svc_spawnstatic and reading jdhack's mind

[Johnny Law]

[Johnny Law]

[Spike]

presumably svs.clients[0].spawned should be false when changing levels.

sv.signon is the signon message buffer. its a reliable buffer which is sent as part of the intial connection (when you first sign on). it also contains other precaches and things (the precache_model should be first, obviously). adding to it mid-map will NOT be visible to clients currently on the server.
thus checking the spawned setting *should* allow it to only fire when the client is already on the server and will thus be unable to see the signon buffer.

there might be a race condition between setting spawned and signons. in single player you're not likely to notice it, but its possible. iirc during this window the client won't receive either.
in multiplayer, the extra code is too hacky to be useful, and may be counter productive for modders who think that it'll work in multiplayer as it does in single player (including coop). by my definition this is a bug, or at best a hack, undesirable either way.

presumably, the logic used should be the same as the lightstyle logic iirc.

(all this stuff got rewritten in QW... and again in FTE... so I might be wrong with a few things)

imho the problem comes from requiem's protocol promotion feature. if there's more than 255 models precached, just switch protocols right from the start instead of randomly mid-message, that should help solve precache index sizes.

[Johnny Law]

Ah. I'll check the spawned flag's behavior when I get back to a debugger tonight, but it looks like it's not set false until SV_SendServerinfo, which is after PR_LoadEdicts. (And then set true later, at the end of the signon process, after everything in my initial post.)

I think I've got my head around the desired behavior at this point. The "create" console command is supposed to be used only from a local client, and only when the current number of clients is 1. (And this is enforced in Host_Create_f.) Pushing svc_spawnstatic cmds into svs.clients[0].message should take care of updating the local client with the created entity. Pushing the same svc_spawnstatic cmds also to sv.signon doesn't hurt, and if a new client happens to connect it should get the created entity from there.

The kicker is that for the normal svc_spawnstatics during changelevel, we only want to put the cmds into sv.signon, and the client's spawned flag isn't the protection that is needed to avoid inappropriately dumping things into svs.clients[0].message at that time.

(I'm getting pretty curious to see what happens on changelevels other than the zendar test case.)

If I really want to make sure that jdhack's snippet is only used during the PR_ExecuteProgram for this new "create" command, there's a global (allow_postcache) I could use to guard for that. Might be all that is required. That global is currently being used to allow PF_precache_sound and PF_precache_model during that PR_ExecuteProgram.

I hate using globals this way... I wonder if there is some other client state that would express this situation more accurately than the spawned flag does. (Edit: or as an alternative maybe set the spawned flag false at an earlier point, in some circumstances? That seems iffier though since other code also looks at it.)

And this is sounding a lot like the previous issue. Shared code with some behavior that should only be performed when one of its way-up-the-stack callers is invoked from a particular context.

[Spirit]

The create function is by the way.

requiem also does something to decide which protocol to use, maybe that is somehow involved too? I have no idea how it does it so I might be just adding noise here.

edit: Oops, read over Spike's last line saying that.

[Johnny Law]

The protocol promotion feature is gnarly enough that it could indeed have some lurking bugs, but it doesn't seem to be involved in this particular problem.