changing map == restarting server? [SOLVED]

[OneManClan]

[edit: I changed the 'subject' from 'Baffling SV_RunClientCommand bug.. ' because this might not necessarily be a SV_RunClientCommand specific issue]

Hi all,

IIUC every map change is a 'fresh beginning', the engine re-loads ALL variables and functions from the dat, including built-ins, and 'entry point' functions. I have a situation where 'it appears' that a function behaves differently, depending on whether the server has just had a map change, or has just been restarted. This AFAIK, should be impossible, so I'd appreciate some feedback as to what might be going on. Here's the details:

I defined SV_RunClientCommand in the progs, which IIUC simply tells the engine to use it, instead of it's internal SV_RunClientCommand.

Code: Select all

//at the bottom of client.qc
void() SV_RunClientCommand =
 {	

// This is where code that overrides player movement would go, removed for diagnostic purposes

	runstandardplayerphysics(self); // IIUC this means that all movement code is sent back to the engine, unmodified.
 };

Ok, AFAIK, this 'bare bones' function should do exactly *nothing*, however... it results in players falling through the world, with their origin_z decreasing forever. Spike's suggested (thanks Spike) that "the only thing I can think of is weird ordering with prethink+think+touch+postthinks ..probably resulting in the world getting moved somehow .. probably some global not being reset or preserved properly between pre and post think". I'm trying to look into this, but in the meantime ... have been getting weird and baffling results when compiling and testing.

Here's the actions I took, and the 'results'.

1: Write the 'substitute' SV_RunClientCommand (as above), compile, run the (fte) server, then run the (fte) client, and connect to 'local host'.
RESULT: This produces the 'fall through the floor/map' bug as described above.

2. Rename 'SV_RunClientCommand' to 'SV_RunClientCommand2', compile, and in the (still running) server, change map
RESULT: The player DOESN'T fall through the floor (ie as would be expected), because we are using the engines internal SV_RunClientCommand, because ours no longer exists (ie the renamed SV_RunClientCommand2, as above). Bug aside, this makes sense, however:

3. Rename 'SV_RunClientCommand2' back to 'SV_RunClientCommand', compile and in the (still running ) server, change map.
RESULT: Now .. for some reason... everything (appears to) work perfectly! The server *is* using the SV_RunClientCommand in the progs ( I put some dprints into it to confirm), but players are NOT falling through the floor.. the bug is gone(!?).. however:

4. Close server exe, restart it, reconnect to localhost w client.
RESULT: .. bug re-appears! .. we're back to the player falling through the floor, again!!?!

I repeated the above steps many times (because it doesnt make sense, and in case I had made a mistake) , but got the same results.

Can anyone offer any ideas as to what might be going on?

OneManClan

[OneManClan]

Hey people,
Here's a video of me demonstrating the issue, which might clarify the situation better.

ps If anyone can think of a better/more concise way to describe the 'subject' of this topic, please let me know.

[Cobalt]

Hrm, well in normal Netquake, MAP command will knock/ disconnect all players out of the game, unless you are the first player in listen mode. Apparently FTE
permits this to happen, as opposed to the changelevel command - where player slots are preserved.

What Spike says seems kinda on the right track. Something the engine (I dont think the QC , but could be wrong) upon startup is not doing something that the MAP command is. Im not familiar with QW type Qc, but in regular Quake C it would come down to something in StartFrame () or WorldSpawn () usually. Unless in QW the MAP command is preserving or assuming some player entity fields.... or this could really all be a setsize issue regarding the players first spawn into the server. The engine could also be fixing the setsize problem on the next map load. In normal Quake if the size of the player is bad, or if it spawns the correct size, and part of its hull happens to be sharing space with another solid , you will usually see the "falling through floor" effect in your video. Perhaps also the MAP command happens to detect this issue and fix / nudge the ent out of the solid, while starting the engine over "clean", puts the map up first, then puts the player in, bypassing the code that checks for this kind of problem.

[Zop]

I would say that running one progs, then compiling different code, then doing a map/changelevel command should give undefined (weird) results. I think a better test would be running the progs with a bug, then after seeing the problem, do a changelevel with the same progs to see if you get the same result. Also, try noclipping when it happens, and then shoot some weapons to see if it is the level's walls that are missing, or the player is not solid.

[OneManClan]

Thanks Zop, I was just responsing to Cobalt when your post came through.

Update: Thanks Cobalt for your suggestions. Spike has confirmed that issue was an..um.. er.. how shall I put it.. 'undocumented feature', of the FTE dedicted server. I had ruled out a server bug because two people confirmed that they could run the function in their mods with no issues, BUT ... they weren't using the dedicted server. Spike tells me its been fixed n the latest build, so this one is (thankfully) resolved.

[Spike]

on map changes, the gamecode is completely purged. and then reloaded.

the server has more state than just the gamecode, however. most of that isn't reset. players are not kicked, etc. you get the idea.
providing a SV_RunClientCommand function causes the server to follow a different path through the code - essentually it needs to redirect everything via QC to give the qc a chance to control everything instead. this path failed to set things up properly, but it worked fine if the server had previously used the fallback path, or if the client part of the same process set it instead (which is why it wasn't blatently obvious in my basic test code).

to clarify, the bug was in the runstandardplayerphysics builtin, rather than the handling of SV_RunClientCommand, so at least the main purpose of SV_RunClientCommand was unaffected even in dedicated servers. blurgh.