changing map == restarting server? [SOLVED]

[OneManClan]

[OneManClan]

Hey people,
Here's , 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.