Talk:Robocode/Game Physics

I need to know percisely, which might involve rotating a rectangle, I don't know, if a point intersects my bot, given its X and Y location. Remeber that in Robocode, Y is reversed. While I'm at it, I might just ask: What your opinion is on whether I should do surfing or anti-gravity movement to dodge predicted bullets my robot simulates? --Awesomeness 21:52, 3 May 2009 (UTC)

The 'hitbox' of a robot is always a non-rotated square at the bot's location, so the former check is very very simple. As for your second question: It depends. Surfing is going to be stronger almost surely, however anti-gravity movement is considerably simpler. My suggestion would be to do anti-gravity for now, and at a later date try surfing once you feel comfortable with exactly how it works. --Rednaxela 22:01, 3 May 2009 (UTC)

Oh, is it a 40 pixel long sqare? that's what it looks like. --Awesomeness 22:43, 3 May 2009 (UTC)

No, it is 36px non-rotating square. » Nat | Talk » 23:42, 3 May 2009 (UTC)

I've been trying to track down a weird bug that makes DrussGT occasionally not be able to identify one of its bullets in an onBulletHitBullet situation. The bullet I get in the onBulletHitBullet handler gives a getX() and getY() to a point which is one tick behind the one I have stored from fire time. This only happens rarely, once every ~100 or so bullets, but it's enough to make DrussGT crash with some new optimizations I've added, and enough to prevent the wave shadows from being cleared in certain circumstances.

I'm also not sure which one is giving the incorrect results, the setFireBullet Bullet or the BulletHitBulletEvent Bullet; if it's the former, it means that every so often my bullet shadows are incorrect, which would also explain why I get hit by a bullet which is inside of a bullet shadow several times a battle against Diamond.

So, any ideas of how on earth this might be happening, or the best way to mitigate it? Would somebody please check if this happens to them as well? I'm using 1.7.3.2 as a dev environment.

If you just match the bullet within a distance of 50 and also match the bullet power to 1 decimal, there should be no room for error, right? At least in matching to the right wave. I think I've always done it that way, probably going back to the point where my wave management was buggy enough that I just compensated for it.

In fact I thought the *HitBullet methods used to return points not even along the line the bullet traveled, though again that could have been buggy wave management. But I thought it was something Fnl fixed at some point.

That is pretty funky and I'd def like us to track it down and fix it. I'll run some tests when I get a chance.

onHitByBullet events return bullet coordinates after it hits you, and onBulletHitBullet events return bullet coordinates before it hits the other bullet. If you reuse the same code for both events, you have to adjust time accordingly. I stumbled on this while tracking a wave detection bug in Combat a while ago.

But surely both Bullet objects should show the same location even after a hit? ie, the one from setFireBullet and the one from BulletHitBulletEvent? They both represent the same simulated object. They should stay in step with each other.

They both represent states of the same simulated object. Maybe the Bullet instance returned from setFireBullet is updated every tick while the instance returned by BulletHitBulletEvent isn't, but only debugging the Robocode engine to be sure.

I agree this is a silly bug and it sucks that it's causing you problems, but I'm kind of surprised you are using these Bullet objects this way at all. I just check if setFireBullet returns null and if it's not I mark the appropriate wave. It never even crossed my mind to store the Bullet object or use any information from it. :-)

I'm actually using it as a pass-through between my gun and movement so that I can mark the enemy waves with the correct shadows. I could always make a class that has bullet power, firetime and initial fire location, but that's essentially what the Bullet object already is so I thought I'd rather just use the built-in one =) A bit of my codesize-restricted mindset weighing in, perhaps.

Ah, that makes more sense. Indeed I do duplicate that in my own class for the gun/movement linking of bullet shadows.

(Not sure if you're joking about your focus on code size... =) jk)

At one time, I was using the bullet objects for matching things up. I stopped doing that after the bug in 1.7.3.0 where the bullet objects in the events could no longer be compared against the one from the setFire method. Now I use my own bullet objects, kind of like what Skilgannon mentioned as a possibility.

I thought this was fixed in Robocode 1.7.3.2....maybe it was, but a lot of us are still running 1.7.3.0 (in part because 1.7.3.2 is not available on the web, and newer versions are not currently supported by the Rumble). Furthermore, I thought this was the bug that broke Krabby2, but I see it's scores are not improved with 1.7.3.2 (if you look at it's history, you will see much better scores for clients from version 1.6.1.4).

At one point when I was just starting out kept the bullet object, but things didn't seem to ever match up at the time (I probably just didn't know what I was doing). So I ditched it.

So yeah, I just fudge it now too. If it is within x of a wave, and that wave is the closest, then that wave is the wave the bullet is from.

But for longest time I had this weird bug in my detection which I finally found out was an enemy firing on the same turn it died (thus I could not detect its firing). So I just kept the heat wave, which solved the problem most the time.