Tomorrow is the new Yesterday (Patreon)

all right, so yesterday i posted all of the AI bugs we had remaining. last night, I took the AI for a night out on the town, and then afterwards we came back to my place to get to know each other a little more intimately. Here's what I found:

Case 1: Bounce vs Ice Punch against a Fire Type

so although i thought this was a normal issue with the numbers on two-turn attacks being wrong, it turned out this was actually the most important bug to solve last night. firstly, i dialed back the multiplier i mentioned for all two turn attacks, but as I kept testing it still seemed really low. In fact, it seemed like it wasn't valuing the paralysis chance at all. i compared it to Fly to confirm-- sure enough, the AI only cares to Fly, never Bounce (which, if it's not looking at paralysis, is correct because of the higher BP/accuracy)

so why come this? i throw in a few commands to make her speak to me the way i like it. sure enough the paralysis part of the scoring is just become straight 0. i may have mentioned before for moves but we score the additional effect separately and then multiply it in to the move's main score after dividing it by the chance of the effect occurring-- record scratch
run that back again?
we multiply it into the move's main score after [concentrate; slow motion] d i v i d i n g  i t -- SORE WO CHIGAU YO!
B R E A K 

Remember a few posts ago when I talked about how Ruby divides things? If the second number is lower than the first, the result just becomes 0. That means that anything that has an effect chance of less than 100 won't be considered. Unfortunately I had been testing many things with Power-up Punch... hmmmmm. sure to the 'nough, I check and that's exactly where the paralysis score drops off. the reason this is so important is because this additional effect division is the same in like, more than a quarter of the function codes we worked on. and since that's all the common stuff like thunderbolt, flamethrower, etc, that's actually most of the moves. despite all the code we put in, it wasn't considering the additional effects at all because of this bug.

a quick .to_f replace command on 34 function codes makes that medicine go down real smooth. and after that's done, the opponent likes bounce pretty well after all. 

i mentioned in a previous post that i thought that the final score values were being capped at 110 despite that only having been meant to apply to the initial score (base damage only). marcello was always adamant that no such cap was happening, and he was right. it's just that literally everything that would have applied beyond the initial score was getting 0'd out.
or otherwise didn't exist.

yikes.

During this testing I also found an unrelated issue where the score for Hi Jump Kick was always being cut to 0 so the AI would never use it. unfortunate. I don't know the cause right now but I passed it along to Marcello to look at make sure there are no other cases of. The thing is, HJK is one of the moves that we haven't made code for. So I'm not too concerned about this-- we just comment out the offending single line for now and make it work next cycle. But the 'why' is important to know.

Case 2: Cinccino's Hidden Power vs its Skill Link Moves

my theory was that it preferred hidden power because there wasn't properly code for multi-hit attacks' expected damage yet. like HJK, multi-hit attacks are among the functions we have yet to do, so this would have made sense. Although, it was strange that Noel in the past seemed to prefer these moves fairly reliably, suggesting that Essentials had default code for it.

Which it did. I found a solid method, BetterBaseDamage, which was properly counting the expected power, even with Skill Link. sweet! but... the final scores the AI was getting seemed like it wasn't counted at all. why this??? It expected Rock Blast to do 18%  damage to an opponent, when it actually would have done 90% damage. yowzers?

as I continued to look through the code, I noticed something worrying... That BetterBaseDamage method was being called, sure... but it seemed like the result wasn't being used at all. Sure enough I found the code that would normally use it in a large section of commented out code from the old AI logic. That explains why Noel used it in the past, but not now. We had to rewrite that section entirely, but forgot to reinclude that method. Which makes sense-- because the timing we'd need it at is actually totally different now

This is really unfortunate to not have because that method has all the handling for moves that change base power at all-- Eruption, Low Kick, Wring Out, Hidden Power-- wait, hidden power? what are you still doing there???? you only do 60 BP now!! I guess through Episode 16 the AI was still expecting a HP BP based on the pokemon's IVs. oops. we'll have to be sure to cut that out later...

Once we get that method integrated back into the code then not only will multi-hit attacks be calculated properly, but so will many other moves. That's a big one to miss out on! Can i get a y i k e z

Case 3: Radomus and Trick Room have a fight and don't speak to each other

This is one I expected coullld be a numbers issue as in maybe the value wasn't quite reaching a high enough number for it to reliably use TR every time. So I looked at the score first to confirm this theory.

0.

Why are things like this??? This one doesn't even have any additional effects or any division at all!!! What gives??

Actually it was pretty easy to figure out though. Part of TR's function code is basically

• if we're slower than the opponent
• and trick room is not up
• use trick room
• but if it is up 
• definitely don't use trick room
• and if we're faster
• and trick room is up
• we should totally cancel trick room
• but if not
• we should definitely not use trick room

and it was becoming 0 (definitely don't use--) after that. hmmm. well, it wasn't that hard to figure out after all. it seems like the conditionals for "if trick room is up" were copy pasted incompletely when the function logic was converted into ruby. they uh, didn't have any operators. (so tell me operator, how do i operate her?) all i had to do was finish those off and it worked like a charm. the happy couple is back together again.

...anyway, most of the others are not especially noteworthy. the issue with Victoria and Fire Fang, was indeed because of the %fluke, which as been fixed (i.e it has a 95% chance to use Bite, and a 5% chance to use Fire Fang, and it just happened to pick fire fang) by making it always choose the best moves instead of only doing that when the best move was a certain amount above the others (which is how essentials natively does it, and also that threshold was skewed because of how we changed the scoring center)

I've elected to push the Potion handling to next episode, because while it is very significant, the section that exists for it is a disaster and we will probably have to rewrite the whole thing. Right now it doesn't even know how much health its potions will heal. that is. kind of important. 

The issue with Freeze on E-Terrain couldn't be reproduced, meaning whatever it was was probably already fixed.  The partner scores have been properly updated to just reduce the attack score by the amount of damage it does to our partner, except in some cases like if our partner is about to be heckin' deadzo anyway, etc. Switching just needed some numbers tweaks on it to think about cases differently (it was overvaluing offense and undervaluing resists), and priority KOs were another thing that got commented out from old AI but I put them right back in their position. 

That's about everything! Meaning once Marcello gets the last of those fixes into the code and finished up, we will finally start internal testing! Yayyy~~~