You misread Anthony’s post r3fleX. It was about the net_clientMaxPrediction (maximum number of milliseconds a client can predict ahead of server) cvar, not the net_clientprediction cvar (additional client side prediction in milliseconds, which I’ve set to 20, because many of my favorite servers force me to set it at that value).
Edit: you fixed your post 
The screenshot addresses net_clientMaxPrediction, not net_clientPrediction. There’s a difference.
net_clientMaxPrediction maximum number of milliseconds a client can predict ahead of server.
net_clientPrediction additional client side prediction in milliseconds
I however only use net_clientPrediction as well and don’t know the effects of net_clientMaxPrediction on the games performance 
EDIT: Coliseum already posted this, bleh
Bleh i posted it then realised and then while editing it you guys were to quick! Give me a chance plz 
Nevah! In-game experience has proved it extremely unwise to give you any chances! 
Pure guess, but clientmaxprediction sounds like the game will keep predicting for 1 second (1000ms) in case of a lagspike.
So that might affect the behavior of:
“walking forward for a short while and jumping back to original spot because of lag”
and
“you see a player running in a straight line and keep firing at him, then he suddenly disappears and appears on the spot he actual is. Again because of lag”
The “short while” and the “time spent on firing at a ghost (predicted location)” is the time set by net_clientMaxPrediction
Does this sound accurate?
Anyway, we should stop hijacking the thread I guess :-p
I think so, sounds logical to me. That would mean you can’t put people at a disadvantage using that setting, just yourself 
r3fleX: lol unhit fight
It was probably against somebody else ? But still, this nightL gut is definitively using some weirdo net settings, we don’t really need to bash them more in a “screenshot” thread ^^
:stroggtapir::stroggtapir::stroggtapir:
Yea that was against Alsef and was mainly to do with my aim (or was it my aim??? dun dun dun)
Hmm, doesn’t look like that on my ingame screen. Seems the success depends on screen resolution…
Edit: Here’s a few pics that I found way back before the release of the game. Several have been posted already, but I don’t think these have, sorry if I double any up. I don’t have any of my screens moved over to this rig yet, but these I have already hosted.
Does OpenGL, specifically the version ETQW uses, have the same multi-core advantages that DirectX 11 does? Like being able to have parallel calls from the Gpu to each core individually, all at the same time?
Also I haven’t payed any attention but I’ll try it out now, single player, and see if the game is at all threaded and to what degree. So far the best I’ve seen have “all” been DirectX games. Does this have something to do with a weakness in OpenGL 2.1?
Thanks for any replies. I very very much support open source and thank god for OpenGL, I’m just curious if OpenGL 2.1, and also the newest version of OpenGL has the same advantages that DX11 has.
Btw, running ETQW I only get 30-38% Gpu load. For example Stalker - Call of Pripyat, using DX10.1, utilizes 80-100% of the Gpu, according to GpuZ. However I realize CoP is hardcore optimized for ATI/AMD.
Sorry to run off topic, pics coming. Was about to post them but I didn’t restore them onto the new rig yet… My bad not trying to hijack the thread…
Those teaser shots, no actual player-made footage (shows an early version of Valley)
To my knowledge OpenGL has a multithreaded feature. On the Mac client there is a macUseMTGL cvar which allows you tu run several openGL threads. Don’t know how it is on other platforms
The rest I can’t help you to answer, maybe google can.
Adding useless GPU cycle is optimization now ?
BTW QW runs faster on Intel CPU, everybody knows that. :armadillochase:
