Or was that for swampy. If you are having too much trouble, switch to an engine that supports drawing EVERYTHING when outside the level bounds...oh wait you can't because QS/QSS and QuakeDroid are the onlyones that support AD lol. 

is there any way to configure coop to work properly? it keeps dropping packets and a lot of things like bullets and particles aren't showing up on the client. 

The packet size limit of Quakespasm is fixed at compile time (DATAGRAM_MTU 1400), I've tried raising it to 32000 for testing coop and it worked OK, but routers/internet are not required to deliver large packets from what I understand.

try Quakespasm-Spike; it has a new network protocol which is supposed to be better for coop: http://triptohell.info/moodles/qss/ 

thanks, the datagram thing totally worked.
there's one weird quirk though, maybe you can tell me what causes it.

most maps load on client, but synchronization problems get really bad as they get bigger and water of any type is completely unrendered. sepulcher doesnt load at all on client, host says "sz_getspace: overflow" when client is trying to connect. adjusting r_wateralpha once on client makes the water reappear, performance is way better and sepulcher actually loads, but you have to do it every time after connecting. lava and portals seem to be unaffected by whatever is causing this. 

thanks, the datagram thing totally worked.
cool!

most maps load on client, but synchronization problems get really bad as they get bigger and water of any type is completely unrendered.
Not sure what's going on with the water, or synchronization problems in general (could be packets are being dropped).

Turning off AD's particles ("temp1 0" in ad/quake.rc) is a good idea because each one is an entity and they generate a lot of network traffic.
I think if you use QS-Spike they no longer use entities, but I'm not 100% sure.

sz_getspace: overflow - This is the "signon buffer overflowed" message. Not sure why it would show up in coop but not singleplayer, maybe there is some extra info that gets sent in coop for some reason.

Quakespasm-spike should have this limit removed entirely so that would be what I would recommend trying next. So what made the "sz_getspace: overflow" error go away again, wouldn't just be changing the r_wateralpha cvar on the client? 

i made a mistake. i tested it at least a dozen times and it always worked after adjusting it, and never when i didn't. but apparently that was just coincidence.

once i tried connecting 3 times in a row without changing anything and it actually connected on the third, but i haven't been able to replicate that again and now it either connects first try or never until i restart everything. then i was sure it was related to connection quality, since it seemed to always work on a wired connection and only sometimes on wireless and there was a huge difference in network performance, but then it eventually refused to connect on a wired connection aswell, with the same overflow error.

i also don't really understand whats going on with the water, there are 3 different scenarios for the client. either it is completely invisible, but if you check r_wateralpha it has a value that should be visible. sometimes it is totally opaque and r_wateralpha reflects that accurately with a 1, and other times it simply carries over the value from the previously loaded map. sepulcher is supposed to have 0.6, and start has 0.65, so the client will sometimes have 0.65 while the host has 0.6 when i changed the level after connecting.

i tried spikes version but that has the exact same problem, only worse for some reason. it happens for much smaller maps like magna at a rate comparable to sepulcher in regular quakespasm with the limit removed.

can the signon buffer size be increased as easily as the packet size limit? i'd like to test that in my quakespasm build to see if it makes a difference. 

With QSS as a server, set sv_gameplayfix_spawnbeforethinks 1. This prevents PlayerPreThink etc getting called on player entities that have not actually been spawned yet, thereby preventing AD from spamming at the worst possible time.
You should then be able to connect just fine, every time.

However, I fucked up such that the above cvar doesn't do its job on map changes. Reconnecting will work fine until the next map change, thankfully most AD maps have shotgun starts so this shouldn't be too annoying beyond the hassle of it.

@sock
the overflow comes from spammed v_cshift stuffcmds (somewhere inside PlayerPostThink) to players that haven't even been ClientConnected yet, this then overflows the waiting signon data.
Normally I'd say its just an engine bug, but it goes all the way back to vanilla (so applies to more than just QS[S]) and the general policy is to not break other mods that actually depend on weird legacy behaviour (hence the gameplayfix cvar defaulting to 0). 

the overflow comes from spammed v_cshift stuffcmds (somewhere inside PlayerPostThink) to players that haven't even been ClientConnected yet,

It looks like like it's coming from this ResetDebuffSystem() call (the internals of that do the stuffcmd unconditionally.)

//----------------------------------------------------------------------
// Core debuff function, run every frame from client.qc
//----------------------------------------------------------------------
void() ClientDeBuff =
{
// If player is dead or intermission running, turn everything off
if (intermission_running > 0 || self.health < 1) {
ResetDebuffSystem(self);
return;
}


Probably adding a (self.flags & FL_CLIENT) check should do the trick? 

yup, totally does the trick.

thanks for the help, both of you :) 

why are some of them so janky and others just fine? most of them you clip into a little bit like the two in start, very few are completely fine like the first on tfuma, and others are really bad making you jump up and down like the second one on crucial. 

First, make sure you aren't playing with max fps set higher than 72 (60 might be more consistent). Quake has a long standing physics bug that isn't framerate dependent.

The clipping might have to do with making a func_plat that also includes clip brushes. Some elevators have invisible brushes to make them into a solid rectangular box so players don't get trapped under the lip and get their heads bonked. 

A "smooth out stair step ups" engine change may also resolve this. In view.c: https://github.com/id-Software/Quake/blob/master/WinQuake/view.c

Change "oldz += steptime * 80;" to "oldz += steptime * 160;" and a lot of elevator jankiness goes away.

This change is in Bengt Jardrup's engine, but what's not clear is how he knew to make the change nor where he got the figure of 160 from. 

Elevators (and ramps) that are inside a trigger_fog or other trigger that does a stuffcmd every frame defeats the movement smoothing.

I debugged it a bit and cl.onground was getting set to false after each stuffcmd, which disabled the smoothing, but I didn't track down how cl.onground is linked to the stuffcmd-ing. Quakespasm-Spike's new protocol avoids this, but I'm not sure what change is responsible. Do you know what's going on, Spike?

test cases:

jittery:

temp1 0 # enable the stuffcmds inside trigger_fog
map ad_swampy.bsp
notarget
setpos -67 1368 840
noclip


smooth:

temp1 2048 #this disables the stuffcmds inside trigger_fog
map ad_swampy.bsp
notarget
setpos -67 1368 840
noclip


you need to walk off the plat and step back on. Look at the floor (plat surface) to see the jittering. You might have to ride the elevator a few times to see it jitter, but the "smooth" case is always smooth. 

Ok, did a bit more debugging (quakespasm / protocol 666), and it seems the client gets a net message with just svc_stufftext, and no svc_clientdata. onground gets set to false on every received network message unless there is svc_clientdata in it, so that is how the stuffcmd causes the stairstep smoothing to be reset. Not sure about the bigger picture like why does PF_stuffcmd result in a standalone net message without a svc_clientdata?

I guess the best solution assuming qc changes would be to use fitzquake's built in fog interpolation over time, which would avoid spamming the network with fog changes. 

svc_clientdata is normally present in every single _unreliable_ packet (the exception being nop packets).
Unlike Quakeworld, in NQ all reliable data (like stuffcmds) is sent in separate packets. hence why you're getting a packet that contains only a stuffcmd. This is true even for DPP7 and QSS.

There really is nothing specific to stuffcmd here. there are many other ways to trigger small reliables without svc_clientdatas.


FTE/QSS's network protocol considers the onground flag to be part of entity state, and doesn't even use svc_clientdata any more.
I don't recall any particular reason why you can't just do similar, and set/clear it only on reception of svc_clientdata (and CL_ClearState). I probably ought to do just that in QSS. Flagging the player as offground can affect things like bobbing, but its better to make sure any such unwanted effects are disabled by map changes, pause, or whatever, instead of potentially breaking on random reliables. 

i changed it to 160 and it's smooth as butter now.

completely unrelated, my save file somehow got corrupted in the most bizarre way i have ever seen. all the detail prop models have been shuffled. lit candles are now shell boxes, unlit candles are fire, and fire is a health kit. the zombie knights are invisible except for their swords which attack you without any sort of animation, and the shadow axe is duplicated and doesn't disappear when picked up. everything goes back to normal when you change level or restart.

would be super impressed if someone could explain how this might have happened. have a look at it yourself if you're curious, there's even more weird shit like the fire that gets abducted into the ceiling immediately.

https://drive.google.com/open?id=1jFNJH3Z84DfK56GrWRFpNpm1sqHBJWQx 

Quake stores all the models in an edict list on map load (or was it game start, whatever). If you load a saved game in a different mod or different version, the edict list could be different amd thus the referenced model for each object is off from where it should be in the list. 

Thanks! That explains everything. set/clearing cl.onground only on reception of svc_clientdata sounds like a reasonable change. 

it has nothing to do with edicts.
its the model indexes. precaching models in a different order can and will result in the model indexes referring to different models.

there are all sorts of ways to trigger the issue, from updating a mod or map between saving+loading, to mods that just use non-deterministic precaches such that they all get renumbered on reload.
If the mod ever uses random() in order to decide which model to precache then the mod is buggy.

FTE+DP+QSS are meant to write out the precache list so that it can be restored properly afterwards, which should allow non-deterministic mods to reload games properly.
Don't expect to be able to fix the game by just loading your existing save with one of those engines - if the saved game doesn't include the data then it'll have to be made up somehow - which means guessed, which means buggy. 

I would really like to know if there is a way to play Arcane Dimensions (v.1.70 patch 1) in co-op using Quakespasm (0.93.0). I tried to make it work but I'm always getting some kind of connection problem message. Is there a tutorial for that anywhere? 

Scroll up a bit to #649, I asked the same thing a few days ago.

Right now you either need to compile Quakespasm and AD with the minor changes to the source code mentioned above, or use Spike's version of Quakespasm (QSS) and set "sv_gameplayfix_spawnbeforethinks 1" in the console. If you're going to play over internet I would recommend just going with QSS, it will perform much better. 

The documentation and editor description led me to believe it makes the entity aware of the player right away regardless of distance and sight obstruction, which is exactly what I need for my map. I tested it with multiple monsters and it doesn't seem to make any difference at all, flagged entities are still idling until attacked or within the detection radius. 

I think you need to specifically trigger them IIRC. 

it's only useful when they spawn in. 

It's funny that just searching for "serpent runekey" brought me here. Anyway, thanks for the hints, they were much appreciated. I felt like an idiot after finally finding the secret. I tried so many things.