inexpressible disappointment (Patreon)

i'm crying right now.
i am incredibly depressed.
heartbroken, honestly.
i just don't know the words to express the depths of utter frustration, bitterness and sorrow i feel

before you all start panicking-- nothing bad has happened.
i'm overreacting.
i am not at all exaggerating when i say that i am crying and depressed right now, but i am definitely overreacting

the thing that happened is... i fixed a bug.
but i am not at all happy about what i had to do to fix it. 

all right, here we go. so today up on the chopping block is destiny bond. if you have played the community release, you may know that destiny bond is not really working very well. specifically, it doesn't carry over to the turn afterwards, and it is supposed to work until the user's next move. when it does not, it makes it almost impossible for slow pokemon to actually use.

so a bit of a code/structure run-down for the unfamiliar:
when the move destiny bond is used, a marker is set to the pokemon that used it
then when a pokemon faints it checks to see if it has that marker
if so, it kills the other pokemon too
and then we need to turn that off later so it's not permanent
simple, right?

so the obvious conclusion is that that marker was being turned off at the wrong time. it's probably being turned off at the end of the turn, whereas it should be turned off at the start of the pokemon's next move. let's go fix that, right?

turns out, it was not in fact being turned off at the end of the turn, as marcello would discover when he first looked into it. the timing should have been correct. just to be sure, he tried removing the part of the code that turned off the marker-- therefore after being used once, it should stay on forever.

that did not happen. it was still resetting at the end of the turn.

there are not that many places in the script that reference that marker so it should not be hard to find. in fact, he could easily  just comment all of them out so that none of them would have any effect and there's no interference, and go from there.
so he did. all traces of anything dealing with that marker that wasn't turning it on, was removed.

...still, it was off by the next turn.

he was a bit baffled and bothered probably some other verbs that begin with the letter b, and decided to just set it aside for now.

that's where i come in. challenge accepted. he's a better scripter than me. but i have heart.

well, i used to have heart. not after this.

anyway i started dicking around with it. first i recreated the scenario in which it still doesn't work despite anything that could pppppossibly turn the marker off being nuked to orbit.
yep, still broken.
cool.

so what now.

i played around with how the variable was initialized a little bit. there's a big long list that runs at the start of the battle and sets up allll the things we have to care about like encore and destiny bond and ingrain and sets them to their default values which is "hi i dont exist yet but maybe could someday if you use my move". big ugly long list of nothing. but it's all the same so it's pretty simple. i briefly considered seeing what would happen if i moved the line about destiny bond to the very bottom of the list, but that shouldn't change anything so why bother. anyway, nothing i did with the initalization seemed to matter. even deleting it. ...which really is not right. 

next i tried experimenting with the destinyrate. i theorized maybe somehow the marker was just not getting passed to the next turn at all-- it's not that it's being deleted, it's that it's not existing in the first place. i suspect if you are not familiar with coding, that will sound strange, and if you are familiar with coding, you will think it is the obvious case.
anyway, destinyrate.
destiny bond is supposed to fail if you just used it on the last turn so in addition to the marker we set saying this pokemon is bonded, we set another one saying this pokemon just used destiny bond so that when it uses destiny bond again the script checks the marker and says qqurrrrl nu-uh. since that specifically has to carry over between turns to work, i figured it's a good indication that the data is making it through after all. it's initialized in the same list-- it's basically the same in every way, except being for a different purpose.  so if the move can fail, we know the data is making it to the next turns.
and the move could properly fail.
soooooooooooo it wasn't that.
i tried having destiny bond work off of the destinyrate instead of the original marker. that worked great. it doesn't work because the destinyrate doesn't get reset until you use the move again without having used it the previous turn, so i can't just fix the effect that way, but it worked. 

so... what does that mean. the data is being passed, so something has to be resetting marker. right?

just to be sure there was no unexpected outside interference, i tried changing the marker's name. we refer to them by name so that should mean anything i did not explicitly change should not be able to edit the marker.
doing this is a very complex process that involves putting a '2' at the end of about three lines and calling it a day. if it works we could just leave it like that. destinybond becomes destinybond2 and nothing that we didn't explicitly ask to turn it off can turn it off. badda bing, badda done.

it was still broken.

logic time:

• - destinybond is not being changed by anything, therefore we have to assume it is somehow not making it to the next turn
• - destiny rate, which is handled in exactly all of the same places is making it to the next turn

therefore... what is different between destinyrate and destinybond?

two things:

• one is that one is a true/false variable and the other is a numeric variable.
  in all rationality and likelihood, if a difference were to matter, it would be this one. i strongly consider changing the type and seeing if destinybond works then.
• the other difference is that destinyrate is further down in the initalize list than destinybond.
  since the list is handled all at once and does not depend on other factors in it, the placement in the list should be irrelevant, and this difference does not make sense to test changing.

i decided to test the illogical, second option. 

i moved the initial call of destinybond, which was not making any difference no matter what i did to it, down to the bottom of the initialize list.

it fixed the whole thing.

there is absolutely 0 reason for it to have made any difference.
but it did.
marcello had spent hours on this, i had spent a hour and a half on it.
and a one line, two-second, irrational change fixed it.

i hate that that worked.
i hate this engine sometimes.
i especially hate that i had had the thought to try that in the first place and didn't.

someday i'll learn to code just based on feeling and intuition alone.
but today is not that day.
today, i will be crying at this irrationality.