Random Chance of Reversing
I think it would be best if we change the default chance-of-reversing in RM mode from 0.666667 back to 0.5.
Done. This is something which will need some tuning, though. And how about a larger orbit distance?
But, if you would like to try 180 or 200, go ahead.
Huh, apparently 0.6666666666667 was about 0.4 APS better than 0.5.
Do you have any idea why it's performing so horribly against other PM bots?
Those two oddities are linked. Because it only decides once per enemy bullet which direction to go in, and because of the close fighting distance, we end up with two large probability spikes, one at GF1 and one at GF-1 (or as close as is reachable). If it were further away more than one bullet firing event would happen, so it would make the decision more than once, adding variability to where it ends up (2^n spikes for n bullet firings). Either we need to take the reversing decision out of the bullet-fired dependency, or we need to be far enough away that it can even out those spikes.
If you could fit a .08 probability of reversing every tick without loosing performance elsewhere, that would be amazing. The reason Yatagan's movement is small enough to fit distance control and good energy monitoring is because it's so simple and elegant. When the enemy fires, either never reverse, always reverse, or have a random chance of reverse or not reversing.
I guess we'll try a distance of 200/220 in the next version. It will almost certainly harm performance against HOT, but the gain against PM might make up for it.
I think I might have something which keeps full functionality but also reverses with a 0.08 probability. The problem is, it also reverses with any enemy bullet fire, so should I decrease that probability? I'm thinking down to about 0.06, since there needs to be a good chance of a direction change happening during the flight time of the bullet, but there was already one at bullet fire time so we don't want it reversing all over the place. Or should I stick with 0.08?
Never mind, I figured out a way around that too, all while using even less codesize than our previous reverse method, so I added back setAdjustGunForRobotTurn(true). Being able to feed custom variables to a random multiplier can do miraculous things! Particularly when you only want probabilistic behaviour, and not absolute behaviour. But hey, a probability of 1 in 20k is pretty much 0, right? ;-)