[FTEQW] Modifing player velocity server side

[toneddu2000]

Hy guys! The more I learn about QuakeC, the less I can do what I want. I'd like to change player velocity, making it a lot faster. I tinkered SV_RunClientCommand() function and it works as single player game, but, once I use a local server and I connect with a client to it, player starts walking slow as always. Of course I can set in ftesrv.cfg sv_maxspeed to 2000 and then, when client connects, I can type in client console cl_forwardspeed 1800 but this is not what I want. I want a new multiplayer game that has a completely different physics from Quake, EVEN in multiplayer.

PS: I use FTEQW, compile with fteqcc as qwprogs.dat and for this game I use ONLY ssqc by now, so CSQC is not the problem, today!

Thanks in advance for any hint!

EDIT: same thoughts for sv_gravity!

[toneddu2000]

[Spike]

here's a vauge qc reimplementation of player physics that I wrote aaaages ago and never quite polished:
https://sourceforge.net/p/fteqw/code/HE ... n/pmove.qc
it has more of an NQ feel than a QW feel, however, as it re-uses some code that LordHavoc originally ported from the nq engine to qc, so its also GPLed as mentioned in the file.
the engine's runstandardplayerphysics builtin is somewhat similar to it, so it should give you a feel for what's going on.

basically, the server sets the input_* globals according to whatever the client sent, then calls your qc function so that you can do whatever you want with it. one trick is to just tweak the inputs and then just forward that on to the engine's implementation of player physics - this prevents prediction getting too broken, at least.

or you can figure out the direction the player appears to want to move in, accelerate towards that according to whatever weights you want, then apply gravity+friction, then try and move the player with tracebox, and clip the velocity according to whichever surfaces you hit. Or you could use movestep for really lame player physics.

the full thing can be a bit fiddly, in part because tracebox isn't aware of steps, requiring special logic to move up over them etc.

just directly hacking the velocity without considering input_timelength will make your player physics highly dependant upon the rate at which your client sends packets at the server. this is not a good situation. you're better off manipulating input_movevalues instead (and probably sv_maxspeed too).

[toneddu2000]

[Spike]

maxspeed and gravity (as well as a few other sv_ cvars have some quakeworld-derived awkwardness to them.
in the pre-final vanilla quakeworld protocol, the server sends these settings at the start of the game. there is no machinary to update them later. this means the server explicitly caches them at the start of the map (after spawn functions are run) and then ignores the cvars themselves for the rest of the map. this ensures that all clients receive the same values.
later versions added support for per-player .maxspeed and .gravity fields, as used by TF and hipnotic and stuff, and these additions CAN be changed mid-game.
FTE should already be emulating sv_gravity changes with this mechanism paired with a little maths.
if its not working then I messed up. the traditional way is to use cvar_set in the ssqc to set gravity (as is done with e1m8 - beware race conditions). using cvar_set instead of localcmd is required if you wish to ensure the movement cvars are actually set before the engine locks them down as part of the map-change logic. in contrast, localcmd has a small delay to it meaning the actual result happens AFTER everything else in the console buffer has finished executing.

if it works in single player, it should work in multiplayer too. especially in coop.
any differences are more likely to be down to the time at which the player joins the game - singleplayer is generally much sooner. I can't think of any other reason right now.

[toneddu2000]

[Spike]

each engine has its own set of cvars, whether they're client, server, or both.
localcmd adds the specified text to the local engine's console command buffer thing (regardless of whether its called from csqc or ssqc). stuffcmd sends it to a connected client (possibly the same machine as the server, but also appears in demos) for it to be executed there instead.

if you set sv_gravity on the server then yes, that's on the server, not the client.
the client doesn't know the value of all the server's cvars. they're on the server - not the client.
the server settings the client does know are normally exposed via the serverinfo stuff (using that command on the client will show you the official serverinfo strings, there are a few special extras that are visible only to csqc as somewhat of a hack, check fteextensions.qc for those names).

[toneddu2000]

[Spike]

[toneddu2000]