Fortress Forever

Go Back   Fortress Forever > Projects > Fortress Forever > Feature

ping-dependant delay of the grentimer-sound Issue Tools
issueid=72 01-11-2009 01:04 PM
Interzone technican
ping-dependant delay of the grentimer-sound
like he said ...

Hi there,

playing on high-ping connections isnt fun and one of the most annoying effect is the gren being late compared to the grentimer-sound. Maybe you could delay the grentimer-sound for the current ping-time (maybe the mean of it) of the player? would be nice :)
Issue Details
Issue Type Feature
Project Fortress Forever
Category Sound
Status Rejected
Priority Unknown
Suggested Version Undefined
Implemented Version (none)
Votes for this feature 0
Votes against this feature 2
Assigned Users (none)
Tags (none)

01-11-2009 04:47 PM
German fag since 80īs
 
Reply
01-11-2009 05:53 PM
FF Whiner
 
I'm quite sure we already know what lag means, TS :)
Reply
01-11-2009 06:05 PM
Time Lord, Doctor
 
Make the timer client-side only if isn't already?
Reply
01-11-2009 06:06 PM
 
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.
Reply
01-11-2009 06:07 PM
Time Lord, Doctor
 
But the sound happens on server, doesn't it because you can hear when people prime ?
Reply
01-11-2009 06:10 PM
 
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.
Reply
01-11-2009 07:33 PM
Interzone technican
 
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
Reply
01-11-2009 10:04 PM
 
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. :)
Reply
01-12-2009 07:53 AM
Keep On Keepin' On
 
Global Timer FTL!
Reply
01-12-2009 08:46 AM
Banned
 
Quote:
Originally Posted by Firefox11
I think that the grenade timer is already Client side
Yes, yes it is.
Reply
01-12-2009 05:08 PM
Time Lord, Doctor
 
Quote:
Originally Posted by Crazycarl
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. :)
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.
Reply
01-12-2009 09:30 PM
Gets tickled by FF
 
Quote:
Originally Posted by Crazycarl
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.
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..
Reply
01-13-2009 08:10 AM
QUAD ROCKET
 
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.
Reply
01-13-2009 11:10 AM
 
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 :)
Reply
01-13-2009 02:52 PM
 
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.
Reply
01-13-2009 09:22 PM
Banned
 
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.
Reply
01-13-2009 10:08 PM
IRL Combat Medic
 
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.
Reply
01-14-2009 05:09 AM
Banned
 
one way to fix THAT problem would to define a maximum velocity, just behind the threshhold of dissapearing.
Reply
01-16-2009 06:44 AM
Stuff Do-er
 
Use the visual timer. It's never wrong.
Reply
01-16-2009 07:16 PM
 
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)
Reply
Reply

Issue Tools
Subscribe to this issue

All times are GMT. The time now is 07:31 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2018, vBulletin Solutions, Inc.