Be on the start platform on e1m6
I think I had a quicksave beforehand.

I wasn't able to replicate it.

It just died with that error. 

Well, I can't reproduce it either. We'll need to reproduce it reliably in order to find a solution. 

http://quaketastic.com/files/misc/touchlinks-test.zip

The player spawns over 4 nailguns. The nailgun touch function calls setorigin() to move all 4 nailguns to the other side of the map (into another areanode).

The map freezes immediately in fitz085, MarkV, QS, and works in QSS and DarkPlaces 

Indeed it freezes immediately. (Linux note: test this with -nomouse on the cmdline.) It doesn't even hit the NULL link error. 

the only way I can see that QC would observe Spike's version being different is if a touch function teleports something into areanode that is currently being visited by SV_TouchLinks.

e.g. player touches a lightning gun. the touch function teleports (with setorigin) a nailgun (from a different areanode) onto the same position as the lightning gun.

With the vanilla code, the nailgun touch function could run during the same SV_TouchLinks call.
With the fixed code, the newly teleported nailgun wouldn't have its touch function run until later (next frame in this case, when the player entity is relinked.)

This wouldn't be observable with id1 since trigger_teleport is delayed 200ms. 

the way I see it, the differences in what the QC might observe only appear when the QC does evil things that could crash vanilla anyway.
While that's no real guarantee that it won't break stuff, it does at least mean that you can fully blame whoever potentially crashed vanilla. :) 

I committed your patch with minor tweaks (hunk allocated array, made the touch->v.solid test in SV_AreaTriggerEdicts the same as the one in SV_TouchLinks.. shouldn't make much difference?).
https://sourceforge.net/p/quakespasm/code/1485/

Did some more experimenting, and it turns out you can make a teleporter setup that behaves differently depending on the engine's SV_TouchLinks, with vanilla id1 progs:
http://www.quaketastic.com/files/misc/touchlinks-test2.zip
(DarkPlaces = you pick up RL and SSG, winquake = you pick up SSG only). Kind of annoying since I was hoping this change wouldn't be visible to a map running on id1 progs, but I did set up the map specifically to show a difference..

My attempt to summarize the behaviour of vanilla's SV_TouchLinks:

Say the player touches a trigger_teleport, whose touch function setorigin()'s the player on top of a weapon pickup:
- if the weapon's areanode was visited by SV_TouchLinks before the player's starting areanode, the weapon's touch function won't run this frame
- if the weapon is in the same areanode as the player's starting areanode, the weapon's touch function will run this frame if the weapon appears later in the areanode's trigger list than the trigger_teleport
- if the weapon is in an areanode that hasn't been visited yet by SV_TouchLinks, the touch function will run this frame.

So to sum up, whether the weapon touch function runs the same frame as the teleporter touch is pretty much random. What happens in my test map is the player misses picking up the RL because the RL is earlier in the linked list than the teleporer they just arrived through.. but there's another teleporter later in the list that can still be touched on the same frame, so they go through that before they have a chance to pick up the weapon.

With the new patched SV_TouchLinks, the weapon touch function will never run until the next frame. Hopefully QC code / maps are not relying on touch functions making changes and then other touches happening as a result that same frame, since whether that is possible in vanilla is unreliable. 

At this point, darkplaces does so many other things that you can't pin such a difference on any single feature.
We're talking ordering here, so things like a different world size can change the places of the collision nodes. DP uses a 2d grid instead of a kdtree which ensures a different order. DP also puts triggers and non-triggers (even non-solids) into the same lists.
Whereas FTE has all the same stuff, but gets only the shotgun (matching your winquake claim)...
The fun thing is that if I load up the .map directly in FTE then I get neither weapon!

Its worth noting that DarPlaces has only the bounds checks inside 'SV_AreaTriggerEdicts' and they're missing from its SV_TouchLinks-equivelent.
This guarantees that the RL will be touched.
Which is probably the safest behaviour, if it were not for triggers potentially getting touched from the other side of the map after a teleport. The only types of triggers that I can think of that might actually care are q3-style jumppads (ones that actually aim properly), and I don't really see one occupying the same space as a teleporter (q1 pushers might overlap, but they at least don't care about starting points). 

I should have mentioned, QSS gets RL+SSG on the test map (with the SV_TouchLinks_New) or just SSG with pr_checkextension 0 (reverting to the old quakespasm SV_TouchLinks). Quakespasm gets RL+SSG since r1485, before that it got just SSG.

I'm surprised FTE doesn't get the RL. 

http://quakespasm.sourceforge.net/tmp/93_RC1/

Release candidate for the next QS release, thanks to szo for building the binaries. Note the above link is temporary and will only be around until we do the official release.

Biggest change for players is that the QS changes to "always run" are disabled by default; if you want:
- Shift to act as the "walk" key, when always run is on
- always run to be affect all directions (forward/back, side, up/down)
as they did in 0.92.1 and earlier you need to select Options -> Always Run -> Quakespasm

Aside from that there is a long change log (see the readme.txt); this has all of the limit increases from the ad_sepulcher "quakespasm-admod.exe" and can run Orl's episode. 

Orl's episode
So KenChennar = Orl? 

what's again the diff between the QuakeSpasm, and QuakeSpasm-SDL2 ?

And what about the spike version ? 

(see the readme.txt)

Quakespasm utilizes either the SDL or SDL2 frameworks, so choose which one works best for you. SDL is probably less buggy, but SDL2 has nicer features and smoother mouse input - though no CD support. 

Mugwump: yeah, see Orl's post in the episode thread.

Barnak: Generally you should use the "QuakeSpasm-SDL2" one, it has more features (game controller support, specify refresh rate, desktop fullscreen, etc). "QuakeSpasm" is using SDL version 1.2 which is officially at the end of its life, but supports old OS'es (windows 95, mac 10.4). 

 

... and no Spike effects. What gives ? 

QSS and QS have not merged into one, this is an update for Quakespasm only. Although, I slowly added some fixes/improvements from QSS to QS this past year (not the new protocol and particle system though). So - I don't know what the plan is for QSS. 

Eventual merge and option to toggle extension advertisement to the mod so particles could be either pixelly or DP??? Maybe hopefully someday. 

Seems when I updated to "Quakespasm-0.93.0-rc1" that when I walk up to a pedestal(sorry hate the word: PLINTH) the screen no longer goes dark making the text easier to read.

Is it just my setup? 

Hi! Seeing that people complain about this issue in unrelated places, I've made the patch, which automatically switches to protocol 999 when map bounds exceed -16384..16384 range (not sure this is a correct range, but that's easily fixable :) ). 

I wasn't aware this was an engine specific issue but this does make things easier.

So If I want something coded I just need to name my post "Not a request" - cool! 

I need to experiment with this a bit; one potential problem is a map like telefragged.bsp is right on the edge of the protocol 666 signon buffer limit, and won't load under protocol 999 in QS (signon buffers are larger with 999 since coordinates are 4 bytes instead of 2). I think that map has world geometry extending past +-4096 too.

Maybe checking if hull1 bounds exceed +-4096 would be a more robust heuristic? It would avoid false positives that work properly in 666, where the playable area is +-4096 but scenery extends beyond. 

For the most part, FTE+QSS doesn't use the signon buffer. Ambient sounds are QSS's last hold-out (excluding things the QC might explicitly write, but tbh I don't think I've ever seen a mod that actually does).
This basically obsoletes the signon buffer size limit, allowing for pretty much unlimited entities etc.
Additionally the revised entity networking doesn't need to send coords with every single packet either (and even if the mod forces it [eg: AD's sprite particles], it can do so over multiple packets, which avoids overflow issues with the datagrams too).
Port that part of my code over and it becomes a non-issue.

The real problem is when exactly 999 should actually be used...
Even small maps will benefit from increased angle precision on rotating things, so arguably the answer is 'always'.
In FTE's case I aim for network compatibility which means I try to auto-enable to as infrequently as possible (while fte supports multiple protocols simultaneously, it still can't cope with primitives changing sizes for different clients). Thankfully for QS, it doesn't really need to care about any of that.

Some maps have non-interactive geometry outside the 4k range in the form of a skyroom or whatever. Some might even have monsters (ready to be teleported in).
So perhaps the real solution here is to just create two new worldspawn fields - one to specify required origin range, and one to specify required angle precision.
The server would then be free to upgrade as desired, or not (if the default setting causes overflows/etc).
That or just upgrade everything so that it can be used by default/unconditionally (like DP does or FTE/QSS could). 

How does this sound for worldspawn keys?
"_maxcoord" "10000" if you need +-10000
"_anglebytes" "2" for requesting 16-bit angles

Yeah - this would be more robust than trying to guess based on looking at the bsp, which would also be a mess if different engines had different heuristics.

re: signon - yeah, I need to check out QSS's code for this again. 

I think I'd rather anglebits instead of bytes. Maybe I'm just weird. It doesn't really make any difference unless some crazy engine dev decides to splurge bits instead of bytes (like q3 does...).
And now I'm wondering what interpretations engines might make if they support different sized angles in different places... (client->server angles changing can be problematic, though 666 already uses 16bit angles there anyway).

Side note: in multiplayer situations, consider giving any out-of-order unreliables time to arrive before protocols are switched.

Could also be worth adding it to your qbsp too, if only to warn when large maps are not explicit about it.

Oh, I just remembered the issue with certain bsp entities with an erroneous angle of -1 breaking on engines with 16bit coords. that makes defaulting to 16bit angles messy too. Explicit limits are nice...

re signons: QSS+FTE dynamically allocate lists of the objects instead of storing raw network data, which allows them to selectively support extensions (although with baselines that data is already known anyway). This is overkill if your only aim is to remove signon limits. It would be easier to just create a list of signon buffers and allocate a new one when the previous one gets a little full. Its not as fancy but it'll get the job done. Really it just depends on whether you know what your clients will be given before they even connect...