calling execute() every tick

I notice you only call execute() once during your run() method, not in a loop. Is that new? Don't you need to call execute() or another blocking method every tick?

That execute() was just an instance of me trying to stop the do-nothing-this-round bug. When deBroglie does nothing on a round, the radar isn't spinning.. despite the infinite radar spin in run().. yet onSkippedTurn is still never triggered.

I don't have any calls to execute(). Everything is in onScannedRobot()

Question: in a 1v1 match, can onScannedRobot trigger more than once? That right there might be a source of some of my problems.

deBroglie's structure would allow a movement(), gun(), execute() loop in run().. and just update the Universe object in onScannedRobot. I think some of my bullet/wave code would need tweaking because the gun and movement might be operating on a one-tick-old Universe.. but I think that can be dealt with.

I don't think you should get 2 scans in one tick, but I did find oldwiki:DoubleScanning the other day, where David Alves said: "f you skip a turn before handling the ScannedRobotEvent for that turn, you'll get 2 ScannedRobotEvents on the next turn. You only miss lose events if you skip 2 or more turns in a row, if you miss one you'll just get extra events on the next turn."

My guess is that this is likely to have long ago been fixed, but I don't know for sure. It seems like Wompi and I have found some similar issues recently, so maybe something like that could be happening?

Having everything in onScannedRobot except a turnRadar in run() makes sense, but I thought you'd still need the turnRadar in a loop, wouldn't you? If you skip a turn and your radar slips, will it ever move again?

No, if the radar slips, I'm well and truly out of luck. Interestingly enough, my weird rounds (when I have battles slow enough to observe visually) seem to happen right from the word go.

might be worth exploring the idea of getting a non-onScannedRobot Universe update method, and put everything I can in run()?

Those rumble rounds (with about 6 bots on my rumble client, MN's and KID's it looks like) with completely zero score are concerning to me too.

Interestingly enough, if I put an execute() at the end of my onScannedRobot(), my debug graphics for waves fired from the enemy are off, as if I didn't tag the wave until one turn too late. *head scratching*

I get the feeling once I really figure this whole mess out and resolve it, my bot's scores will benefit greatly.

Sorry if i'm wrong (i'm a little drunk because of the soccer EM). I think your radar can miss the target in the first search procedure. If the target moves very unlucky you end up with a sitting duck. It happens sometimes that you hit the target under an very bad angle/velocity and than the radar won't lock at the first hit. Looking at your code, i think this would lead to a sitting duck straight from the first round. I think you are better off with something like

public void run()
{
      ....
      while(true)
      {
            if (getRadarTurnRemaining() == 0) setTurnRadarRight(Double.MAX_VALUE);
            excecute();
      }
}

I don't think you have to move all your onScannedRobot(..) stuff to run(). This would lead to some other issues if you miss/skip some turns.

For the execute() at the end of onScannedRobot(..). The paint event has a priority of 5 (i guess) and comes after the onScanned.. so if you end your turn before onPaint(..) is processed you won't get any graphics. Not sure about the priorities now but it is something around this i guess.

I try to have a closer look at this tomorrow ... not sure on what time shift you are :) but maybe it helps right now.

Take Care

I agree having everything in onScannedRobot for a 1v1 bot is reasonable, and is a setup I've used in some bots. I just have an infinite loop in run() like Wompi put above.

I see your initialization code only runs in the first round. I don't know what's happening, but if your bot throws an exception in the initialization in the first round, you'd be dead in the water. I usually check for null... but at least this way it's really obvious something is wrong, which is probably a good thing.