toneddu2000 wrote: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.