NS1 3.2 Issues

22:21.15 <puzl> at frame X, if you deem a bullet should have fired at t(X-a) then you can adjust damage
22:21.23 <puzl> but it would be rife with innacuracies and rounding errors

23:01.10 <jiriki> if you are going to increase the damage of a bullet depending the fps, wouldn't it give more damage per clip then?
23:01.26 <puzl> no
23:01.30 <puzl> what you would do is this
23:01.59 <puzl> you would track how much fire time is lost due to lag
23:02.13 <puzl> and adjust it upwards to compensate when you have lost 1 bullets worth of time
23:02.18 <puzl> and then subtract an extra bullet from the clip
23:02.33 <puzl> that's the only real solution I can think of that solves it server side only
23:02.44 <jiriki> oh right okay
23:02.52 <jiriki> so it'd give marginally better accuracy?
23:03.22 <puzl> yeah, but it could(in theory) increase the dps beyond 200, but only slightly if at all
23:03.27 <puzl> which is the major problem with it
23:03.46 <jiriki> yeah I guess the question is how big is the rounding delta
23:03.46 <puzl> the correct way to do it is to compress the bullet space to compensate for a delay
23:05.05 <puzl> well, if you compress the inter-bullet gap, you'd get bullets like this
23:05.50 <puzl> 0.11, 0.22, 0.33, *0.44, 0.5*, 0.61, 0.71 etc..
23:06.14 <puzl> so at the frame when the bullet is fired at 0.44 you set the next bullet to occur in .06 seconds insead of the usual .1 seconds
23:06.28 <puzl> but then you'd get some weapon sutter on the client
23:06.53 <puzl> tbh, I think I'd have to experiment with this for some time before I get a feel for what is really feasable
23:07.02 <puzl> somet hings that are simple in AMXX are  anightmare to code in the sdk
23:07.12 <jiriki> just wondering, wouldn't it be easier to fix on client?
23:07.38 <puzl> well, you fix it in one place, and it gets compiled twice
23:08.20 <puzl> the important thing here is the server fps
23:08.29 <puzl> only the server fps allowed this problem to manifest
23:08.41 <puzl> you need high server fps and high client fps to see the problem

--

I'm going to ignore weapon upgrades for the purpose of this
discussion, as they have no bearing on understanding the underlying
flaw in the engine.


If you look in the Balance.txt file in your ns folder, you'll find:
#define kHMGROF 0.10
#define kHMGDamage 20


This is the rate of fire of the HMG and the damage per bullet.

So the HMG fires every 0.10 seconds, or 10 times a second and
therefore the damage at 200fps you cited is the [b]correct[/b] damage
of the HMG.

It has been suggested that the drop in damage at 111 fps is due to
rounding of floating point or some sort of rounding for more efficient
network transmission of floating point numbers, but this is not the
case.

The HL engine process activity per frame.  If your framerate is not an
even multiple of a weapon's rate of fire then the next bullet will be
delayed until the one right after the inter-bullet gap has expired.

This is why the graphs that a_civilian put together are a saw function.
http://img237.imageshack.us/img237/7928/lmgrofal1.gif

I'd have to do some research on how to fix this with a server-only
patch.  We could track the inter-frame gap and try to compensate for a
late bullet by multiplying the damage it by the gap/rof.  So if we are
only firing 90% of the bullets we should be
we could do 100/90 extra damage per bullet to compensate, but this
would be rife with rounding errors.

Now, onto the jetpack:
The jetpack situation is different and a little more complex.   The
thrust/lift from the jetpack was, in 1.04, applied per-frame and this
is what caused the infamous imbalance with the JP back then.  It was
sort of fixed in 2.0 in that lift is applied at a rate modelled at
100FPS, *but* you have the same problem that occurs with with the
weapon ROF occuring here - i.e. the jetpack lift isn't applied until
the frame after it is due to be applied.

The second problem with the jetpack is that directional movement is
still applied per-frame.  So if you want to move left or backwards
with a jetpack you will be much more effective at 200fps than at
100fps, and this really should be fixed and can be fixed BUT it
probably will require a client patch to avoid jittery jetpack
movement.