LongDon wrote: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
joevano wrote: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
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.