With cordite in the air, splintered steel, shell casings and powder burns, there’s only one explanation...
If you have any trouble with SG, this is the place to ask.

Moderator: Pardner

Postby Lucky Bro » Thu Mar 19, 2009 9:23 am

Unfortunatly my ping on RAWHIDE is about 200-250. So, that's not my preferable server (and for last week it was empty to me). Baller Bude is my favourite - 80ms ping (with cl_timeNudge trick). But usually (few last weeks) it's empty too.
Yes, I've noticied that too - the game is slower than original Quake. And you're right - there is enough players who play cool with ping higher than 100-150. And besides most players use some tricks (tactics?) to win instead of 100% precision. That is not kind of tricks I like but I can see the fun of it.
So, for me - I'll stay until I'm getting fun while playing. That the reason I came and that the reason to stay.
But I'm still looking for ways to reduce ping.
"You should know that the lies won't hide your flaws/No sense in hiding all of yours/You gave up on your dreams along the way" (c) "Fake it" by Seether
P.S. English isn't my native language.
User avatar
Lucky Bro
Gunslinger
 
Posts: 143
Joined: Mon Mar 09, 2009 4:12 pm



Postby /dev/random » Thu Mar 19, 2009 3:58 pm

Ballerbude is located in germany. Always try to use server swhich are located next to you. If all your packets have to swim through the ocean first, they'll be delayed somewhat :wink:

About the FPS; I've mentioned it. com_maxfps should be a multiple of cl_maxpackets. Your fps should be stable, otherwise there's packetloss. More than 125fps are useless, since they don't bring any benefit. You could ask some serveradmins to enable pmove_fixed, so you can even use lower fps.

I'd be interested if un-unlagged servers work better for you :D
User avatar
/dev/random
Smokin' Amigo!
 
Posts: 410
Joined: Thu Jan 22, 2009 1:58 pm



Postby mLy! » Thu Mar 19, 2009 4:53 pm

whats the effect of pmove_fixed in SG? and what is the standard value serverside?
My Latest fragmovies:
Winning BB cup
User avatar
mLy!
Gunslinger
 
Posts: 218
Joined: Wed Feb 11, 2009 8:46 pm



Postby /dev/random » Thu Mar 19, 2009 5:28 pm

pmove_fixed - Typically the player physics advances in small time steps. When this option is enabled all players will use fixed frequency player physics, the time between two advances of the physics will be the same for all players. The actual time between two advances of the player physics can be set with the pmove_msec variable. Enabling this option will make the player physics the same for all players independent from their framerate. [Enforced Server side]

pmove_msec <milli-seconds> - Sets the time in milliseconds between two advances of the player physics. [Server side]


Defaults:
pmove_msec = "8"
pmove_fixed = "0"

Haven't digged into SG's code, but it should work here asewell.
User avatar
/dev/random
Smokin' Amigo!
 
Posts: 410
Joined: Thu Jan 22, 2009 1:58 pm



Postby Lucky Bro » Thu Mar 19, 2009 7:49 pm

/dev/random wrote:Ballerbude is located in Germany. Always try to use server swhich are located next to you.

Yep, got it. Any Europe server should be fine for me (they are closest ones).
/dev/random wrote:About the FPS; I've mentioned it. com_maxfps should be a multiple of cl_maxpackets. Your fps should be stable, otherwise there's packetloss. More than 125fps are useless, since they don't bring any benefit.

I've read it and I really thankful you for the info (I know it should be obvious but somehow I missed the point of multiplying during first try). It did help to understand how to perform testing. But for my ping it's really useless.
/dev/random wrote:You could ask some serveradmins to enable pmove_fixed, so you can even use lower fps.
I'd be interested if un-unlagged servers work better for you :D

Oh, don't wanna be so annoying. And besides servers do not have this option configured by default. I'll let server be server.
As far as I understand FPS and world's physics frames may work by one of the following schemes (for Q3):
1. g_synchronousClients 0 (all world physics is independent from sv_fps):
You'll get a really smoth client-side physics. But this case server should provide fair-physics for all because of physics dependency from FPS (Quake jump problem (really old article) - that concerns not only jumping but strafe as well). And that is where pmove_fixed 1will be really helpful (as I uderstand that is why it was created). To make fake sv_fps to 125 server must have pmove_msec about 8msecs (1000 msec/8msec=125Hz (125 fps)). And that will provide fair-for-all physics. This mode is usually used on Q3-online servers (as I've read). And as I understand the one's highest ping will became problem for all players instead of being only this one's problem. Everyone will suffer because of this outsider.
2. g_synchronousClients 1 (all world physic is depend on sv_fps and is independ from client FPS). This case the pmove_fixed is not required. Physics is already independed from players FPS.
This mode ping will be client latency between your mouse click and your shoot in physics world. And server doesn’t mind what happens to client. It's only client headache to make his high ping-latency lower.
As I understand first technics should be used during fair online plays and the second one is for LAN games.
Anyway it's up to server admin to decide. I don't see any reason why he should change a thing because of my high ping thoughts :)
So, all things that I will change is client-side options.
As I discovered it's only about these values:
snaps (frequency of requests to update my snapshot of world physics). 40 is fine. Must be less than cv_fps.
rate. To me the vital value. Depends on your bandwidth.
cl_timenudge. Should be set to 0. But if you belive in prediction - use negative value.
cl_packetdup. Use 0 in case of 0 packets loss. Default 1 is fine.
cl_maxpackets. Must be lower or a divisor of average FPS (or com_maxfps). So, it's 125.
Seems that's all the values to change.
"You should know that the lies won't hide your flaws/No sense in hiding all of yours/You gave up on your dreams along the way" (c) "Fake it" by Seether
P.S. English isn't my native language.
User avatar
Lucky Bro
Gunslinger
 
Posts: 143
Joined: Mon Mar 09, 2009 4:12 pm



Postby Tequila » Thu Mar 19, 2009 10:36 pm

Very interesting thread for admins ;)
I wasn't aware of such kind of "Fair" parameters for the server side on Q3 servers. Of course I'm speaking about your point 1 explanation Lucky Bro...
As I'm the admin on smokinguns.fr, I've just setup a new server with only "set g_synchronousClients 0 ; set pmove_fixed 1 ; set pmove_msec 8" different in the configuration. It uses also the mixed gametype mode proposed by Joe Kari ;) .The server is named "smokinguns.fr-FAIR"... you won't miss it :P

Then guys, can you try it a little and tell us if that changes something in your gameplay ?
User avatar
Tequila
SG Team
 
Posts: 1100
Joined: Thu Nov 15, 2007 11:33 pm
Location: Montpellier, France



Postby Lucky Bro » Fri Mar 20, 2009 10:45 am

I'm in!
And I'll ask my brother to join in.
I'll write back as soon as possible. Mean as soon as I discover any results.
Good point will be to record the demo.. But I think it's not necessary for this time.
Since I'm not one of the best-players it'll be good if someone from tough (or long time playing) players will join too. They'll say more than me for sure.

Tequila, thank you for quick reply-action! I'm deeply appreciate that!

No volunteers on the server. I'll try to be on IRC channel time-to-time, so if anyone wants to test - please you're welcome! Don't hesistate to kick me and go for testing!

And one more note about the Rate value. Stupid me as always! :) Each server can set sv_maxRate from 0 to 25k. This value restricts Rate value of each player. Most of the servers has this value from 8k to 10k. That's why no value from 10k up to 25k doesn't change a thing for me! By the way sv_maxRate=10k is one of the methods to help people with low bandwidth connection.. Since I have Rate 7500 it's about me. As I understand in case if sv_maxRate = 25k the players with good connection will have some advantages on players with bad connection (just lower ping).
I always wonder why most of the online servers here has sv_maxRate about 10k. Now I know the answer.
Server admins usually use the following method to determine the sc_maxRate value:
Upload speed in Kbit per second / 8 = Upload speed in Kbytes per second / 1024 = Upload speed in Bytes per second
sv_maxRate = upload speed in Bytes per second / Average number of players on server
e.g.
Upload speed = 128Kbit/s = 16384 byte/s
Average players count = 8
sv_maxRate = 16384/8 = 2048
I know it's obvious.. But probably may help to understand some thing about the game to newbie like me.

EDIT:
As a conclusion of my experience with decreasing client-side ping I may state the following points:
1. Ping hardly depends on your badwidth. Simple: Depends on your down and upward internet connection speed. If you have more than 128Kbit/s down speed and 64Kbit/s up speed - you have nothing to set for decreasing your ping. The default SG configuration is the best in the case. If you have lower down speed try these values:
\Rate from 2000 to 15000
and/or
\cl_maxPackets 63
(Remember \cl_maxPackets set to 125 (default one) may cause "fake" increase of your ping. It's not your actual ping).
I (and not only me) suppose to recommend not to use negative cl_timeNudge and not to change snaps, com_maxFPS, etc. These methods are extreme ones and you should use them only if you understand what they actually do. And when you understand you actually don't want to change them.
2. Ping depends on your distance to server you play. There's nothing you can do with it.
3. Ping depends on your FPS in game. Use "\cg_drawFPS 1" to watch the game FPS. It should be 125 all the time.

P.S. I suppose to end Tequilla's server testing.. There are no volunteers.
"You should know that the lies won't hide your flaws/No sense in hiding all of yours/You gave up on your dreams along the way" (c) "Fake it" by Seether
P.S. English isn't my native language.
User avatar
Lucky Bro
Gunslinger
 
Posts: 143
Joined: Mon Mar 09, 2009 4:12 pm



Postby moRtem » Wed Apr 01, 2009 8:55 pm

mLy! wrote:I suggest you try playing with -20 and see how it 'feels' for you and then adjust from there


i definately suggest NOT to set cl_timenudge to a negative value in an unlagged game (and SG is unlagged) since it makes you appear choppy and laggy for other players .. which is pretty much the only effect you got in an unlagged game

rather try setting it to little positive values to make the yellow spikes at the upper blue line in your lagometer disappear


(addon for the devs: it would be a good idea to lock cl_timenudge to non-negative values when server is unlagged to prevent players abusing the choppy-effect of negative values)


/quit
User avatar
moRtem
Gunslinger
 
Posts: 284
Joined: Sun Mar 15, 2009 5:56 pm



Postby moRtem » Wed Apr 01, 2009 9:30 pm

Lucky Bro wrote:One "bonus" solution (in case if one decided to use simple graphics) is to set com_maxFPS to 150-200 and cl_maxPackets to the same value.


com_maxfps 125 is highly adviced -- due to rounding errors in vQ3

and if your connection allows it, cl_maxpackets 125 --.. otherwise cl_maxpackets 63

I've also tried snaps. The default "40" is fine for me.


40 should be fine for everyone

cl_predictItems is not the one vital for me.


caused weird effects in q3 often .. so i suggest to set it to 0

Somehow when my ping is about 200-300 I fell guilty too.. Because some players just don't want to play with such pingy guy.


as long as the ping is stable (without packetloss) everything is fine - just a disadvantage for you.. but non for your opponents (beside some strange seeming happenings due to unlagged)

My old Q (quake player) friend says that any ping higher than 100 is unplayable.


on a server without unlagged this makes sense -- in SG however we got the unlagged Code .. it is harder with high ping (since the pressed buttons of a player with lower ping arrive the server before yours), but still playable

So, if anyone knows any other possible solution to reduce ping - I'm really need you. Please let me know.


you can't do a lot ... it's mainly the way between your PC and the server you play on :: sometimes an ISP-change makes sense

you could ask some serveradmins to enable pmove_fixed, so you can even use lower fps.


afaik pmove_fixed sometimes causes problems when standing near edge (you are suddenly falling down altough you are still standing on the roof) due to rounding errors

To make fake sv_fps to 125 server must have pmove_msec about 8msecs (1000 msec/8msec=125Hz (125 fps)). And that will provide fair-for-all physics. This mode is usually used on Q3-online servers (as I've read). And as I understand the one's highest ping will became problem for all players instead of being only this one's problem. Everyone will suffer because of this outsider.


pmove_fixed is doing nothing else than making everyone 'feel' like playing with constant 125 fps (regarding jumps and walking)

and this got nothing to do with pings

g_synchronousClients 1


try that setting and you will notice that the game is unplayable

snaps (frequency of requests to update my snapshot of world physics). 40 is fine. Must be less than cv_fps.


wrong -- it should be equal or higher than the server's sv_fps setting :: so 40 should be fine for everyone

cl_timenudge. Should be set to 0. But if you belive in prediction - use negative value.


read my comment above please..

cl_maxpackets. Must be lower or a divisor of average FPS (or com_maxfps). So, it's 125.
Seems that's all the values to change.


try the same setting as you use for com_maxfps first - if you notice laggy moments sometimes, reduce it to the next divisor of com_maxfps (if you don't set an exact divisor, q3engine will do that for you internal)

I've just setup a new server with only "set g_synchronousClients 0 ; set pmove_fixed 1 ; set pmove_msec 8" different in the configuration.


only pmove_fixed 1 defers from the default -- and like mentioned above, it ain't changing a lot

As I understand in case if sv_maxRate = 25k the players with good connection will have some advantages on players with bad connection (just lower ping).


not really :: using low rate could cause lag-problems in big battles :: sv_maxrate 25000 is just fine

If you have lower down speed try these values:
\Rate from 2000 to 15000


ough -- you seriously shouldn't got below 8000 rate

Ping depends on your FPS in game. Use "\cg_drawFPS 1" to watch the game FPS. It should be 125 all the time.


mmm - very low fps make you feel choppy and laggy :: but that got nothing to do with your ping :: FPS mainly affect the height of your jumps in q3engine-games (but we are only talking of a little effect here ,, since SG is a very slow game where it is impossible to do strafejumps etc.)


/quit
User avatar
moRtem
Gunslinger
 
Posts: 284
Joined: Sun Mar 15, 2009 5:56 pm



Postby Lucky Bro » Mon Apr 06, 2009 12:55 pm

moRtem, thx for answer!
I think there is no need to me to reply anything - you wrote clear.

Instead I’ll say the following.
First of all if you want to understand game-insides you have to read source code. Since the code (at least this) is not self-explanatory you may want to read the articles about it first.
The best thing to read about q3 network code and lag problems is bunch of readme files coming with unlagged code. To do this download unlagged 2.01 source code from author’s page (http://alternatefire.planetquake.gamespy.com)/. And check the docs section in archive.
These docs have really good lag nature explanation and its root cause. And q3 network code as well. The only thing I didn’t get from scratch – it is how Xaero moves on the pictures? – is he moving from jump-pad or to jump-pad? :) He moves to jumpad. And there is nice FAQ section.
Actually nothing can save you from your ping in game :) You always will shoot after “your-ping msecs” has passed. And move and so on.
Unlagged will try compensate your ping during aiming.. But for price of warping other players back for short period of time (to make server do right decision about your hit). This method called backward reconciliation. And the method is the reason why sometimes when you under strong fire you feel choppy and warping back. The higher your ping, the noticeable the trick.
The unlagged is not the only one solution for the problem. It’s a solution. But principle of backward reconciliation is used in many other games/mods (especially mods).
Next one to help to understand the lag is the source code by itself.
It’s really unreadable for the first time. I read the source code and I can say it’s really mess of styles and principles. And I read enough to get out from any wish to read it again. I can’t say that I understand the whole thing but I get the principles. For me that is enough.

Now to FAIR server. The big (actually the only one) difference from other servers is pmove_fixed = 1. Pmove is coming from acronym player move (bg_pmove.c).
This thing (pmove_fixed) was really helpful for jumping guys in q3 (defrag mod and others). Since it makes them undependable from their FPS when server does not synchronize clients (g_synchronousClients = 0). In short – it makes them jump easier. This was the case for online speed champs.
Other possibility to make physics better (most of all for jumping) is to synchronize clients and make server think 125 times in a second (instead of 20) (sv_fps). But it can’t be applied to online games. The reason – server will be too loaded (it needs to think each 8msecs) and bandwidth too (it needs to send update to each player each 8msecs). This configuration can be applied only for LAN dedicated server.
So pmove_fixed was the best solution. But there comes another problem. Game became buggy. The root cause is not obvious. May be it’s because all player events became not consistent.. or something else.. Anyway players had noticed these bugs. And then there are come new and new solutions – you may check zero ping mod. RTCW has new g_physics variable. Unlagged became Ultra Freeze and expanded with cg_pmove_accurate variable which should provide same functionality as pmove_fixed but not buggy. And so on.
For me – FAIR server is the same as others. I can’t even say that I became jump better (just not enough tests). Nothing special about bugs. Actually no bugs at all. Except I know that Tequila noticed unlagged back-warping first time on this server. I never got it there. But I notice it each time on full-servers.

As conclusion:
There is no any solution to reduce your physical ping which is root cause of your lag. There are only tricks. If you know programming well – please welcome to source code. Check current solution and try to implement anything better. There is lot of things to think of. SG reduced the speed and velocity of q3. So, delta became smaller. And round-errors can be bigger. And so on. Just read the code.

FAIR server will stay as long as Tequila will let it. Nothing about fair at all. But jumps should be easy to perform. So, just check it by yourself. We are not about jumping records here but if it’s really easy and not buggy – why do not give it a chance?
"You should know that the lies won't hide your flaws/No sense in hiding all of yours/You gave up on your dreams along the way" (c) "Fake it" by Seether
P.S. English isn't my native language.
User avatar
Lucky Bro
Gunslinger
 
Posts: 143
Joined: Mon Mar 09, 2009 4:12 pm



Previous

Return to Doc's Office

Show Sidebar
Show Sidebar

User Control Panel

cron