Just to verify if I have this correct, since I'm no math expert:

BulletETA is the estimated time of arrival of a fired bullet.

It does NOT originate from the center of the firing robot, but bulletvelocity V = 20-power*3 away in the direction fired. That means that you have to substract that from the distance D when calculating the BulletETA.

Robocode is a discrete system where time is always a whole number, meaning you'll have to round off your calculated ETA. If you assume that your wave hits the enemy at or beyond its center then you have to round to the next whole number (Math.ceil()). If you assume that your wave hits when it's as close as possible to the opponent's center then you have to round in the regular way (Math.round)).

so, the formula for calculating ETA with a given distance D and bulletvelocity V is:

ETA = Math.ceil((D - V) / V)or

ETA = Math.round((D - V) / V)

right?

--Vic

While implementing WaveSurfing i was in need of a very precise calculation of the ETA and my tests revealed that there is a chance the bullet travels up to 2 * V in the tick of impact. I know that this sounds rather strange, so i tested several times. There is a function setFireBullet in AdvancedRobot, that returns the bullet that was fired. So i wrote a stationary bot that shot with setFireBullet at SittingDuck, and logged the position of the bullet for each tick until impact. The result:

- the bullet is created immediatly upon a call to setFireBullet at the exact position of the shooting bot, and is advanced one tick after a call to execute
- any tick before impact the bullet travels distance V ( = 20 - 3 * power)
- the last tick (the tick the bullet arrives) one would expect that the bullet travels a distance less or equal to V. But in these tests there were also situations where it travelled more than V but less then 2 * V. Sure, the easier explanation would be a bug in my test robot, but i couldn't find one. So it looks like a bug in Robocode to me.

All in all that leads to:

Math.ceil((D - V) / V) <= ETA <= Math.ceil(D / V)where D is the distance at shoot time, and V is the bullets velocity

--Mue

Thanx Mue, basically it seems you came up with the same formula I did, only I did not observe this bug you mentioned. --Vic

(edit conflict) Yep, i just wondered whether this 'the bullet is advanced immediatly one tick'-opinion (which i read alot while looking into WaverSurfing? on the wiki) is just to compensate this bug, or how people got this idea. My test seems to show that the bullet is not advanced immediatly on firing, and just the bug during impact sometimes let it look as if it were. --Mue

Well, I do use that 'the bullet is advanced immediatly one tick'-opinion and it seems to be perfect 100% of the time. I could not reproduce your bug. Maybe someone else has a good observation on this? --Vic

My ETA (calculated at firing time) now is equal to the ATA (ActualTimeofArrival?), measured as the waves hits the opponent, 100% of the time. I tested against SittingDuck firing random power bullets both when my bot is moving and when it is stationary.

ETA = Math.round((D - V) / V)

This is how I determine when a wave hits:

wave hit when: (D - Radius) <= (V / 2);

--Vic

Well, if you measure the time until you wave hits, i'm not surprised you can calculate the exact ATA :-), since you youself wrote the code that advances the wave. I was actually talking about the time of the corresponding onBulletHit?-event... --Mue

I did not write the above paragraph to surprise anyone with my brilliant ATA calculation, but rather to help newbies or the mathematically challenged like myself not to make these mistakes :-) It's actually very easy to make mistakes in both calculating ETA and measuring ATA. In the ETA case I found I was simply using ETA = D / V. I would not be surprised if a lot of people actually do that.

In the ATA case, I had misaligned my waves by advancing the bullet immediately by the robot radius (=18), instead of 20-3*Power. That radius thing was something I read about on this Wiki a long time ago. After correcting this I could visually confirm (using RobocodeGLV014) that the waves were perfectly aligned with the actual bullet.

You are right aligning to an onBulletHit? event is a different story. That's why I couldn't reproduce that bug you mentioned. If I recall correctly, I also had problems with aligning onBulletHit? events with my previous bot Ender.

--Vic