You can count the number of MicroBots using GuessFactorTargeting on one hand I'll bet. Add this one to it. Its gun is probably one of the best there is for a MicroBot, and it sports a reasonably unpredictable random movement.
Random distances in either direction, roughly perpendicular to the enemy. Tries to stay at about a medium distance.
It doesn't, it just sort of hopes it's unpredictable enough to not get hit too often.
It was designed with only the OneOnOne aspect in mind.
Selection is not in its vocabulary (but Fhqwhgads is?)
Between rounds it saves its stat buffer and other arbitrary variables. Between matches it saves jack.
See the page on Fhqwhgads
I suppose so, as long as you conform to the KawigiPublicLicense (KPL).
When I figure out how to improve its movement, I'll probably sacrifice colors and some other things for it.
Not really, the next one will probably be Spark, though. The variations in bullet power probably throw of its movement.
Funny thing happened in testing...
kawigi.f.FhqwhgadsMicro 1.0: Exception: java.lang.ArrayIndexOutOfBoundsException?: -1 java.lang.ArrayIndexOutOfBoundsException?: -1 at kawigi.f.FhqwhgadsMicro$MicroBulletEvent?.test(FhqwhgadsMicro.java:135) at robocode.peer.robot.EventManager?.processEvents(EventManager?.java:653) at robocode.peer.RobotPeer?.tick(RobotPeer?.java:1024) at robocode.peer.RobotPeer?.turnRadar(RobotPeer?.java:1086) at robocode.Robot.turnRadarRight?(Robot.java:1001) at kawigi.f.FhqwhgadsMicro.run(FhqwhgadsMicro.java:37) at robocode.peer.RobotPeer?.run(RobotPeer?.java:616) at java.lang.Thread.run(Thread.java:536)-- Kuuran
Yep, F-Micro does no bounds checking. That's why it's last in melee, it will just about always crash if there are multiple bots to see. -- Kawigi
I didn't say it never happens in OneOnOne, just that the same problem is why it's last in melee. Although it seems to happen rarely in one-on-one battles, it seems that when it does it might disable F-Micro for the rest of the battle. Did you observe that? The next version will probably have room to have this fixed. -- Kawigi
Yeah, it decided he's still in his Condition.test() for the rest of it. If you calculate your GFs a little more carefully you shouldn't need boundary checks, should you? -- Kuuran
If I scan a little more carefully I shouldn't, there's something of a buffer in there for error beyond the bounds. I suspect the problem is when he skips scans right before the wave would have hit you (or reasonably close, it's probably more likely to happen when the wave travel time is shorter). Since he's using the same radar as the nano-pattern-matchers, he skips 7 scans at a time sometimes. I'll probably fix it by using some Math.min(30, Math.max(0, lkdj;ldjkkl;ddjl;k)); action. -- Kawigi