7/30/2020 Notes:
Status Report
*(dons the customary lab coat/straightjacket)
If you don't like purple prose, skip to Log Status, Log Element, and Log Charge for the nitty gritty testing.
My fellow furious fiddlers finding fickle frame rates and forcing function into flawed formats, today's topic is status infliction.
If you're an avid RPG player, you probably remember this guy.
Malboro. A Final Fantasy recurring monster who taught us the fun of watching party members attack each other, hoping the friendly fire would snap someone out of confusion long enough to start removing status conditions such as poison, blind, baleful polymorphs, petrification, itchy armpits, etc.
A foe who made it very worthwhile to invest in status-prevention gear.
The long and short of it is that in any given RPG, you will likely have:
- Status effects that result in controller damage
- Monsters whose entire schtick is inflicting multiple controller-crushing statuses at once or on the entire party
- A means to both cure and prevent such misfortune.
The purpose was, of course, to keep players on their toes. A net HP total of 0 of course means the end, but having your HP slowly drained or being afflicted with something that shut down a party member was a slower way of getting to that dreaded game over screen, as well as adding frustration and stress to the mix.
In the old days, status effects stayed with you after battle, persisting until cured or the character's death. Final Fantasy XII brought this dying tradition back into a very sharp relief, with characters retaining ailments even after K.O.
In any event, a wise player made sure to have a stockpile of medicines in addition to generic HP restores, or better yet, equipped mitigating gear on characters to prevent the statuses that would hamper them most- Blind prevention on physical attackers, silence prevention on casters, and confusion prevention above all else in an Atlus game.
You may recall some games thought group hitting instant-death attacks at early levels were a form of difficulty. This is what we in the business call "A Very Stupid Idea" and I will not dignify it by expounding on it further in this rant.
But here's the thing- some games have a late-game item or ability- "ribbon" in Final Fantasy that allows a character total immunity to a status, or multiple statuses at once. If made very rare, it becomes a premium item to be equipped on someone you either can't afford to be shut down for more than a turn at most- this usually means the healer, who can then get to remedying everyone else.
If this "ribbon" is made readily available for an affordable price at your local Equipment Shop, then getting hit by a status boils down to either being improperly prepared or prioritizing other parameters over status prevention- elemental resistant, raw protection, damage increasing gear, etc.
Other games go a different route, offering various items that make a character "resistant" but not immune to a status. Items that give outright immunity to anything may be very rare, late game items, and further exacerbate the problem of "prevention vs. power".
This brings me to how this issue was represented in Tabletop rpgs, namely, having better stats in one area could make you more resistant to related statuses. Your squishy wizard might have a hard time saving vs. poison, but would be able to shrug off attacks on their mind much more easily than other party members. There were also feats you could take to become even more resilient to certain kinds of effects, which had a way of making your character feel more badass than just slapping a badge of null poison on them.
To that end, Vitality and Spirit in Pariah's Creed.
LOG STATUS
I was informed of the right way to go about this by a fellow gamemaker named Theo. I had spent several nights trying to figure out what the hell I was doing wrong with no success until I asked for advice.
chance += (((user.xstat.macc*0.01)/10)-mev) if item.magical? and opposite?(user) #added
chance += (((user.xstat.acu*0.01)/10)-eva) if item.physical? and opposite?(user) #added
chance -= (xstat.vit) if effect.code == 21 && [2,3,7,10,26,27,28,29,30,31].any? {|id| effect.data_id == id} #added 7/29/2020
This snippet of coding is part of how status accuracy is affected in Pariah's Creed. If the action in question is magical, it receives a bonus from the user's macc, if physical, it gets a bonus from acu.
Right now, the xstat.vit is just a placeholder. There will need to be a reckoning of balancing before I can get it into a finalized form. Right now, all we're concerned about is that it works as intended.
The random numbers 2 through 31 aren't entirely random- they're a combination of statuses related to injury and toxins. In gaming logic, having a higher endurance score means a greater resistance to injury and illness.
It's our good friend Mr. Death, ironically still shackled to the confines of the program and unable to escape his unrelenting hell of eternal torture! Of course, Mr. Death is a concept made of preassembled sprites and data, and doesn't actually exist as we would consider a living being to, so he doesn't feel pain.
Probably.
I think.
My computer only screams on full moons, anyway.
Anyway, he has a vitality score of 300, waaaaaaaay more than any of the other monsters I've made, for the purpose of providing a very definitive "No" condition.
And here's the skill we'll be using for testing.
Hemotoxin and Injured Eyes are statuses # 2 and 3 respectively, included in that string of numbers mentioned earlier. Amnesia is status #4.
Ignoring Mr. death's persistent confusion and that 1 popping up, we can see that Amnesia is inflicted, hemotoxin and Injured Eyes are not.
What this means brings up back to the case of a theoretical "Malboro" monster. If we don't take any preventative equipment into account, then it's possible to have statuses resisted by a character's innate traits on a grouping basis. A high VIT character can resist toxins while still being susceptible to mental and curse statuses.
As the player is ultimately in control as to a character's growth in regard to their six core stats- STR, VIT, AGI, SPD, MAG, and SPR, this gives more incentive to pump vitality and spirit beyond HP, MP, and damage mitigation. It also helps to avoid "Godstat" syndrome, which I will touch on later.
"But why, why, why, Crazy Rob?" some may ask. "Why do you do such perverse and unnatural things? Rpg Maker VXA already accounts for luck on both sides, status resistance, and the success rate of the skill itself!"
In a word, accountability sans bullshit. There will be times the enemy critically hits, or a skill misses, or a status connects when it's a really bad time. But the goal is to allow the player to choose how they are prepared.
To capture that feeling when you do something that a particularly devious Dungeon Master did not see coming, and suddenly the Boss Monster's ace-in-the-hole is nowhere near as reliable as they thought.
But I wax poetic. ONWARD TO MORE ABOMINATIONS.
Elementary, my dear Watson.
RPG Maker VXA improved on many, many things. The ability to easily modify elemental damage output was not one of those things, for reasons known only to the Enterbrain executives. Yes, there are plenty of ways to modify a target's resistance, but beyond mere resistance mods you need scripts and a working knowledge of how to exploit them.
If you for some reason want to emulate most of the nonsense you read here, you need to consult a psychiatrist, and should that not cure you, download a fun little thing called Extra Stats.
You may have heard me yammering about stuff like xstat.vit and xstat.spr, macc and acu, etcetra. How these were implemented and made is something for another time if people are interested. The gist of it is that while RMVXA offers plenty of stats to tinker with, sometimes you want to create something so complex it requires an entire gamefaqs guide and spawns vicious forum arguments over whether you were simply drugged or if you're truly that crazy.
Via Crystal Engine: Extra Stats, I created several "ElementPlus" stats, something concrete to base boosts and penalties to individual elements off of.
"Crazy Rob," you say with an exasperated sigh, "you done goofed. I don't see any whatever-plus stats here."
This is correct, for two simple reasons.
The player doesn't need to see them, and it would require a second page.
As of now, the game has in terms of basic elements: Impact, Slash, Pierce, Acid, Pyro, Hydro, Aero, Geo, Light, Darkness, Healing, Drain, and combinations of Impact/Slash/Pierce for all elements save Healing. While we don't need a separate state for each combination, having items and skills that say "Boosts Pyro damage by 25%" is sufficient.
And let's be honest here- there's already enough info here to bludgeon a particularly mean mathematician into unconsciousness.
LOG ELEMENT
This weapon in question is chosen for most of my tests because it has a combo-element, SlashPyro. It stands to reason if a zombie type enemy is vulnerable to slashing weapons and being set on fire, then the best weapon is a flaming chainsaw launcher. Failing that, a sword set on fire will do in a pinch.
You can see in the lower right hand "notes" corner some flavor texts and some tags, specifically the ones that say "pyroplus" and "hydroplus". This weapon boosts the pyroplus stat by 25 but penalizes the hydroplus stat by the same amount, meaning it's a great weapon when dealing with flammable insects, mobile poisonous plants, and the aforementioned zombie... not so great when dealing with an angry fire demon or lava golem.
However, just because we made a stat named pyro plus and then modified it doesn't mean jack squat to RMVXA for purposes of elemental modification.
<damage formula>
m=0; d=(a.xstat.strpow*1); for n in [1, 25, 28, 31, 34, 37, 40, 43, 51, 54, 57,
60, 63, 66, 69, 72, 75, 78, 81]; if v[400][0]==n; m+=(a.xstat.impactplus*0.01
); end; end; for n in [2, 26, 29, 32, 35, 38, 41, 44, 52, 55, 58, 61, 64, 67, 70,
73, 76, 79, 82]; if v[400][0]==n; m+=(a.xstat.slashplus*0.01); end; end;
for n in [3, 27, 30, 33, 36, 39, 42, 45, 53, 56, 59, 62, 65, 68, 71, 74, 77, 80,
83]; if v[400][0]==n; m+=(a.xstat.pierceplus*0.01); end; end; for n in
[4, 25, 26, 27]; if v[400][0]==n; m+=(a.xstat.acidplus*0.01); end; end;
for n in [5, 28, 29, 30]; if v[400][0]==n; m+=(a.xstat.pyroplus*0.01);
end; end; for n in [6, 31, 32, 33]; if v[400][0]==n; m+=(a.xstat.hydroplus
*0.01); end; end; for n in [7, 34, 35, 36]; if v[400][0]==n; m+=(a.xstat.
aeroplus*0.01); end; end; for n in [8, 37, 38, 39]; if v[400][0]==n;
m+=(a.xstat.geoplus*0.01); end; end; for n in [9, 40, 41, 42];
if v[400][0]==n; m+=(a.xstat.lightplus*0.01); end; end; for n in
[10, 43, 44, 45]; if v[400][0]==n; m+=(a.xstat.darkplus*0.01); end;
end; for s in [12];if a.state?(s); m+= 1; else; m+= 0; end; end;
d*=(1+m); d-=(b.xstat.arm)
</damage formula>
That festering abomination of code is a formula for a basic attack, which, in conjunction to some modification of the rmvxa's base script code, will take the weapon's element stored variable 400-0, and check it against multiple arrays. In this case, having multiple bonuses to *plus stats would be a boon- a player with slashplus and pyroplus would effectively get two bonuses at once! Which sounds great- right up until something with a "reflect slash" or "reflect pyro" property throws a powerful attack back in your character's face.
This is necessary for skills that have 'normal attack' set as their element- RMVXA needs help finding out what element a weapon is for the purpose of this formula.
The formula for something that's a set element, like say, the traditional fireball to the face, is a lot simpler.
<damage formula>
m=0;d=(a.xstat.magpow*1.25);m+=(a.xstat.pyroplus*0.01); for s in [12]; if
a.state?(s); m+= 1; else; m+= 0; end; end; for s in [135];if b.state?(s);
m+=(0.25); else; d+= 0; end; end; d*=(1+m); d-=b.xstat.mar
</damage formula>
Being spared the need to drop an element in a variable array, then check it against multiple arrays, the formula for a 1st level fire spell is a lot less complex. A bit of code for a "charged" status to amplify damage, a status checker to add more if an enemy is afflicted with an earth elemental 'damage over time' attack, and subtracting enemy magic armor at the end.
Got it? Good.
The two previous formulas were a mistake.
Why then, would I go through the trouble of posting them and explaining what they do, when I openly admit they were in error?
Because there is a much, much better way, one that does not involve repeatedly pasting and tailoring code into each skill.
$game_variables[400] = user.atk_elements #added
$game_variables[501] = 0
$game_variables[502] = 0
value = item.damage.eval(user, self, $game_variables)
value2 = 0
if item.damage.element_id < 0 #added 7/31/2020
value2 += ((user.xstat.acidplus*0.01)) if [4, 25, 26, 27].any? {|id| $game_variables[400][0] == id}#added 7/31/2020
value2 += ((user.xstat.pyroplus*0.01)) if [5, 28, 29, 30].any? {|id| $game_variables[400][0] == id}#added 7/31/2020
value2 += ((user.xstat.hydroplus*0.01)) if [6, 31, 32, 33].any? {|id| $game_variables[400][0] == id}#added 7/31/2020
value2 += ((user.xstat.aeroplus*0.01)) if [7, 34, 35, 36].any? {|id| $game_variables[400][0] == id}#added 7/31/2020
value2 += ((user.xstat.geoplus*0.01)) if [8, 37, 38, 39].any? {|id| $game_variables[400][0] == id}#added 7/31/2020
value2 += ((user.xstat.lightplus*0.01)) if [9, 40, 41, 42].any? {|id| $game_variables[400][0] == id}#added 7/31/2020
value2 += ((user.xstat.darkplus*0.01)) if [10, 43, 44, 45].any? {|id| $game_variables[400][0] == id}#added 7/31/2020
value2 += ((user.xstat.healplus*0.01)) if [12].any? {|id| $game_variables[400][0] == id}#added 7/31/2020
value2 += ((user.xstat.impactplus*0.01)) if [1, 25, 28, 31, 34, 37, 40, 43, 46, 51, 54, 57, 60, 63, 66, 69, 72, 75, 78, 81].any? {|id| $game_variables[400][0] == id}#added 7/31/2020
value2 += ((user.xstat.slashplus*0.01)) if [2, 26, 29, 32, 35, 38, 41, 44, 47, 52, 55, 58, 61, 64, 67, 70, 73, 76, 79, 82].any? {|id| $game_variables[400][0] == id}#added 7/31/2020
value2 += ((user.xstat.pierceplus*0.01)) if [3, 27, 30, 33, 36, 39, 42, 45, 48, 53, 56, 59, 62, 65, 68, 71, 74, 77, 80, 83].any? {|id| $game_variables[400][0] == id}#added 7/31/2020
end#added 7/31/2020
value2 += ((user.xstat.acidplus*0.01)) if [4, 25, 26, 27].any? {|id| item.damage.element_id == id}#added 7/31/2020
value2 += ((user.xstat.pyroplus*0.01)) if [5, 28, 29, 30].any? {|id| item.damage.element_id == id}#added 7/31/2020
value2 += ((user.xstat.hydroplus*0.01)) if [6, 31, 32, 33].any? {|id| item.damage.element_id == id}#added 7/31/2020
value2 += ((user.xstat.aeroplus*0.01)) if [7, 34, 35, 36].any? {|id| item.damage.element_id == id}#added 7/31/2020
value2 += ((user.xstat.geoplus*0.01)) if [8, 37, 38, 39].any? {|id| item.damage.element_id == id}#added 7/31/2020
value2 += ((user.xstat.lightplus*0.01)) if [9, 40, 41, 42].any? {|id| item.damage.element_id == id}#added 7/31/2020
value2 += ((user.xstat.darkplus*0.01)) if [10, 43, 44, 45].any? {|id| item.damage.element_id == id}#added 7/31/2020
value2 += ((user.xstat.healplus*0.01)) if [12].any? {|id| item.damage.element_id == id}#added 7/31/2020
value2 += ((user.xstat.impactplus*0.01)) if [1, 25, 28, 31, 34, 37, 40, 43, 46, 51, 54, 57, 60, 63, 66, 69, 72, 75, 78, 81].any? {|id| item.damage.element_id == id}#added 7/31/2020
value2 += ((user.xstat.slashplus*0.01)) if [2, 26, 29, 32, 35, 38, 41, 44, 47, 52, 55, 58, 61, 64, 67, 70, 73, 76, 79, 82].any? {|id| item.damage.element_id == id}#added 7/31/2020
value2 += ((user.xstat.pierceplus*0.01)) if [3, 27, 30, 33, 36, 39, 42, 45, 48, 53, 56, 59, 62, 65, 68, 71, 74, 77, 80, 83].any? {|id| item.damage.element_id == id}#added 7/31/2020
value *= value2 + 1
Forgive the need to scroll to the end, but as you can guess, it's a doozy.
The astute of you will notice "Drain" doesn't have a plus of it's own. Impact/Slash/Piercedrain skills can get boosts from Impact/Slash/PiercePlus, but drain doesn't need a boost it can double off of, as mentioned before. HP and MP draining skills get bonuses depending on what the enemy has in terms of status conditions, and making skills that damage and restore too powerful is a great way to unbalance a game.
Note the 6th line about if the element_id is less than zero, or in non-code terms, is a "Normal Attack" element that draws on the user's weapon. Then note the first line that gets the user.atk_elements for Variable 400. Normally, you can put as many elements as you want into a weapon, but this makes damage calculation confusing and unreliable.
You may see that it seems I've done the value multipliers twice. Note the details at the end of each line of code- one is explicitly for weapon attack elements, the other is for "set" skill elements. Testing shows there's no undesired redundant multiplication, meaning a "normal attack" skill will benefit from the top set of lines, but not the bottom, and a set element skill will benefit from the bottom but not the top. Value2 is initially set to 0, loaded with all relevant "plus" multipliers, then plugged into value at the end of this.
For the purposes of this next experiment, the default attack, and four test skills will all be set to 100 flat damage.
Attack: All, physical, normal attack
Test 1: All, physical, normal attack
2: All, magical, Acid
3: All, physical, Acid
4: All, physical, Pyro
The magical and physical don't mean much. Yet.
In the game, Lohste has a number of factors that will contribute to the formula.
Pyroplus+:
Flame Talon, 25
Pyro Ring, 50
Pyrokinesis, 10
Greater Pyrokinesis, 10
Slashplus+:
Slash Ring, 50
Acidplus+:
Acid Ring, 50
There is the matter of the -25 to Hydroplus, but we're not testing the Hydro elemental here.
As is evident in Mr. Death's latest brutal maiming, the numbers are right on target with what would be hoped with this script modification. Equipping both the slash and pyro rings brings the total damage of the 'normal attack' skills and attack itself to 245, while the explicitly pyro skill remains at 195.
This of course was just discovered during my experiments of the status mod, courtesy of Theo. Having learned the language needed to get the results, the next step was a series of crashing the program repeatedly until I learned how to twist words into what I wanted.
Naturally I'd already implemented the flawed code on a good hundred or so skills. And I'll need to repair them so they don't get redundant boosts. Such is life, but herein lies another valuable lesson, sans my usual nonsensical bullshit.
If you're having trouble with something, ask someone who knows what they're doing.
This is applicable to so many situations in real life it's not even funny.
Thus endeth my attempt at being philosophical. Onward to something that's been bugging me for far too long and only got resolved today as well.
Three issues brought to resolution in three(?) days. God must be cutting me slack.
Chargin' it Atlus Style!
<damage formula>
m=0;d=(a.xstat.magpow*3);m+=(a.xstat.slashplus*0.01);
for s in [12];if a.state?(s); m+= 1; else; m+= 0; end; end; d*=(1+m);
d-=b.xstat.mar
</damage formula>
Another snippet of a code that is slated to be scrapped, note the 2nd line in the damage formula, "for s in [12]; if a.state?(s); m+=1,else;m+=0..."
This in so many words is a damage formula that checks to see if user (a) has state 12 (charged). If so, it adds 1 to M, a variable we just made a line ago. Damage formulas, especially the ones allowed by Hime's Damage Formula script, are much, much easier than the arcane language that is RGSS3.
...it's arcane to me. Shut up.
Anyway, "M" serves as a multiplier at the end, added to 1 and then used to multiply "d", the damage formula itself, by 1+M. So with a Magpow of 30, slashplus of 50, "charged" status on the attacker, and 30 mar (magic armor) on the defender "b", we get 195 total damage assuming a variance of 0. (Variance is a percentage of how far the damage can vary, +/-. The higher the variance is, the less consistent the damage)
But in SMT games, once a damaging skill is used, it removes the related charge status on the user. It's a simple matter to just stick something like a.remove_state(12) somewhere in that formula, except for one glaring issue.
The formula is called each time for each opponent in a group attack, meaning that the first use of the formula will remove the charge status, and only the first target has a chance to get the charged damage. The alternative I had in mind due to this setback was to have one universal "charge" skill that lasted one turn.
You get three guesses why I am happy to scrap that method and the first two don't count.
Again, revising this old method means I will have to dig through a lot of skills and excise now redundant code. But if that's a price you're not willing to pay- undoing old flawed methods in favor of using new, better ones- then you should probably ditch game creation and go into politics or management.
I'd like to point out that during the writing of this section, thunder started rumbling. This may not be a sign of an angry or even mildly upset deity, but it's a good sign you should back up whatever you're working on.
You'll note that I say this often and with a considerable dip in the usual humor. There's a really good reason for that, and it can be summed up as losing something you've spent years working on is a really awful thing to have happen to anyone, and while there's a good number I wish that and even worse misfortunes on, chances are if you're reading this, you're not one of them.
Any-hoo.
LOG CHARGE
value *= 2.5 if item.physical? and opposite?(user) and user.state?(146) #added 7/31/2020
value *= 2.5 if item.magical? and opposite?(user) and user.state?(147) #added 7/31/2020
$game_variables[501] += 1 if item.physical? and opposite?(user) and user.state?(146) and value != 0 #added 7/31/2020
$game_variables[502] += 1 if item.magical? and opposite?(user) and user.state?(147) and value != 0 #added 7/31/2020
You may recall a previous batch of code lines had declarations for variables 501 and 502, setting them both to 0. Note that rggs3 gets really cranky when any variables are undeclared, and we need those variables to be reset to zero each time. Here's where we use them.
For those with their rmvxa editors open, this is under Game_Battler, under Calculate Damage.
After all the elemental plus mods are done, if the related charge status is in place, the value is multiplied by 2.5. Why 2.5? It worked for Persona!
Keep in mind these are all tentative values. It may be that a playtester, myself, or my good friend @elizibar point out that this value and others are wack, and need to be toned down.
State 146 will serve as our "Power Charge" and 147 as our "Magic Charge". As most of my STRpow and AGLpow based abilities are physical and nearly all MAGpow abilities are magical, this should be pretty clear cut. There are exceptions, but those are more outliers to spice up certain skill toolkits.
The code presented does two things- multiplying physical/magical damage if the relevant state is present and the target is on the enemy side.
Afterwards, it goes through those same three checks again to determine whether 501 or 502 are added to, which will serve as crude but effective flags for the next part of this contraption.
Note that I've added "and value != 0 " to the end of two lines. Some skills are physical and magical to allow for vit or spr reduction, but don't do damage. They may have damage formulas for more complex problem-solving and special conditions, and due to the scripts' design, they'll need to be set to 'HP damage', but the total damage done will be 0 and we don't want charges wasted on fancy status effect only skills.
We've got the 'boost' part of the problem down. Recall the other issue I pointed out- that the "charge" status would be removed after the first hit, and the only interim solution was to have it last one turn. We want it to last, say, x turns normally, but be expended and removed once the player fires off a relevant attack.
Still in Game_Battler, we progress down to * Processing at the End of Action.
def on_action_end
@result.clear
remove_states_auto(1)
remove_buffs_auto
self.remove_state(146) if $game_variables[501] > 0 #PLACEHOLDER
self.remove_state(147) if $game_variables[502] > 0 #PLACEHOLDER
$game_variables[501] = 0#added
$game_variables[502] = 0#added
end
While the placeholder tags may be redundant now, it's good to mark changes you made to the code for future reference in case problems crop up.
The condition for removing the Power and Magic charge states is about as simple as it gets for rmvxa. If the relevant variable is above 0, poof.
Recall that at the beginning of the damage code, we set the 501 and 502 variables to 0. Just to be sure, we have them reset here as well.
You've probably guessed that I'm debugging and testing these things behind the scenes to make sure they work, which of course I am.
Above, I had the vitality clause subtract xstat.vit from the percentage chance, which barring skills that result in >100% cos will mean no success on any given attempt. For this next test, I'm changing that to spr * 0.5 and using the madness status, which won't be a final number, but should provide a rough 'coin flip' test to see if madness sticks and misses with a physical based 'no damage'.
The red rectangle indicates one of the special damage formulas in question- a simple check to see if the target has status #5 madness, in which case it automatically hits it with status #40, despair. While the primary purpose of this test is to ensure that the power charge works when it's supposed to and doesn't activate when it's not, this is a good way to make sure the damage formula is still being called.
With the current setup of just having Lohste equipped with the Flame Talon and the skills Pyrokinesis and Greater Pyronkinesis, the precharge damage output we should see is 145. We won't be adding rings for this test. Given the code's current setup, a charge should raise it to 362.5, rounded down to 362. Test attack 3, set to do no damage whatsoever, should not expend the charge.
I've set the battle events to refresh the charge status on Lohste every other turn for purposes of clarifying boosted and unboosted damage.
The uses of Test Attack 3 inflict and refresh madness and despair, but don't inflict damage or expend the charge. Immediately after using a physical skill, "Focus Power" is removed as we intended.
Thus we've created some alterations that provide what we set out to do-
- The charge being used is accounted for via a variable
- The charge is expended when a relevant skill is used on the opposing force
- The charge is not expended when using a physical skill that does no damage
- Said physical skill can still have a functional damage formula for shenanigans regardless
I could go on and on, but the summary is more or less "we got what we came for", and that's as good a note as any to end this rant on. You should go do something fun to reward yourself for getting through this.
Thank you for reading my rant, remember to read, shrug, and ignore.