hit zone bug

[LongDon]

Hi all,

snick thinks he found a bug in 2.x with the hit check depending on the fps used. He created a map, added a world weapon firing shots to a bouncing tank. Shot height was 1.57m, tank height 2.07m (snick said that to me):

Code: Select all

Frames per second    height under tank      hits
15.000000                  Z 3.407011               394 
30.000000                  Z 2.631972               329 
60.000000                  Z 1.971943               209 
120.000000                Z 1.830598               164 
240.000000                Z 1.651825               156 

First column describes the used frame rate. Second column is the maximum height a tank got hit by the world weapon. Last column shows how often in the measured interval the tank got hit.

You can see that depending on the frame rate the hit check must be calculated wrong since the tank got hit while being high in the air (1.9m over shot heigth).

He already talked to some dev which were (as he said) only interested if that bug was in 3.x too. But until 3.x is released and world wide used some time will pass by and the bug should be fixed in 2.x.

[joevano]

My feeling is, the bug has been there for quite some time, and it seems to penalize you for low frame rates. It isn't horribly noticeable while playing (ie does not affect game play horribly bad). We are having a hard enough time getting 3.0 out the door, it just is not worth fixing in 2.0.x IMHO.

I would say "Patches Welcome" at this point, but the 2.0.x code base is not under active development, so it probably wouldn't help.

[JeffM]

the bug can't really be fixed in 2.0.x

you can turn on your fps limiter now.

if we were to try and fix it in 2.0.x those that want to abuse it would simply stay at a broken version.

There is simply no way to ensure that everyone will use a fixed version unless it breaks protocoll.

We have been aware of the various physics bugs for a long time.

[snick]

Hi all,

snick thinks he found a bug in 2.x with the hit check depending on the fps used.
He created a map, added a world weapon firing shots to a bouncing tank. Shot
height was 1.57m, tank height 2.07m (snick said that to me):

Hi. I rather hope I said 2.05m. But that's a minor quibble. 0.02m is neither here nor there
in a whole universe of lag

I would say "Patches Welcome" at this point, but the 2.0.x
code base is not under active development, so it probably wouldn't help.

The problem is still there in the latest 2.99.x SVN. I would consider submitting a patch,
time permitting. But it's not quite obvious what the original intention was (if that is
still something to aim for). What I mean is: we have to decide what shape and size
hitzones we would like.

Now, it looks rather like the original coder(s) tried to define a hitzone as the intersection
of two volumes (rectangular cuboid and sphere). But I cannot be completely sure that was
their intention.

At a guess, a fairly trivial change would give you completely spherical hitzones that don't
vary with framerate. Not quite to my taste, mind you.

I would like to tentatively suggest these solution contraints:

(i) Hitzone volumes should remain a constant shape and size. They should not be
affected by the angle of a shot, the speed of a tank or framerate etc.

(ii) Hitzone volumes should be somewhat similar to what we have now for an immobile
tank and shots that run parallel to the ground (this case at least appears to be
handled reasonably well by the existing code). For example, you might choose to
go for a cylinder of similar dimensions.

(iii) Hit calculation should be efficient. This is the tricky one! It's easy to achieve
(i) and (ii) if one ignores efficiency. And I think it's plausible, though not certain,
it was trying to achieve efficiency at the expense of correctness that got us into the
situation we are in now.

[snick]

For a demonstration of hit detection weirdness, try this map:

Code: Select all

# Collider

options
  -mp 0,0,0,0,0,2
  -j
  +r
  -ms 3
  -srvmsg "Large Bullet Tank Collider"
  -set _worldSize 100.000000
  -set _shotSpeed 10.0
  -set _shotRange 105.0
end

weapon
 name ww
 position 0.0 0.0 0.0
 rotation 0.0
 tilt 90
 color 0
 initdelay 2.0
 delay 3.0
end

material 
   name mat1
   diffuse 0.7 0.7 0.2 1
end 

zone
   name spawn
   position 5.0 5.0 0.0
   size 0.1 0.1 5.0
   rotation 0.0
   team 0 1 2 3 4
end

pyramid 
  position 0 0 2.30
  size 1 1 -1
  rotation 0
end

box
  position 0 0 3.30
  size 1 1 15
  rotation 0
  matref mat1
end

[Hint: place the centre of your tank under the nasty looking pyramid]

Map also available here: http://pastebin.ca/raw/1330744

[An SQUERRILz]

These two maps demonstrate the same bug, showing that something as trivial as the world size can affect whether you die.

Code: Select all

options
  -sb
  -set _shotSpeed 10
  -set _flagEffectTime 0
end

world
  size 75
end

weapon
  pos 0 0 50
  initdelay 5
  delay 3
  tilt 2.29
end

zone
  pos 0 0 52.975
  size 0 0 0
  team 0 1 2 3 4
end

box
  pos 0 0 52.975
  size 20 20 .000001
  shootthrough
end

material
  color 0 0 0 0.7
end

arc
  pos 0 0 52.975
  size 4.7 4.7 1
  divisions 4
  ratio 0.000001
  rotation 45
  matref 0
  shootthrough
end

Code: Select all

options
  -sb
  -set _shotSpeed 10
  -set _flagEffectTime 0
end

world
  size 74
end

weapon
  pos 0 0 50
  initdelay 5
  delay 3
  tilt 2.29
end

zone
  pos 0 0 52.975
  size 0 0 0
  team 0 1 2 3 4
end

box
  pos 0 0 52.975
  size 20 20 .000001
  shootthrough
end

material
  color 0 0 0 0.7
end

arc
  pos 0 0 52.975
  size 4.7 4.7 1
  divisions 4
  ratio 0.000001
  rotation 45
  matref 0
  shootthrough
end

GU players can see a common instance of the bug on replay at bzflag.enuffsaid.co.nz:5159, match on *20110220-124244* (valid for ~2 months).