BulletHitBullet behaviour

Jump to navigation Jump to search

BulletHitBullet behaviour

Currently I am busy with transforming my rough 'black' shadows (setting risk to zero) to more sophisticated 'gray' shadows, reducing risks depending on how much shadow is present per bin. Also due to Bullet Shadow/Correct. The problem is now that I get hit quite often while under a shadow (15% of the hits) or that I get a BulletHitBullet event just outside the shadow (also 15% of the events).

When determining the wave that hit me (or my bullet) I use the enemyBullet location as hit-location, and compare the distance between firelocation and hitlocation with the distance the enemybullet would have traveled. For real hits it is always spot on, only some rounding behind the comma. For BulletHitBullet hits, it is always 1 bullettick (70%) or 2 bulletticks (30%) off.

So basically, I don't trust my shadows as the BulletHitBullets don't line up with the real hits. Does anyone of you have the same experience and has any solution for my problem. I do know that I don't do everything perfect yet, f.e. I don't remove shadows on other waves when there is a BulletHitBullet event.

GrubbmGait (talk)16:07, 28 June 2021

According to Robocode/Game Physics:

  1. All bullets move (including the bullet fired in the last tick) and are checked for collisions.
  2. All robots move (gun, radar, heading, acceleration, velocity, distance, in that order. gun heat is also decreased in this step).

However there are details not noted. If bullets get collided, they are moved back 1 tick. If bullet get collided before it moves (due to order of updating), they are also moved back 1 tick, resulting 2 tick behind in total. I remembered doing same thing, and discovered correct bullet shadow, but did not implement due to having problems with integral risk.

Xor (talk)16:26, 28 June 2021

Ah, thanks for the info, so I am doing it the correct way. Now I only have to hammer the details right.

GrubbmGait (talk)17:02, 28 June 2021