Alpha Testing, Day... whatever. (Patreon)

all right, so most everything that was reported for non-script-side errors was handled at the alpha stream a couple days ago, but let's take today to talk about some of those script-side errors... and specifically AI because AI being busted is the cool new thing in Reborn. you guys know that we've been kind of wrestling with it for weeks so i'll talk about why you're seeing some of the errors that you're seeing, and why they weren't caught sooner.

Pokemon with Hyper Beam type moves take no action

this one was pretty simple... it was actually working in internal just fine! but now that the AI knows that hyper beam sucks it didn't like to use it much, which was a problem for the PULSE Abra fight which is really only beatable if it uses hyper beam as much as possible. soooo for the alpha we added a handler that says hey if our name is ZEL let's like hyperbeam a whole lot more so we actually use it.

it turns out this did not happen because the line that was added to that was typo'd or... something. anyway the point was it didn't like doubles existing because it's a lot harder to ask what a person's name is if there are two names. it seems like this also backfired onto the singles implementation and made the score check not work. sooo fixing that typo makes it work again in double, aaaand makes ZEL properly more disposed to hyper beam. two stones, one bird. nice. 

Pokemon with Calm Mind/Quiver Dance/Bulk Up/Coil take no action

I don't actually recall the details on this one... i'm trying to hard but you know my memory... it's just... awful... it's just absolutely awful... here's the gist: in internal testing we observed that the scores for these moves were r i d i c u l o u s l y high sometimes, so they would just set-up forever and never attack. i am pretty sure the reason that was a thing was just because the offensive and defensive stats together (using full calculations from each of those individually) just made it very mathematically desirable. so i asked marcello before alpha to add something or other to those moves. 

what was that? i... don't remember... that's what i can't remember... but whatever it was, it was to make the AI much more choosey about those. i also cut the base values so it liked them less in the first place.

anyway, it was those four moves that were affected because those are the statup moves with offensive + defensive components. whatever marcello added at my request before alpha, he just typo'd, causing alllllllllllll of those errors we saw. awkward.

The fucking screen glitch

the reason this one gets to be 'fucking' is because we had a :b:itch of a time replicating it. basically, sometimes, under certain conditions, pokemon with screens would just... stop using screens altogether. they'd also stop using any moves. very rude of them. but no matter what marcello did, he couldn't recreate the issue to solve it. very frustrating. 

this one we actually did see in internal as well-- and i couldn't recreate it then either! what! why is it so elusive?! 

when we were going over it again i figured whatever section of the code it was in was probably one that was really convoluted to get to. and it's prooobably this one, as written out in my logic before, for light screen as an example:

• if this pokemon is faster than the opponent
• -------- score * 1.1
• -------- if highest expected damage > this pokemon's HP from a special attack
• ---------------- but highest expected damage / 2 < this pokemon's HP
• ------------------------  score * 2

this is the most complex the function code gets, so i figured if there was an error it was probably in this section. it's meant to look at cases where using light screen could make it live a turn longer, and prioritize that if so. so, i asked marcello to check that condition in specific.

he did, and still couldn't replicate it.
well shoot.

eventually i decided i'd step back in and try myself, so i had azery, who had reported a very easily replicable instance of the error, send me his save file. surely if i traced his steps, i could do it.
...and i did!
so i threw some debug messages in there. then i can see exactly where the move is failing.
............and it's right at the spot that i said it probably would.
did marcello test it improperly or something?????? did he not really test it at all despite my asking him to???

so i told marcello how to recreate the error exactly: send out a pokemon against a faster pokemon with a screen, and hit it with anything. this is actually hard to test on a pokemon with one screen because it will almost always want to get that screen up first turn, and then it'll skip calculation since it's already up and it knows not to bother. but if it has two screens there's still one screen left for it to glitch on. 

i asked him if he had actually tested that-- he had. he asked me if i was using the most up-to-date scripts. i admitted that i was not-- i was still using the alpha's scripts. 

...but that's it!

suddenly very happy he understood everything.

the error was in that section i mentioned. specifically it would get hung up if we -hadn't- used an attack the screen could block, and then we asked for a variable based on the blocked attack to proceed... so if there is no attack to block... there's no variable... and the thing shuts down in a fit of frustration. 

but the reason that marcello couldn't replicate it was because, by some stroke of luck, when he was doing something entirely different he just happened to fix that error by accident by adding a default value for that missing variable. he didn't realize at the time that was causing the issue, but then having since fixed it, he thought the other thing couldn't be replicated. it was a stroke of luck that i happened to be testing on alpha scripts, otherwise we might never have figured out the accidental fix. 

...but the error would have gone away regardless. so really it was mostly lucky for our collective sanities.

Myriad of other Stupids

Those of you in attendance to the alpha-fixing stream at the right time will remember this one: There are a lot of moves with inefficient uses that are coming up with the alpha. Dream Eater being used on awake Pokemon, Helping Hand being used in singles-- and it's just-- what??? These things have never been an issue before, why this???????????

Now make no mistake-- all of these are moves that we have -not- done AI code for yet. We did 120/350 but that's still 230 left un-done so that's statistically likely. but that's weird, because it's not like we removed the old code or anything-- it has the same code as it's had since base essentials, and dream eater on waking pokemon has never been an issue before. so what gives???

marcello showed me a snipet of code mid-stream:

this is for dream eater. that has nothing to do with the function code being "DE"-- that's just a very happy coincidence i just now noticed and i appreciate it a lot. anyway. the score only reduces by .9 if the target is asleep??? that's wrong. that's awful! it should go to 0. why this essentials????
...was basically the mindset marcello showed it to me in

truuuu i first thought. it's kind of weird that one of those has a trailing 0 and the other one doesn't, i next thought.
oh.
actually that's important. it clicked together all at once. if you were at the stream you probably saw the exact moment it did. 

basically what happened is: i have talked a bit already about how we converted move scoring for all moves, not just the ones we did, from additive to multiplicative so that it's better basing off of the starting scores, and that changed the scale completely.

anyway in order to make that change without editing all 350 function codes individually yet, i used notepad++'s replace feature. i'd search for something like "score+10" and replace it with "score*1.1". since the original starting point for scores was 100, this equated nicely. the same was true for the reverse. "score-10" became "score*0.9" and so on.

...figure it out yet?

i did that auto-replace, but let's say that there was something like, oh, let's say, "score-100". when auto replace happens, it finds "score-10" in "score-100" because the strings match. then that becomes "score*0.90". suddenly what was gutting the chance of a move being used is actually just a light discouragement. oops!

fortunately since the trailing 0's were preserved we were able to catch this during stream yesterday and another quick replace restored them all back to their harsh reductions, meaning that whole host of affected moves, whatever they were, should now be working much better!

-- that's it for most of the major alpha AI bugs. there's a few scores i've gotta tweak but that much is expected, and relatively easy. onwards!