Q3 physics: pmove_fixed & pmove_msec

[tar]

Hi,

you may be aware of the internal Q3 function pmove() which calculates your position by movement (and weapon recoil) and that its calculation depends on the g_gravity setting of the server (which we will ignore as g_gravity is set to "800" by default) and its calling depends on the actual frame rate of the client (your com_maxpfs).

That means,
- if you have (constant) 100 FPS then every 10 msec a frame is received by the server and every 10 msec the pmove() function is called.
- if you have (constant) 125 FPS then every 8 msec a frame is received by the server and every 8 msec the pmove() function is called.
- if you have (constant) 200 FPS then every 5 msec a frame is received by the server and every 5 msec the pmove() function is called.

The issue hereby is that the result of the pmove() calculation varies and depends how often it is called/executed.

You can test this by yourself if you deactivate VSYNC in your OS graphics driver settings, start Q3, go in your console, execute /devmap q3dm6 and try out the following com_maxfps settings: "100", "125", "200", "333". The difference between "100" and "333" should be obvious (if your machine cannot reach such high FPS just reduce your resolution for this test). You could also try out the famous bridge to rail jump which should be easy with 333 FPS.

In fact, 333 FPS is the value that gives the lowest possible gravity and the highest recoil when g_gravity is "800" (default). You could also test that and see completely different results when you change g_gravity.

Furthermore, if you have inconstant FPS then the pmove() function is also called inconstantly which results in slightly different in-game positioning although you do the exact same mouse/key movements. Therefore the Q3 command pmove_fixed has been included.

pmove_fixed
When enabled the pmove() function is called according to the value in pmove_msec which is 8 by default. That means that the calculation result is always like it would be if you have 125 FPS (=1000/8) and it does not matter anymore what your actual FPS might be. With pmove_fixed you get the same positioning results whether you have 100 FPS or 333 FPS or any other value.

The issue with pmove_msec now is that it should be set to a value that matches your average FPS because if you have 200 FPS and use pmove_msec = "8" the position calculation is done as you would have 125 FPS and this leads to display stuttering. Sometimes you even cannot see your own actual position and experience "warping" on your client. This is of course not very practicable as your movement and aiming does not match the actual positions and therefore you cannot hit or move accurately.

But if you want to set pmove_msec to another value as "8" the engine reacts very confusingly (at least for me):

Single player baseq3:
- com_maxfps = "200"; pmove_fixed = "0"; pmove_msec = "8": everything runs smooth but I cannot do bridge to rail jumps
- com_maxfps = "200"; pmove_fixed = "1"; pmove_msec = "8": everything stutters a lot but I can do bridge to rail jumps
- com_maxfps = ""200"; pmove_fixed = "1"; pmove_msec = "5": is not possible as pmove_msec are always reset to "8"

Single player unfreeze:
- com_maxfps = "200"; pmove_fixed = "0"; pmove_msec = "8": everything runs smooth but I cannot do bridge to rail jump.
- com_maxfps = "200"; pmove_fixed = "1"; pmove_msec = "8": everything stutters a lot but I can do bridge to rail jump.
- com_maxfps = ""200"; pmove_fixed = "1"; pmove_msec = "5": the setting of pmove_msec most often show "8" and sometimes "5", i have some stutters and sometimes I can do bridge to rail jump, but most often fail

I have no clue why the value of pmove_msec is reset by baseq3 and why it shows different values in unfreeze (just execute pmove_msec very fast to see the actual value in the console after you set it to "5") but I am not able to set it to the value I need.

Furthermore, I tested this yesterday evening (German time) on the unfreeze server while 20 players were online and experienced more and more stuttering the longer I played. Then I tested it last night around 4 a.m. (German time) only against bots and the stuttering did not increase over time. I will test this further as I reinstalled my graphics driver.

Please try it out for yourself and tell me your experiences so far as I would like to clarify this issue as I really have either in-game moving or display issues which is frustrating. Thanks a lot!

[adminless]

the behavior you described there is the default normal behavior of the rounded physics in q3 that as I had explained other times that is already patched here (as in cpm for example btw) by using the actual exact real numbers instead of a approximation. I think that probably the best article that you can read that explains it is this ("Accurate physics"). as I see from your output I believe that looks more like "randomness" to me than any other thing, I don't really see a pattern there, probably the problem is just something else and the pmove doesn't even have anything to do (though nevertheless is always cool to experiment).

anyways like I also said, I'm starting now to push some new patch to make some improvements on that direction on the client, I hope I can get it here for this weekend or so.

[tar]

I dont know what you mean by "randomness". As explained I can do bridge-to-rail with pmove_fixed = 1 only and pmove_msec got reset which is rather strange.

As I said I am looking forward for the maxpackets patch as I also think that the increased stuttering occured after setting cl_maxpackets to 200 (which would be the optimum value for the 200 FPS I use) which got restricted to 125 (and somehow the client cannot handle this with 200 FPS I guess) for a reason I have no clue of. Is it due to the server performance?! If so, would it not be the best to optimize all settings to 125 FPS (com_maxfps = 125, cl_maxpackets = 125, pmove_fixed = 1, pmove_msec = 8).

Thanks for the article... will read it now (but u know: its openarena and not Q3).

[tar]

What makes testing worse is the permanently random resetting of those values by the unfreeze server. Perhaps that is also a thing that leads to this stuttering behaviour. Therefore I would appreciate it, if you just set a MAXIMUM allowed value but DO NOT reset any client settings.

[adminless]

But if you want to set pmove_msec to another value as "8" the engine reacts very confusingly (at least for me):

Single player baseq3:
- com_maxfps = "200"; pmove_fixed = "0"; pmove_msec = "8": everything runs smooth but I cannot do bridge to rail jumps
- com_maxfps = "200"; pmove_fixed = "1"; pmove_msec = "8": everything stutters a lot but I can do bridge to rail jumps
- com_maxfps = ""200"; pmove_fixed = "1"; pmove_msec = "5": is not possible as pmove_msec are always reset to "8"

Single player unfreeze:
- com_maxfps = "200"; pmove_fixed = "0"; pmove_msec = "8": everything runs smooth but I cannot do bridge to rail jump.
- com_maxfps = "200"; pmove_fixed = "1"; pmove_msec = "8": everything stutters a lot but I can do bridge to rail jump.
- com_maxfps = ""200"; pmove_fixed = "1"; pmove_msec = "5": the setting of pmove_msec most often show "8" and sometimes "5", i have some stutters and sometimes I can do bridge to rail jump, but most often fail

I have no clue why the value of pmove_msec is reset by baseq3 and why it shows different values in unfreeze (just execute pmove_msec very fast to see the actual value in the console after you set it to "5") but I am not able to set it to the value I need.

now after a second and more thought read at what you wrote I believe that the behavior you described (particularly in the quote) is actually the correct and intended one (which by the way proves the mod code right and as intended). you can't set 5 msec pmoves in standard q3 because standard q3 is limited to 8 max, you have 5 msec pmoves at unfreeze because it's modded for that. as for the rest I believe that you have there evidenced more or less clearly the overall tendency with pmove it ends up causing hell a lot of troubles for online play (even with top equipment let alone people, actually the majority, that as you pointing doesn't precisely hits 200 fps constants all the time), looks really tested and confirmed. besides at the end of the day as far as I understood from your testing for what, just to take advantage of some physics exploits (trick jumps that probably shouldn't even have been there in the first place), doesn't really seems like worth the trouble if it were for a tricks jump server (i.e. defrag) but for regular deathmach play I believe I'd rather go for smoother play.

[adminless]

well UnFreeZe is actually a mod so it contains more code that just only q3, the code I added for the physics there is, in fact, based in openarena itself, so the article is relevant (furthermore it also writes about cpm and more, even original q3 stuff).

as for the server settings well I believe that that should be pretty self explanatory, those settings must be kinda locked or it could potentially lead to people having unfair advantages over others, I mean, apparently as I understood it so far the purpose of all this is being able to do some trick jumps by exploiting the physics to jump higher, that's kinda unfair, I believe that physics shouldn't be affected by the particular player settings, everybody should move the same (i.e. jump the same), therefor is something that obviously the server has to address in some way or another. I still left some stuff slightly unlocked there to give some room for experimentation and for a better understanding of the game, compatibility with other mods/settings etc etc but nevertheless like explained and generally observed, that shouldn't really take anywhere here anyways.

by randomness I refereed mainly at when you wrote that it worked differently depending on the hours of the day and/or the load and that overall it worked sometimes while others doesn't on the second read I answered about on previous post, I got a better understanding of what you was saying.

[tar]

you can't set 5 msec pmoves in standard q3 because standard q3 is limited to 8 max, you have 5 msec pmoves at unfreeze because it's modded for that.

Ah, I understand

besides at the end of the day as far as I understood from your testing for what, just to take advantage of some physics exploits (trick jumps that probably shouldn't even have been there in the first play), doesn't really seems like worth the trouble if it were for a tricks jump server (i.e. defrag) but for regular deathmach play I believe I'd rather go for smoother play.

I agree for the smoothness (and 125 FPS are not smooth here) but the thought behind was to make physics advantages equal for all players, (+edit:) get rid of any positional issues (movement/accuracy) and play the maps as they are meant to be (they are designed and adjusted for 125 fps physics: for example, the bridge to rail jump on q3dm6 is not a bug but not possible on unfreeze at the moment).

For the last one and as you mentioned you used the openarena code for the unfreeze mod: would it be possible to activate/include the accurate physics method mentioned in your link and include the g_gravitymodifier with a value of "0.9475"?

[adminless]

ah ok that's cool then, I get you now, as I said, I had specifically patched that one way and another, I believe that as you could see that won't really take you anywhere here which is really the intention of that code. yes overall I believe that the server is pretty much finished (at least when it comes to the core settings) all that is left are some final corresponding improvement on the client side matching the server. btw may be better move this to the main forum and mark it as ticked it then.

[tar]

fyi: just edited my previous post...

[adminless]

that's already corrected of course, I would be pretty reckless if I had forwarded you into a article I haven't even fully read myself haha yes, you jump/rocket jump the same as in 125 fps standard q3 for what the game was originally intended here, I mean from your own original post, "Single player baseq3: - com_maxfps = "200"; pmove_fixed = "0"; pmove_msec = "8": everything runs smooth but I cannot do bridge to rail jumps", the response can still be slightly different as a result of that, more accurate math instead of just rounded, but that's precisely what makes a smoother game. give it a try, try a couple of jumps in standard 125 q3 and on UnFreeZe you should find that they work exactly or almost exactly the same, I mean, at least I already accounted for that effect.

[tar]

Erm... it seems you did not understand me at all. Of course, I can do a bridge to rail jump when I set 125 FPS (on baseq3 and unfreeze) but the issues are:

1) with vsync I cannot use 125 FPS as my monitor only has 100 hz
2) without vsync I cannot use 125 FPS as the display is constantly stuttering/jerking. It looks laggy, the movement works but you cannot really play with it as this display lag effects the whole gameplay.

With 100 fps (vsync) and 200 fps (no vsync) the display is absolutely smooth but with both 100 or 200 FPS the jump is not as high as with 125. If i activate pmove_fixed then the display begins stuttering again.

[adminless]

well, once again as I can read from your output the behavior of both, "I can do a bridge to rail jump when I set 125 FPS (on baseq3 and unfreeze)", is therefor the same under the same client settings even for fancy tricks like that which clearly shows you that the server code is not the one at blame here and the corrections already made as well as the server performance are virtually flawless. what that is also clearly showing you is how unreliable, inconsistent and dependent on specific client settings/hardware combinations/specifications those tricks really are (and that can even be clearly inferred from the comments on the video you posted) and that therefor most of the times those kind of tricks are more of a result of experimentation under very specific circumstances rather than really mainstream intended behaviors. I don't really see any server issue here that's just the way the game is.

[fernandinho1337]

@tar: to fix this issue as your computer is pretty fast. you could try to do vsync = yes and maxfps 83. you can jump higher than when using maxfps 100. maybe that reduces ur suffering (btw i barely see you moving anyways )

*edit* i can do bridge2rail with maxfps 83 but i have to admit it is not as easy as using maxfps 125 though it should be easier than using maxfps 100

[tar]

@admin:
again: this is not a *trick*, it is *standard* movement and every position calculation different from 125 fps / 8 msecs is a disadvantage.

@dirk:
thanks, will try it out later/tomorrow.

[adminless]

"this is not a *trick*, it is *standard* movement and every position calculation different from 125 fps / 8 msecs is a disadvantage."

that's simply false, it's definitively not every position and it's definitively not a disadvantage as is the same for everybody. so far the only thing you seem to have proved was some specific fancy trick on some specific map not working on a specific setup which to tell you the truth all that don't even seem like that much of a deal altogether, I mean, honestly, I don't see why all this drama about just not being able to perform a specific jump trick at some specific map, but hey look it's cool I'm not gonna argue with you as I've said other times I'm not here pretending to "sell" this to anyone, so if you find that not being able to perform a specific trick at a specific map under your specific setup here is the central element of your gameplay that is preventing you from reaching your full potential, sure prefect I'll totally understand that you will go play somewhere else where you can display the full potential of your gameplay from now on-wards, no problem at all. one thing is clear here, for the good or the bad, that's how the server works, I have no interest in having users here frustrated with the server, I mean, that's no good for anybody.