User talk:BenHorner

onBattleEnded()...

Isn't this event supposed to be called win or lose (or abort) at the end of each battle? I'm not sure if this means at the end of each round, or at the end of all rounds, but I don't think it's getting called ever... Am I doing something wrong? --BenHorner 23:02, 25 June 2009 (UTC)

Is called only at the end of the battle, after all rounds or if you click the stop button on the gui. You can use onWin and onDeath to know when a single round is over and how it ended. --zyx

anatomy of a turn

Here is what I currently have for the seuqence of processing during a turn, the reference I got it from is no longer a valid web page, it was the help link from: http://robocode.sourceforge.net/ which now redirects to this wiki. =)

• each turn these things happen in order:
  • time is incremented
  • bullets move and check for collisions
    • BulletHitEvent data collected
  • robots move
    • bullets are fired (energy is charged for firing)
    • adjust heading
    • adjust acceleration
    • adjust velocity
    • adjust position
  • ScannedRobotEvent data collected
  • events are fired in priority order using previously collected data
  • robots execute their run() method until their thread is blocked (through action, or time out)

Does anyone have anything to add to the above? Or change? I always thought that all the events would fire at once, and you would receive them in order of the priorities you set... I assumed they all fired where it says "scans are made" above. I'm also wondering, if it is unintuitive, at what point a robot's energy is charged for firing? Thanks for any help on this one. --BenHorner 21:19, 25 May 2009 (UTC)

Just realized that the original source of my info was this: http://robowiki.net/w/index.php?title=Robocode/Game_Physics it just changed locations I guess.

Well, robots are given events 'all at once' at the begining of the "robots execute their code" stage, but the event objects are actually generated prior to this though, during all the other stages listed. For example, relating to the "discrepancy" you noted below:
1) The BulletHitEvent data storage object, is created during the "bullets move and check for collisions" stage, before the robot has fired or moved or anything.
2) The robot actually fires/moves/etc during the "robot move" stage, this is when the robot has an energy change for firing.
3) The ScannedRobotEvent data storage object is created during the "scans are made" stage.
4) The things like onBulletHit() and onScannedRobot() are called, in order of priority, at the start of the "robots execute their code" stage, after steps 1 to 3, using the event objects created before.
Does this explain things? :) --Rednaxela 04:24, 26 May 2009 (UTC)

I haven't fully digested it, but I appreciate the information! Are you saying that "bullets move and check for collisions" includes the bullet that the robot is about to fire during the "robots move phase", or is it just bullets that were fired in previous ticks? I've adjusted my outline above, if you have other information that could be inserted, please let me know! --BenHorner 02:36, 27 May 2009 (UTC)

No, "bullets move and check for collisions" doesn't include the bullet that the robot is firing in the "robots move phase". That bullet never exists until the "robots move phase" and at that phase is generated at the center of the bot at the begining of that phase. --Rednaxela 04:05, 27 May 2009 (UTC)

discrepancy between HitRobotEvent and ScannedRobotEvent?

I was wondering if anyone else has noticed a discrepancy between the enemy energy reported by the HitRobotEvent, and the ScannedRobot event...? I have my bot which currently doesn't move, going up against Crazy in 35 round battles to test my radar and bookkeeping code. It seems like about twice per (35 round) battle I get a discrepancy of exactly 0.1 energy points. I believe the HitRobotEvent happens first, and reports lets say 54.60 for the enemy energy, and in the same round a ScannedRobotEvent happens reporting 54.50 for the enemy energy. This is a small difference, but I'm wondering if I should be accounting for fuzziness (something like sensor noise) in my bookkeeping code, rather than planning for exactness. Does this kind of thing happen many places? --BenHorner 17:11, 25 May 2009 (UTC)

I haven't checked anything like that, but I only trust the onScannedEvent energy value, maybe something happens after the robots hit. --zyx 19:04, 25 May 2009 (UTC)

I have a theory about this that I believe is very compelling... Consider the following: 1) bullets moving is processed before bullets are fired, 2) scanning is processed after bullets are fired. If the enemy fired a 0.1 power bullet on the same tick as being hit, then of course there would be a discrepancy, due to the bullet hitting them being processed first. --Rednaxela 20:05, 25 May 2009 (UTC)

I'm still seeing this happening, I've just put off digging into it to see if it's really some kind of bug. I don't think that it's related to bullets being fired though. It seems like about once out of every ten times I see this happen, it happens two ticks in a row... Here is a snippet from my console:

=========================
Round 74 of 500
=========================
HistoryEventListener.onHitRobot() had conflicts
 nrg(37.60e)
 tm(1561.00t) nm(sample.Crazy) nrg(37.70e)
HistoryEventListener.onHitRobot() had conflicts
 nrg(36.90e)
 tm(1562.00t) nm(sample.Crazy) nrg(37.00e)

The log shows the value that overwritten value that conflicted, and then the value it was overwritten with. It looks like he Crazy must have fired a bullet of power 0.6 (or maybe hit me, or a wall, I think one of those is 0.6 damage) on turn 1561, and then the discrepancy occurred again on turn 1562. If he had fired a bullet and caused the discrepancy on turn 1561, then his gun would have been hot on turn 1562, and he couldn't have fired again and caused the discrepancy again... I'm sure I'll figure this out some day, it keeps showing up in my energy reconciliation routines... --BenHorner 02:38, 7 June 2009 (UTC)

I'm not sure I follow your scenario, but it sounds like you're proposing that the sequence of processing might account for the discrepancy? It was my impression that all the events fire without any state changing... That the calculations of state changes for the robots are made in a separate block of time than the events firing, is that not true? The only way this discrepancy could be legit is if some state of the robot (specifically it's energy value) is changed in between onHitRobot() being called and onScannedRobot() being called. (Or if those events are not reporting the then current state of the robot) --BenHorner 20:41, 25 May 2009 (UTC)

See my reply in the above section :) --Rednaxela 04:24, 26 May 2009 (UTC)

min/max/avg battle length (in turns/ticks)?

Can anyone give me a feel for how long battles average? I want to use an array list to keep track of the ticks as they go by, for the random access, but I'd rather not make it reallocate itself unnecessarily often, especially when it's big. Thanks for any help. --BenHorner 23:48, 24 May 2009 (UTC)

Obviously it varies, but for 1v1, I usually ballpark it as 700-800 ticks per round. I think 25k in a 35 round battle is a good estimate. --Voidious 00:01, 25 May 2009 (UTC)

But for wave surfer battle, is usually over 1,000. I think it's around (for surfer) 1,300 - 1,500 ticks. » Nat | Talk » 11:53, 25 May 2009 (UTC)

So surfers get hit by bullets way less often? I'm really going to have to look into that sooner or later. --BenHorner 14:24, 25 May 2009 (UTC)

Sorry, to make more clear, a battle with two wave surfers are over 1,000 ticks since the well-implements surfers usually almost dodge every enemy bullets, I have to said well-implements since some surfer, like BlackHole 0.1.11 cannot dodge even HOT (really, I had broke something in it and I don't wanna fix it). And even perfect AS gun can't make over 50% hit rate now. » Nat | Talk » 14:47, 25 May 2009 (UTC)

Well, not just because of that. Also because most wave surfers favour huge distances compared to most other bots. About 400 is a typical wave surfer distance for instance, whereas many smaller bots prefer 200 to 300 distance from what I see. --Rednaxela 15:47, 25 May 2009 (UTC)

I really don't think 1v1 battles ever last 1300 ticks per round... I just fired up some Dookious vs Dookious and Dookious vs Ascendant battles, and the longest round I saw was mid-700s. I'm not sure surfers have anything to do with battle length. Things that would make a battle long are firing low power bullets and/or the battle being close (so the longest-living bot gains back as much energy as possible before dying). --Voidious 15:54, 25 May 2009 (UTC)

Obfuscater

Well, if you want to get yGuard working, some ant build fill will take care of that for you. The Ant page is sightly outdated (the task use in there is deprecated by now). A more updated version is available at User:Nat/Ant Build File. Hope you will get it work. If you have any questions, feel free to ask. (there is actually other obfuscater, but much harder to use.) » Nat | Talk » 12:41, 4 June 2009 (UTC)