Page 1 of 1

Client connecting during intermission

Posted: Fri Mar 27, 2015 6:30 pm
by Cobalt
as stated in the QC comments - "can cause problems".

I have experimented with this and it seems for some reason the client is being set to .team = 1 ? Not sure if thats something happening in my specific QC, but I am looking for that in ClientConnect () then passing him directly to PlayerPrethink () where it will see the intermission running and do the Intermissionthink, but instead blacken the screen and do a

WriteByte (MSG_ONE, SVC_FINALE);

Plus

WriteString(MSG_ONE, "Some cute text - blah");
...and some cute CD music.


So this works fine only when the next leve l loads, the (4) Runes that spawn at framecount 140, dont have models and their special precache sounds dont play. Is this something to do with the sign on packet?

Re: Client connecting during intermission

Posted: Fri Mar 27, 2015 9:24 pm
by Spike
the problems the qc comment aludes to are:
1) svc_intermission won't be shown for late joiners (qc would need to send it).
2) a delayed svc_intermission will show the wrong end time (there's no sane way for qc to work around this, although I suspect generating a manual svc_time would do it, but would probably break things at the same time).
3) qc doesn't track which svc_finale message was displayed (again, logically this is the qc's job).
4) oldone.qc/end.bsp sets intermission_exittime to something really high. a new player joining the game is the only way for a dedicated coop server to progress.
5) qc doesn't move the player to an intermission spot when they join mid-intermission

these things could be fixed satisfactorily via qc, but its somewhat rare and much easier to just move to the next map. besides, in deathmatch, moving to the next map helps you wake up when someone new joins.


the server isn't aware of intermission at all, the qc does all intermission-related serving.
the client is aware of intermission, but only cares as far as the hud/scoreboard/finale is concerned.

.team is set according to the player's lower colours, as the server is unaware of intermissions, there is no reason for me to believe that there is anything wrong here. 1 is a valid value if your lower colour is 0 (or white).
the client will send a "color" command just before it sends the "spawn" command, so the .team field is guarenteed to be set correctly before ClientConnect+PutClientInServer are called.

makestatic/staticsound builtins write their data to the MSG_INIT buffer. as a result, clients only see these if they join AFTER the builtin was called. its possible for a server to also send it to current clients, but this can potentially result in duplicates if not handled correctly.

Re: Client connecting during intermission

Posted: Fri Mar 27, 2015 9:25 pm
by r00k
look at the runequake source he handles sending new clients the sv _intermission and origin placement

Re: Client connecting during intermission

Posted: Sat Mar 28, 2015 4:54 pm
by Cobalt
Yep thats correct and its ok, its an experimental experience for people joining at the end of a level.
Spike wrote: 1) svc_intermission won't be shown for late joiners (qc would need to send it)..
Spike wrote: 2) a delayed svc_intermission will show the wrong end time (there's no sane way for qc to work around this, although I suspect generating a manual svc_time would do it, but would probably break things at the same time)
This sounds like it could be the reason why when the next map loads, the stuff in StartFrame() at frame 140 seems to not fully work. Basicly at 140, we spawn the 4 Quake runes as GLOBAL ents, precache and assign their models and precache their sounds. Whats happening is the runes spawn via spawn (), but their models dont show up and any precached sounds in the same routine apparently are not precached and wont play.

As a fix I did try a scv_time to the client , but it crashed the client with a packet dump.

Actually as far as I can tell, the only trouble so far after interrupting the normal intermisison QC is the stuff at framecount 140. Its as if there is no memory avail for the precaching of the models and sounds in that function, thus the precaching seems to be failing.

Re: Client connecting during intermission

Posted: Sat Mar 28, 2015 6:18 pm
by Spike
Cobalt wrote:Actually as far as I can tell, the only trouble so far after interrupting the normal intermisison QC is the stuff at framecount 140. Its as if there is no memory avail for the precaching of the models and sounds in that function, thus the precaching seems to be failing.
terminologically, precaching has a 'pre' prefix because its meant to happen in advance of it being used - ie: at the start of the map.
if you do it 140 frames in, then you're (late)caching rather than pre-caching (the client is quite likely to see it as post-caching, because reliable messages are typically higher latency than unreliables).
which is a significantly different thing, and the rest all depends upon which engine you're using.

FTE and DP both support late caching, with different levels of success (iiuc, late-cached bsp models might lack lightmaps, but this isn't an issue here). In both cases this REQUIRES protocol extensions, and thus might be silently ignored if you're using one of these engines with older network protocols (its either that or give you illegible server messages...).
other engines have absolutely no support for late caching, they ONLY support precaching right at the start of the map (spawn functions only, although I think framecount<3 is fine too, but best not to depend upon that). they may also crash if the server reports a modelindex that they do not know.

Re: Client connecting during intermission

Posted: Mon Mar 30, 2015 8:23 pm
by Cobalt
Thank Spike. Decided to precache the rune stuff in worldspawn , problem seems to be fixed.

Re: Client connecting during intermission

Posted: Mon Mar 30, 2015 10:59 pm
by r00k
yes, things that are not map entities should be precached in world.qc; ie not in weapons.qc.

i thought this thread was about putting clients into the intermission when they connect after an intermission had started.

Re: Client connecting during intermission

Posted: Tue Mar 31, 2015 6:37 pm
by Cobalt
Yea thats what I did, and it seems ok except for the code executing at frame 140 which was precaching sounds and models then spawning them.
So all in all you can keep a client that just joined in the intermission instead of the legacy code that just uses that as a trigger to go to the next level.
The issue I encountered as Spike said seems to be the late caching. For some reason the late caching was corrupted or failed, where clients that were already in the game before the intermission handled all the stuff at frame 140 just fine. The strange thing was thentities did spawn and all the related functions like touch, think and effects worked fine.....just the models were empty and the associated precache sounds for those ents did not work.

With DP, there is a built in "late cache" for sounds that are not pecached. So if you call for a sound not precached, DP detects it, and shows a con message

"SV_Startsound - blah not precached, precaching anyway, fix your code."

However in this case it did not say that.



r00k wrote:yes, things that are not map entities should be precached in world.qc; ie not in weapons.qc.

i thought this thread was about putting clients into the intermission when they connect after an intermission had started.