pmove_msec 5/10 and etpro ?

Discussion about specific ET servers

Moderators: Forum moderators, developers

User avatar
ReyalP
Posts: 1663
Joined: Fri Jul 25, 2003 11:44 am

Post by ReyalP »

pmove_msec has no effect, unless the player is using pmove_fixed.

Your idea that there is some benefit to making pmove_msec an integer factor of sv_fps is based on misunderstanding. Clients are not run at sv_fps on the server.


edit:
@deej
The lower limit for pmove_msec in etpro seems to be 3.

Fixing et to work with other sv_fps values probably doesn't require changing the engine, but there is little benefit. The perceived benefits are almost certainly based on misunderstanding.
send lawyers, guns and money
LilleBror
Posts: 111
Joined: Wed Nov 24, 2004 11:10 pm
Location: Dk

Post by LilleBror »

So pmove_msec 8 if changed serverside to something else would have zero impact if the client uses pmove_fixed 0... roger..

But the server sends out snaps at sv_fps 20 sliced and diced in 50 ms intervals? based on the other clients movements "commands" in 50 ms timeframe no? But u are sure it will not smooth anything out?

Up the wrong creek here or what... even if the on server side tracking is independant, the broadcast of sv_fps aspect will not change with different pmove_msec values?
User avatar
deej
Posts: 743
Joined: Fri Mar 19, 2004 12:44 am
Location: Belgium!
Contact:

Post by deej »

ReyalP wrote:edit:
@deej
The lower limit for pmove_msec in etpro seems to be 3.
Yeah since Pro isn't open source I took a peek in the etpub sources ;). They changed it apparently to 8.
Our servers now run on 64 bit steroids. Point your ET to:
- Forgotten Ground StopWatch Server with occasional wolfrof 1
- Fraggle Rock ETPub Server - Mix up ET/UT & Duke Nukem
User avatar
zinx
Posts: 267
Joined: Fri Jan 16, 2004 12:37 pm
Location: US
Contact:

Post by zinx »

Actually, I believe we changed it to 3.
Zinx Verituse http://zinx.xmms.org/
LilleBror
Posts: 111
Joined: Wed Nov 24, 2004 11:10 pm
Location: Dk

Post by LilleBror »

Im getting some strange results...

SERVER running pmove_fixed 0 pmove_msec 8
CLIENT pmove_fixed 0 pmove_msec 8

then i Rcon pmove_msec 5

<</////////xxxxxvvvvvv>>> "shifting" small lagspike's that should not happen if pmove_msec is NOT a "base" in the server calculation? right...
ie. if my client is at pmove_fixed 0..then changing the pmove_msec serverside should have zero impact..

So my "brain" or lackoff..:) is telling me that pmove_msec set server side has a impact on all clients regardless of the client setting of pmove_fixed?

ie. its a "base" number in the position calculation on the server...

If this is the case why use pmove_msec 8 serverside?

My inclination is that pmove_msec of 5 or 10 would be better, why? since the sniper bug, that generates recoil before the shot i fired is gone, at least under the conditions i used.. (and the fill ?)

So the tech explanation please:

pmove_msec 5 --->undesireble because?
pmove_msec 10 --->undesireable because?
pmove_msec 8 -------> is the best value because?

or even better if someone can mapout from pmove_msec 3-33 what the implications are serverside?

I just cant se the logic in useing 8 ms... at sv_fps 20..i can se it at sv_fps 25 and if the cap on cl_maxpackets was 125 not 100..?
LilleBror
Posts: 111
Joined: Wed Nov 24, 2004 11:10 pm
Location: Dk

Post by LilleBror »

one more thing forgot...

q-.:deej "pmove_msec is an integer so no fractions"

hmm.. the server will register ex. 12.5 as a valid pmove_msec.. again not sure if if i can trust the console output..?
setting is server side via rcon, then the client value is also set 12.5.. not 12 or 13..? pb_cvarval pmove_msec also reads out 12.5...


if i set pmove_msec to an out of range value on the server side, like say 34 the client value is set 33... but it can be set 33.1--->33.9

also if i rcon pmove_msec 12.2 and change it to 12.3 the same ajustment come into the lagometer as one would se from 8 -10 or whatever...

but the spikes are smaller...

so now im confused...? it looks like the engine can use fractions...
User avatar
deej
Posts: 743
Joined: Fri Mar 19, 2004 12:44 am
Location: Belgium!
Contact:

Post by deej »

look at the source, it's defined as integer so it'll round
Our servers now run on 64 bit steroids. Point your ET to:
- Forgotten Ground StopWatch Server with occasional wolfrof 1
- Fraggle Rock ETPub Server - Mix up ET/UT & Duke Nukem
User avatar
ReyalP
Posts: 1663
Joined: Fri Jul 25, 2003 11:44 am

Post by ReyalP »

LilleBror wrote: So my "brain" or lackoff..:) is telling me that pmove_msec set server side has a impact on all clients regardless of the client setting of pmove_fixed?

ie. its a "base" number in the position calculation on the server...
No. pmove_msec has no effect unless pmove_fixed is on. Please refer to the game code if you don't believe me.

pmove_msec is always treated as an integer.
send lawyers, guns and money
LilleBror
Posts: 111
Joined: Wed Nov 24, 2004 11:10 pm
Location: Dk

Post by LilleBror »

? now im totaly confused... realy the "tests" i have done dont support the facts that u say are true...

---why in the hell ..pardon the language would there be a "recalulation" on a client that is not using pmove_fixed 1 if the pmove_msec is redundant if i set pmove_fixed set 0 and while changing the server pmove_msec value server side?...


ok.. think... hmm... well what happens in case of "lag" ie a client missing a snap.... or delayed snap... pmove_msec kicks in?


im realy in a jam here, because i would like the pmove_msec value 2 be a real divisor of the 50 ms timeframe at sv_fps 20....

u know the code... and ur sticking 2 that it means nothing... ok so why is it set 8 if it realy means jack and .... ? unless the client opts 4 the use of pmove_fixed 1....

my logic would have it set 10 or 5... or 12.5 (but its treated as int..so no go)


when i paly i notice that my ping is 48..and 56 most off the time...and im not using pmove_fixed...

but agian please explain why 8 is the default choice... and not 10 or 5...

if it means nothing... why not set the value so it "fills" the timeframe out as default?... in case someone will use pmove_fixed 1...?

and i belive u.... so np there just help a nabie like me get the picture of the mechanics into my thick skull....
User avatar
zinx
Posts: 267
Joined: Fri Jan 16, 2004 12:37 pm
Location: US
Contact:

Post by zinx »

8 is the default choice because it is equivilant to 125fps, which is a magic number.

It is not a multiple of snaps or the server framerate because there is *ABSOLUTELY NO REASON FOR IT TO BE*. Player movement (of yourself) is done entirely by client frames, not server frames. Even if you turned pmove_fixed on, it would still only affect your framerate (It will lower it), and your movement itself - It will not affect the network activity, except indirectly (by lowering your framerate).

So, to state again:
  • 1) pmove_msec (on the server, it is ignored on client) has absolutely no effect unless you turn pmove_fixed (on the client)
    2) pmove_fixed does not affect network activity at all, off OR on, unless it changes your framerate. And it only affects it then because your framerate is different.
Zinx Verituse http://zinx.xmms.org/
LilleBror
Posts: 111
Joined: Wed Nov 24, 2004 11:10 pm
Location: Dk

Post by LilleBror »

zinx..thanx 4 the explenation.. but i realy have a thick skull..
So its the "magic" number and regarding the "fill" no reason at all for it to be... just aint getting the greys going...

is the server transmited data size, number calculated positions and timespan the same from one sv_fps to the next regardless of pmove_msec?

pmove_msec is not used if the client lags..?

what is the magic number so the other clients can hitscan better, not the number that lets the client "use rounding errors" to move faster...?

the sniperbug... gone at pmove_msec 10....? (at com_maxfps 100)

why would "build up" server used cvars promoting using
com_maxfps 100 at cl_maxpackets 100 and at pmove_msec 10 be a bad thing...? 8ms promotes..as u say 125 com_maxfps...

from my perspective... when i look at the lagometer at diffent settings...the following holds true..

same size sv_fps revieved as snaps at:
com_maxfps 100 at pmove_msec 10 and sv_fps 20 (*
com_maxfps 125 at pmove_msec 8 at sv_fps 25 (**
com_maxfps 100 at pmove_msec 5 at sv_fps 40 (+

* also at com_maxfps 200 and 400
** also at com_maxfps 250..sometimes at 500..?
+ fast try 2 min but its seems 2 hold true

2 be crystal clear... im not fussy about how 1 client send frames to the server... im very focused on how the sever sends information from multiple clients out via the sv_fps and pmove_msec settings-->

i played fueldump on gmc todes zone last night and the lagg was massive... so from my perspective there is a glich somewhere.. and its not cpu overload... but it seem 2 be fixed in 3.2.6, i get rock soild ping on the beta servers..+/- 2 msec...
User avatar
Father
Posts: 107
Joined: Sat Jul 22, 2006 1:30 pm
Location: Czech Republic
Contact:

Post by Father »

zinx wrote:8 is the default choice because it is equivilant to 125fps, which is a magic number.
So what are differents between b_fixedphysics and pmove_msec?
If i set b_fixedphysics 1 and set b_fixedphysicsfps 125 it lock physic to 125 FPS. If i set pmove_msec 8 it lock physic to 125 FPS. What are differents?
If you don't do it, someone else will.
User avatar
zinx
Posts: 267
Joined: Fri Jan 16, 2004 12:37 pm
Location: US
Contact:

Post by zinx »

Father wrote: So what are differents between b_fixedphysics and pmove_msec?
If i set b_fixedphysics 1 and set b_fixedphysicsfps 125 it lock physic to 125 FPS. If i set pmove_msec 8 it lock physic to 125 FPS. What are differents?
b_fixedphysics removes the main source of the framerate dependency - the snap of the player positions, and adjusts the jump velocity to compensate for jump height (I've been meaning to change the gravity instead, so it compensates for air time too, but haven't gotten around to it).

pmove_msec splits up client frames that are longer than pmove_msec (by default, 8ms) in to intervals of pmove_msec, there-by making the snaps happen at roughly 1000/pmove_msec FPS, so you get movement like you're at that framerate. pmove_msec is very broken in ET, and still hasn't been completely fixed in ET Pro.

To LilleBror: I have no clue what you're trying to say or ask for the most part. I'll try to address your questions as best I can.

pmove_msec and the client framerate do not affect how snaps are sent at all, including size of the snap and duration between snaps.

sv_fps adjusts the rate of the snaps, but not the size, and should not be used in ET because some of the code depends on it being 20.

snaps are how the server sends information from multiple clients out via sv_fps. pmove_msec/pmove_fixed, as stated above, do not affect it at all.

I have no idea how you came to the conclusion that pmove_msec isn't used if the client lags, nor what use that would be. pmove_msec isn't used if the client doesn't have pmove_fixed on.

There is no magic number that makes you hit people better, for any cvar. But you may try adjusting b_placebo, I've heard it can improve accuracy.

I have no idea how pmove_fixed affects the "sniperbug", but I'm sure that it does. And it breaks half a dozen other things while it's at it.

Any lag you're experiencing was not caused by 3.2.5, and no such bug was fixed in 3.2.6. The internet is not consistent in speed and reliability, and can trivially be affected by anyone who wants to affect it. Live with it.
Zinx Verituse http://zinx.xmms.org/
User avatar
Deus
Posts: 1053
Joined: Fri Mar 12, 2004 2:24 am
Location: Germany
Contact:

Post by Deus »

Father wrote:What are differents?
b_fixedphysics does not let you jump as 1337 as with pmove_fixed 1
but
b_fixedphysics does NOT break sniparing/recoil
LilleBror
Posts: 111
Joined: Wed Nov 24, 2004 11:10 pm
Location: Dk

Post by LilleBror »

zinx: i think its the new flood protction cvars and pmove_fixed antiwarp expliot fix in 3.266 that kick's in.

Realy from my point of view, its not a cpu load or net stabilty problems that cause the laggy servers "syndrome"

Somehow the server's "hangs" due to the fact it cannot generate sv_fps at the desired "tic rate"...

I think that "hang" can be fixed by setting the pmove_msec serverside to some other value can fix it.....

IF pmove_msec (quake) was intended to reflect sv_fps the settings below should be intended.

sv_fps 125 - pmove_msec 8 (lan play?)
sv_fps 30 -pmove_msec 33 (net play?)

So zinx... if a clients/server can handle the netload and we disregard the fact that there are issues when ET is run at sv_fps diff. 20..
How would the following server setup be rated by u?

sv_fps 40 -pmove_msec 25 ?

IF this is the intended use of pmove_msec then maby the ETpro team could change pmove_msec range to reflect max of 50..

sv_fps 20 -pmove_msec 50 (if done)

What setup from the following would u think is the best?

sv_fps 20 pmove_msec 25 ( half )
sv_fps 20 pmove_msec 10 ( 1/5 )
sv_fps 20 pmove_msec 5 ( 1/10 )
Post Reply