[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]

Solved by myself. I studied better SV_RunClientCommand(). For those interested, just write something like

Code: Select all

PSEUDOCODE
makevectors(input_angles)
if(groundcheck)
velocity increase

That's it. Well, thanks to me!

[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]

Thanks Spike for your answer. Sorry for my late reply, very busy in these days.

Yeah, I read carefully pmove.qc in the past but I thought that was just for csqc. In fact in my purecsqc demo I wrote some time ago I made a completely functional (but very very simple) physics completely from scratch.

ust 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)

Thanks, this is a great suggestion. In fact I'm trying to use input_movevalues and input_timelength. I'll post all the source code when finished as CC0 because I hate GPL (and that's why I didn't take too much in consideration pmove.qc and I look forward to a -from scratch- solution).

Regarding sv_maxspeed, there's a way to change this value directly via code? Because I tried to launch a timered function that should have changed sv_maxspeed to 1000 and sv_gravity to 2000 it in worldspawn but, in a multiplayer game is not taken into account.

My question is: if "ss" in ssqc stands for "server side", why some functions (for example the one that change sv_gravity and sv_maxspeed values) I wrote in ssqc are completely ignored in a multiplayer game?
Should'nt all code wrote in ssqc be also functional in multiplayer game(differentiating it from csqc code)? I cannot understand this!

Thanks again Spike

[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]

Thanks Spike for the explanation, now I now when cvars should take effect.

Unfortunately it doesn't work. If I set at the very bottom of worldspawn

Code: Select all

cvar_set("sv_gravity","1800");
cvar_set("sv_maxspeed","2000");

Then I launch the server and I interrogate it with sv_maxspeed, it says 2000
but when I launch clients and I interrogate console with sv_maxspeed, it says 320

I need to change mid-game cl_forwardspeed to 2000 to make player go faster, which it's not what I want because player could change velocity with cvars and I want that player can ONLY change their name and that's it (technically I could use CSQC_ConsoleCommand() to avoid cheating attempts but that's not the point of my question, even because I could want to create a ssqc only game).

So, really there's not the possibility to change server side player speed? That's really strange

.maxspeed doesn't seem to have any role on player speed

Another question, what's the difference between localcmd and stuffcmd? Former is for local client and latter is for all clients connected?

Thanks for your help

[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]

each engine has its own set of cvars, whether they're client, server, or both.

Well, as post titile said, I'm using FTEQW, so it'd be great to know a little more of FTE cvars

localcmd adds the specified text to the local engine's console command buffer thing (regardless of whether its called from csqc or ssqc).

And for "local" do you mean client console, right?

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.

"Possibly the same machine as the server"? But the server shouldn't be considered "server"?
So if I wrote "self.netname" in stuffcmd, it wouldn't print connected client netname?

if you set sv_gravity on the server then yes, that's on the server, not the client.

That's the point I cannot understand. How can I BE SURE to talk to server and when, instead, I can be sure to talk to client? I mean, CSQC is a "modern" invention created by you, but, in 1996 how could be possible to refer to server and clients distincly?
When you say "if you set sv_gravity on the server", do you mean "write sv_gravity in ftesrv.cfg" or "put it via cvar_set in a specific function in ssqc (in this case, it would be great to know which function is, because worldspawn() didn't sort any effect)"?

the client doesn't know the value of all the server's cvars. they're on the server - not the client.

This probably of ot the most ununderstandable statements I've ever listen in programming. As a completely noob as I am, I've always imagined that, in a client-server architecture, all data are queried by client and stored on server, so that all clients can retrieve same informations.

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

I checked here and only 2 functions talk about serverinfo:

string(string key) serverkey = #354; /*Look up a key in the server's public serverinfo string */

string(entity e, string key) infokey = #80; /* Part of QW_ENGINE If e is world, returns the field 'key' from either the serverinfo or the localinfo. If e is a player, returns the value of 'key' from the player's userinfo string. There are a few special exceptions, like 'ip' which is not technically part of the userinfo. */

so maybe the correct usage is

Code: Select all

void worldspawn()
{
//retrieve gravity from server
local string mygravity = serverkey("sv_gravity");
//apply at the very bottom to clients
cvar_set("sv_gravity",mygravity);
}

Right?

Thanks a bunch man!

[Spike]

Well, as post titile said, I'm using FTEQW, so it'd be great to know a little more of FTE cvars

cvarlist.

And for "local" do you mean client console, right?

each process has its own console command buffer. if you have the client+server running in a single process then they share consoles. if they're different processes on the same machine then its in no way different from different processes running on computers on the other sides of the world, just different latency/packetloss.

"Possibly the same machine as the server"? But the server shouldn't be considered "server"?
So if I wrote "self.netname" in stuffcmd, it wouldn't print connected client netname?

stuffcmd(self, sprintf("echo %s\n", self.netname));
that will always display the player's own name and never anyone else's. it will not appear on a dedicated server, but will appear on a listen server if the client is connected at the time (ie: still won't appear if its done in worldspawn when there's no players that have spawned yet).

When you say "if you set sv_gravity on the server", do you mean "write sv_gravity in ftesrv.cfg" or "put it via cvar_set in a specific function in ssqc (in this case, it would be great to know which function is, because worldspawn() didn't sort any effect)"?

in world.qc you will normally find this code:
if (self.model == "maps/e1m8.bsp")
cvar_set ("sv_gravity", "100");
else
cvar_set ("sv_gravity", "800");
if you don't find it, then someone has probably moved it elsewhere.
this also prevents config-set values for sv_gravity from being used.

This probably of ot the most ununderstandable statements I've ever listen in programming. As a completely noob as I am, I've always imagined that, in a client-server architecture, all data are queried by client and stored on server, so that all clients can retrieve same informations.

the client and server are separate and distinct. the client interpolates between a series of snapshots that the server sends to it and thus the client simply doesn't need to have a copy of every single cvar on the server. trust me in this - you don't want to have to sit around waiting for all that data to be transmitted at the start of each map.
csqc might care about some of it. you can use serverinfo for most of that stuff, or stats, or fields, or stuffcmds.
so yes. client and server have their own entirely-separate cvars. often they'll have the same value, and often they'll differ (like the 'name' cvar that controls the name of the player). what you would never want would be for all clients to be forced to use the server's mouse sensitivity etc.

serverinfo+userinfos are a quakeworld thing. quakeworld also has localinfo, but frankly that's obsolete due to cvars being more friendly, its kinda munged in with the serverinfo overriding it and basically breaking things, many quakeworld mods used it as a poor-man's way to perform string manipulation thanks to localcmd's string concatination.
each player has his/her own userinfo string (name, colours, etc). the server has its own userinfo string (hostname, map, etc), each qc module can query any player's userinfo or the serverinfo. only the ssqc can see the localinfo but cannot easily distinguish between serverinfo or localinfo.

some cvars are flagged as either userinfo or serverinfo, and changes to these cvars directly update the respective info, and changes to the info change the cvars in turn.

so maybe the correct usage is
...
Right?

no, not really.
the serverkey builtin is csqc-only for some silly reason. I ought to change that.
in ssqc you currently need to use infokey(world, "keyname") instead.

use:
localcmd(sprintf("serverinfo %s \"%s\"\n", keyname, keyvalue));
to change a serverinfo key.

[toneddu2000]

Thanks Spike for the clarification. The client-server part, actually, instead of clear my mind, make it more cloudy, but, however, if quake uses this system, there's no way to change it, so it's better that I start to learn its basics!

cvarlist.

Thanks

each process has its own console command buffer. if you have the client+server running in a single process then they share consoles. if they're different processes on the same machine then its in no way different from different processes running on computers on the other sides of the world, just different latency/packetloss.

Usually I start a dedicated server on my local machine, to emulate server, and then I create 2 or more clients on same local machine and I connect to 127.0.0.1. I assume server and client(s) are separated processes, right?

stuffcmd(self, sprintf("echo %s\n", self.netname));
that will always display the player's own name and never anyone else's. it will not appear on a dedicated server, but will appear on a listen server if the client is connected at the time (ie: still won't appear if its done in worldspawn when there's no players that have spawned yet).

Ok, I'll try it, thanks!

in world.qc you will normally find this code:
if (self.model == "maps/e1m8.bsp")
cvar_set ("sv_gravity", "100");
else
cvar_set ("sv_gravity", "800");
if you don't find it, then someone has probably moved it elsewhere.
this also prevents config-set values for sv_gravity from being used.

Yeah, I tried that early. But in fteqw, server changed it but not clients. I think it's due to different time when they access worldspawn, I guess

the client and server are separate and distinct. the client interpolates between a series of snapshots that the server sends to it and thus the client simply doesn't need to have a copy of every single cvar on the server. trust me in this - you don't want to have to sit around waiting for all that data to be transmitted at the start of each map.
csqc might care about some of it. you can use serverinfo for most of that stuff, or stats, or fields, or stuffcmds.
so yes. client and server have their own entirely-separate cvars. often they'll have the same value, and often they'll differ (like the 'name' cvar that controls the name of the player). what you would never want would be for all clients to be forced to use the server's mouse sensitivity etc.

serverinfo+userinfos are a quakeworld thing. quakeworld also has localinfo, but frankly that's obsolete due to cvars being more friendly, its kinda munged in with the serverinfo overriding it and basically breaking things, many quakeworld mods used it as a poor-man's way to perform string manipulation thanks to localcmd's string concatination.
each player has his/her own userinfo string (name, colours, etc). the server has its own userinfo string (hostname, map, etc), each qc module can query any player's userinfo or the serverinfo. only the ssqc can see the localinfo but cannot easily distinguish between serverinfo or localinfo.

Ok, kinda understood, thanks a lot for the explanation

use:
localcmd(sprintf("serverinfo %s \"%s\"\n", keyname, keyvalue));
to change a serverinfo key.

Ok thanks, I'll do it!