[artificial intelligence]

6 hours ago, andracass said:

fieldeffectchecker will naturally return nil if there's nothing in it, so this would effectively duplicate that step.

the additional line for starlight re-nullifies the return under certain conditions (weather existing).

my bad, forgot ruby returns nil if the one-line if condition statement is false, so first line is redundant, but the second one isn't.

it saves the fieldeffectchecker run in the scenario of weather existing and starlight field in effect.

 

the bottom line is that there isn't a need for re-nullification if you can avoid the check entirely when unnecessary. 

again this is really really super minor though 

[artificial intelligence]

awesome blog post, rather comprehensive too.

as an SRE/CE/DevOps/whateverthefuck, i don't code all that much.

that said, i have some experience with ruby from working on foreman (really cursed piece of modern technology for provisioning baremetal hosts), therefore, i was able to understand the code and it was a lovely deep dive experience.

 

one quick question, you mentioned that:

Quote

 the mon that's been selected as the target earlier might be your partner. that's not always a bad thing! maybe you're trying to heal pulse or something. all of the moves that might apply here are in the PARTNERFUNCTIONS array. if we have a move that isn't in there, we skip it.

 

so this really caught my eye since there are obviously a plethora of useful moves to use on an ally mon (i.e heal pulse, acupressure...) but what about obscure strategies that generally utilize damaging moves (sometimes even strong damaging moves) which benefit the ally?

a well known usecase for example is anger point. you sacrifice some damage to your ally (frost breath for example) to yield max attack.

do these usecases fit in PARTNERFUNCTIONS? how are they evaluated?

 

 

anyhow, another section i really liked was the PBFieldEffects one.

i'll need to analyze the current implementation a bit more before i can give any valuable insights (not that i'll probably have any), but i found some code that could be implemented better, example:

 

Quote

 

the first 2 lines could be changed to:

fieldBoost = nil
fieldBoost = fieldeffectchecker(type,:TYPEDAMAGEBOOST) if !($fefieldeffect == 34 && @battle.pbWeather !=0)

 

assume fieldBoost is nil, skip the check entirely if starlight conditional is met, fieldboost self conditional removed as it starts as nil.

this implementation is so slightly more efficient that it doesn't really matter, but it's not just that.

 

regardless, props to you for creating it, modders are going to have a field day with this one!

[Postgame]

 

 

 

 

3

Quote

 

but it's worth noting that people keep having to remind me that Zeraora exists and to this day i have no idea what exactly it does. it's like.... an electro cat? maybe? idk. good luck finding it in chrysolia cave.

 

lol.