Only skimmed what u wrote and that's great :) 

Sock also just retweeted a blog article by the same author, more about "pixel graphics" in general rather than only talking about AD: https://twitter.com/SimsOCallaghan/status/977864228118941697 

Hi,
Im running the later Quakespasm on a mac and looking at this video: https://www.youtube.com/watch?v=K8JWgsz8-lQ

I think Im missing the rain and some "smoke trail" with the torches and grenades maybe.

Am I missing some configuration? Im running a very clean config with just a texture 2 change and some joystick (due to handicap).
Thanks 

Regular Quakespasm does not have those effects. You need to run AD with "quakespasm-spike-admod.exe" to get those special effects. 

Here it is, app is inside: http://www.simonoc.com/files/ad/quakespasm-admod-macOS.zip 

may the gibs be in your favour! 

So, sock himself is using QSS to play AD. This should be enough reason to switch to QSS over regular QS for playing this mod. 

How can I contact you with a question about one of your maps? 

maikfranzxaver -at- gmail -dot- com 

 

FYI... QSS != quakespasm-spike-admod 

has anyone managed to find all of the new 10 secret triggers in ad_e2m2? there used to be only 3 before it was updated in 1.70. After hours of not finding any new secrets i didn't recognize from 1.60 I noclipped around the entire map still and couldn't find the last 2 anywhere, which is kind of weird since there should be rooms of some kind for them, but there don't seem to be. is this a bug or am i just too stupid to see them? 

nevermind, i'm stupid. 

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.