I'm quite sure we already know what lag means, TS :)

Make the timer client-side only if isn't already?

I think that the grenade timer is already Client side, because I can conc somewhat efficiently with 200 ping, whereas it was a nightmare in TFC when it was server side.

But the sound happens on server, doesn't it because you can hear when people prime ?

Yes, but being able to hear when other people prime a grenade has nothing to do with your own grenade timing, I guess, which is what matters. The server just reproduces the start sound for everyone so they know what you are doing, but you get it client side. Pretty much like jumping grunts or footsteps.

i think the timer-sound is client-side since its not affected by your lag. If it was server-side (or delayed) then it maybe stays sync with the real gren-timer ... and thats what im hoping for

The timer is client-side and does not lag. The priming *click* does lag a bit depending on ping. What I do is turn off the timer and replace the click sound with my timer of choice. As far as timing concs it's a little better, but not perfect. As a side benefit I hear timers for everyone else's grenades, which comes in handy. :)

Global Timer FTL!

Yes, yes it is.

Can this be made client side only too? Never liked that part of ff grenade mechanics. I miss those mysterious tosses when the victim couldn't tell how long I had the grenade primed.

this confuses me. the timer is client side yes but with lag its usless cause its off independently from when the gren goes off. Why isn't the timer with the click sound??

I think this is what the OP wanted and something I've wondered. Otherwise tell me how useful a timer that isn't correctly timed is..

The problem client-side: The timer starts as soon as you press your grenade key, yet you have to send data to the server telling it you primed the grenade which in turn results in a delay when the grenade is actually primed (the timer is ahead of time).

The problem server-side: The timer starts after you send the key press. The server receives the data, then sends data back telling you to play the timer sound (the timer is behind time). This method is even worse because you have to send data 2 ways instead of one.

Best solution:
Since it can't be 100% accurate the best solution would be to start the timer client side and adding a delay depending on the clients latency.

maybe i'm wrong, but i've thought i thought it was simple. here's how i've assumed a hand-held conc-jump works:

1) you press and hold your conc button: your gren timer immediately starts playing, and "i just primed a conc" command is sent to the server.
2) server recieves the "i just primed a conc" command x seconds later (where x is your latency): server then sends out "player y has primed a gren" to all players.
3) all players recieve the "player y has primed a gren" command x seconds later: all clients nearby play the gren "prime click" sound (hence the time that you hear this "prime click" will be delayed from the time that you pressed the button to prime your conc).
4) you press the jump button to do your conc jump: "i just jumped" command is sent to the server.
5) server receives the "i just jumped" command x seconds later: server calculates your conc-jump accordingly.


now then, the important points in all this are:

a) your "i just primed a conc" command and your "i just jumped" command have both been delayed by exactly the same amount of time (assuming your latency doesnt vary in the meantime ofc). therefore the timings with which you have to press and hold your conc button and then press your jump button in order to do the exact same conc-jump will NOT vary at all for players with 10 ping or 1000000 ping, and importantly they will also always be the same relative to the gren timer.

b) the time that you hear this "prime click" WILL be delayed from the time that you pressed the button to prime your conc. the delay will probably = [ 2*latency + cl_interp ].


have i got something badly wrong? if i'm right, i don't understand why carl would want to disable the client side timer (which is connection independant) and instead use the "prime click" as his gren timer (which is connection dependant), as doing this means you have to do different timings for different latencies. so erm, yeah, maybe i'm just wrong :)

In practice, with the client-timer, I often have to jump quite late. It's more useful to ignore the click and count off from the click.

There's no delay when hitting jump (because of prediction, certainly). Does the server use your predicted trajectory when the conc goes off? It seems that way to me.

But then, I miss concs on a LAN; I'm not really a master who'd be sensitive to a few ms. If I don't launch myself into the floor I'm happy.

All I used to do at the end of my TFC days was to conc. I went to conc servers constantly, and rarely pubbed. I could adapt to lag, but one thing since FF was released that I noticed, you cant do drop concs. If the level has a jump that's too far down, once it reaches a certain velocity, the conc dissapears.

That was also an issue in TFC. For example, the 1st tube on exist jump 2. You couldn't prime at the top and drop the conc down for the very end, you had to juggle down.

one way to fix THAT problem would to define a maximum velocity, just behind the threshhold of dissapearing.

Use the visual timer. It's never wrong.

The audio and visual timers are already client side and are as accurate as we can get it.

If your ping is exactly the same when you press prime, and when you press jump, the timers will be accurate. If you have 300 ping when you press prime, and 30 ping when you press jump, then your jump will be 270ms too early and you'll conc lower than normal.

If you have a stable ping, whether high or low, the timers should be correct. However, I have also noticed the timer being slightly off at higher pings.. i can't think how that would be possible, or how to fix it, though... (i usually compensate by jumping slightly late)