Internal Testing, Day 29 (Patreon)

more bug tales. the battle :rage:s on. i took notes this time. well, on a few of them at least.

Disarmed Voice

first up is an annoying little dealio with disarming voice. this was first noticed when fighting cain's popplio... who was taking no action because of this issue. it was reported and I followed up, making sure the issue could be replicated. it could. i passed it on to marcello.

marcello could not replicate it.

he passed it back. i was highly confused having very well replicated it on the same scripts he was using myself. i try again, to get more specifically this time. i notice that the issue only occurs when popplio specifically has liquid voice. great, i think, this makes perfect sense since disarming voice is a sound move. i have found the issue and marcello will now be able to fix it.  i told him the good word.

still he could not replicate it. even ensuring liquid voice.

????????? i tested more and on a new script update. it is -definitely- only occuring with liquid voice, so whyhowcome he not can replicate???? i dont into knowing yet, even now, but i have sent him the exact test trainer that i reliably recreate it with, and if he still cannot reproduce the issue then i will Scream

some say, if you listen on a quiet day, you can still hear me screaming
or maybe you can hear it in about 17 hours since that's how long it would take sound to travel half of the world's circumference.

so this hasn't been resolved yet but i'll keep you posted. 

Recovery Recovery

during the supervised tests, i noted an issue with moves like recover, roost, etc where the AI liked them wayyy too much. this turned out, as i may have related, to be because of our division error which was skyrocketting the scores by making the AI think we were always at 0 health and so gosh if we can recover from that we would really like to recover from that please recover
meanwhile it actually is at 95% health. awkward.

but we fixed that.

during the internal test however, i observed something different-- the AI liked healing moves way too little. in fact it liked them so little-ly that the score for them was getting 0'd out meaning it would just about never use it. what?

well this is absolutely why we have more testing waves. i figured that something about our tweaks after supervised testing had broken this-- although i did test it after that and it was working. so why? but we've seen 0 out problems already. several times it's been caused by our famous division error. lov the divosion. in other cases it was just a typo.

i passed it to marcello. along with the disarming voice issue he passed it back, saying that there was no bug and all of the scoring was working as intended.

well he could not replicate disarming voice, so maybe he just couldn't replicate this for some reason. so we  ▼ ◄ ▲ ► ▼ ◄ ▲ ► ▼ ◄ ▲ ► ▼ ◄ ▲ ► ▼ ◄ ▲ ▼drop our bag of Doritos™ brand debugging messages▲ ► ▼ ◄ ▲ ► ▼ ◄ ▲ ▼ ◄ ▲ ► ▼ ◄ ▲ and see what's up.

well, this time he was right. the scoring was going all the way through to the end after all. but it was way too low from the getgo. so i took a look at the first calculations in the function code. the rough logic as i outlined before is something like this:

• if highest expected incoming damage > this pokemon's remaining HP
• ----score * 3
• otherwise (we're probably not about to die)
•  ---- if best skill trainer
•  -------- if highest expected damage * 1.5 > this pokemon's HP (accounts for possible crit)
•  ------------ score * 1.5
•  -------- if this pokemon is slower than the opponent
•  ------------ if highest expected damage * 2 > this pokemon's HP (anticipating two turns of attack)
•  ---------------- score * 2 
•  ------------  otherwise (we've got at least two turns of safety left and don't need to heal right now)
•  ---------------- score * 0.2

this is pretty reasonable, right? in theory. frankly, accounting for possible crits is going above and beyond the call of duty infinite warfare, but that's just how i got used to thinking back when i played competitive. i was a stall player. in fact i like stall a lot. you're free to judge me. 

the score wasn't actually getting 0'd out in the function code, but it was getting sooo low, that it became 0. the initial math matched up with our score * 0.2 at the end there. all right, so let's rethink it.

there were two unfortunate things when i tested this. the first was that i happened to be testing with a scizor since it was the first thing that came to mind from my last stall team. scizor is Very Slow which meant we were always hitting that conditional and getting to the 0.2, which made think that the move was just always 0ing out. 

the second thing is that i decided to test by chipping away at its health as little by little as possible so i could see exactly when the numbers were changing. if you are especially clever like i was not, you might then notice why this is an issue-- because the very start of that section asks about the highest expected damage. since i was using a chump change chip attack, the AI learned that oh, that's probably the most damage we can expect to receive from that pokemon right now and so it felt very comfortable not healing at all. 

...until it was within kill range. then it would heal just in time to survive.
hm. maybe there's hope. 

this was how i realized the problem with my logic. although it was meant to conserve PP (which, if you're stalling in a competitive match is quite important) it was making the AI far too cozy in not healing off chip damage-- which incidentally was the condition under which this was reported as well. 

although i am concerned about the AI becoming a little too liberal with their recovery moves again this situation, i have just removed that final provision entirely and this seemed to fix the issue including some preliminary tests. but, it will be something to keep working with after all.

Well Aren't -You- Special

Another issue reported in our internal tests: If a shiny pokemon Mega Evolves, the Mega Symbol was crammed partly on top of the shiny star. Frankly, this is pretty esoteric... especially since most players would be lucky to have the shiny of such a pokemon, let alone getting the Mega too? 

But for better or worse, that didn't matter to one brave testers, who defied all odds and just debugged in a shiny mega pokemon for themselves because who the fuck is gonna stop them, not me. Fortunately it lead to noticing this.

I wish I had taken or saved a screenshot of it before, but again, whole lack of foresight issue, but the reason this happened was because of the changes we made to the UI this episode, and more specifically because I had repositioned the shiny star even differently from Pyrolusite's original UI mod. I didn't think to check it for overlap with the mega symbol. whups.

fortunately the fix is pretty quick, just gotta separate the values from how the opponent's symbol is positioned (since theirs was, somehow, fine) and scoot it over. pic related; it's me and my bitch. the red boxes on that pic are where status condition icons like FRZ and BRN go-- i had to test with those too to make sure there was enough room for everybody. there really wasn't. but coder girls make do. 

...as for the charizard's name, this is ikaru's save file from supervised testing... he named it that, not me. idk dudes.

--

i've now handled all of the scriptside reports for internal testing that i need to. ball's in the cellist's court, and i get to move on to the other errors and see how quickly i can KO them.