banimod / etpro / ettv forums

Pmove_fixed x at pmove_msec y at com_maxfps z..... seem to work if x y and z are set to match...


my data right now is "narrow" and very restricted....

can anyone express universal equation than works so x y and z is useable...?

any help is most welcome...

spoofeh... thats why im testing... Its broked yes.. but at ALL pmove_msec values? and at all com_maxfps values? at all cl_maxpackets vaules? ..ect... It might just be very good at that particular server.cfg setup? A adjusted server.cfg using 1 type cvars values 4 all might just work with pmove_fixed...

thanx deej... 10 it is first up in test.cfg then...

amazing... pmove_msec post... I cant se the problem in rating the diffent values... -dont consider the pmove_fixed is broked.. -dont consider b_fixedphysics as an alternative -pmove_fixed 1 is going to be used serverside and forced clientside. -server.cfg will use the stated restrictions. range is 3...

a: sv_fps 20 pmove_msec 25 ( half )
b: sv_fps 20 pmove_msec 10 ( 1/5 )
c: sv_fps 20 pmove_msec 5 ( 1/10 )


hmm sv_fps 20..all.. at pmove_fixed 1 forced serverside.... was the question...

disregard sv_fps 20 then....

disregard that pmove_fixed 1 is borked,,,

a b or c?

a b or c?

Then consider pmove_fixed 1 is forced server side.
same setup as before..
a, b or c... what value would be best..?


//cl_packetdup 0 im going to stick with that... so the clients need 2 geet all thier packets 2 the server not half of them...

//cl_smoothclients... then it make no difference...

deus....? just trying 2 understand the mechanics.. pmove_msec its an odd name 2 use on a cvar unless it reflects timed events that happen on a server... My "idea" would be force'ing the following cvars on an ETpro 3.2.6-2 server.. at sv_fps 20... snaps 20 rate 25000 r_displayrefresh 0 r_sw...

Ok.. mr zinx a: sv_fps 20 pmove_msec 25 ( half ) b: sv_fps 20 pmove_msec 10 ( 1/5 ) c: sv_fps 20 pmove_msec 5 ( 1/10 ) a b or c ..? Its simple if I setup a server... as a test,,, without pmove_msec set 8 what would work best as an alternative. Just make believe its the only values that can be set.. :)

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 ge...

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...

? 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 a...

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_c...

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... i...

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 ...