The mysterious engine killing teleporter

Make sure you have no unsaved work
Install http://www.bendarling.net/downloads/prox/prox_10.zip
map proxmap2
Enter arena 4
Step into the teleporter near 264, 1197, -2843
Curse like a filthy pirate!

I tried it with the following engines on Linux (which shouldn't matter, right?):

Native:
-tyrquake WORKS
-SDL Fitzquake freezes (freezes mouse even after, running the engine normally again fixes this)
-FTE (from August 08), same weird movement like DP and Makaqu, I did not manage to get into the teleporter
-Darkplaces does weird things, but if you manage to hit the teleporter, it works. (Tried an one year old build through wine with the same result.)

Wine:
-aguirRe's engine works
-Fitzquake freezes
-Telejano freezes (mini.exe)
-DirectQ, wow, fuck, never run DirectQ in a Wine window. Froze too when I found the teleporter.
-Joequake freezes
-Makaqu does the same crazy shit like Darkplaces and freezes
-Q2K4 freezes
-TQ148 freezes

Now what on earth is going on there and why are so many engines affected? Seems like there is something to fix in engine land.

edit: sdlquake tells me Error: progs.dat has wrong version number (0 should be 6)

Actually if the majority of engines lock up, I'm inclined to lean towards "something to fix in QC land".

There's a pointer being stomped somewhere in this mod.

I'd like to decompile the QC and see what it's doing with it's trigger_teleport and info_teleport_destination entities; from looking at the entity data stored in the BSP file it seems to be doing something sexy there (switching target fields on the fly by the looks of it).

It's probably worth noting that the engines it works on have had overhauls to their progs interpreters.

___________________


OK, fixed it.

I just ripped the SV_TouchLinks function from tyrquake (respect and all, but the guy's preferred indent and brace style makes me want to reach for something solid to hold on to) and all is resolved.

The relevant code is:

  Code:

      // the PR_ExecuteProgram above can alter the linked edicts
      if (next != l->next && l->next)
      {
         Con_DPrintf ("Warning: fixed up link in SV_TouchLinks\n");
         next = l->next;
      }

Pop it after the call to PR_ExecuteProgram.

Confirms the theory that something sexy is going on in the QC.

Why on earth would you run DP through wine?

Why on earth would you run DP through wine?

Because you can.

If you thought before ranting, you could have considered the possibility that I put it into the wrong listing... Of course I ran the native one (only the old one through Wine).

So it seems like this is just another chapter in the book "Quake engines and their non-existing error handling". Damn, heh.

thanks spirit for finding it, mh for posting the fix...

So it seems like this is just another chapter in the book "Quake engines and their non-existing error handling". Damn, heh.

Actually if it doesn't work in ID Quake it's non-standard behaviour. But we could go round in circles on this one...

might be worth noting, i couldn't reproduce this bug with maxplayers = 4, only with maxplayers = 1

Might be worth noting that remove() inside touch functions is a bad plan, hence the whole reason for id adding SUB_Remove.

Unfortunately this also applies to setorigin, but that at least doesn't lock up the engine.

Also worth noting is e2m2. Shoot one button, then rocketjump/bunnyhop across the bridge-to-be... KABOOM! You hit a trigger_once that killtargets another nearby trigger, throwing the engine into an infinite loop, or was it a crash?...
This has been documented before. Presumably on quakesrc though.

The 'proper' solution is to build a list of which ents need triggering and to then trigger them, rather than triggering them as you find them.
Or to just not remove() in touch functions.

mwhaha exxxxcellent

It's been quite some time since I've worked with the pro-x source. If it's a problem though I'm happy to go diving into the code again to check it out.

I have a progs.dat that is a lot more updated though (lots of bugfixes, but I don't recall anything teleporter related... but I could be wrong). I really should release an update... msg me in irc Spirit

Ah, I was wondering when you'd show up.

OK, laydeez and gennulmen, the court is convened. Charge: QC abuse most heinous.

How does the defendant plea?

Hi guys. As you can see, I'm new here. I've got my own little (unreleased) engine project, so Spirit pointed me to this discussion.

Anyway, I've got a concern about the solution mh posted: The updated code now handles the case where the next link is removed during .touch(). The original id code seems to be designed to handle the case where the current link is removed, but I'm worried this situation may no longer work.

Here's what I mean: say the current link is removed from this entity's trigger list, and then it's relinked. The .next and .prev fields will be non-null, but .next will be different than the stored "next". So we'll end up missing the rest of this ent's trigger list and traversing a different trigger list, probably in an infinite loop.

Or am I missing something?

FTE and DP build a (non-linked) list of entities that should touch, and in a separate step touches them.
This makes list management atomic as far as the gamecode can tell, and fully prevents associated crashes/freezes/runaway loops.
Nothing may edit the list while the list is being traversed.
Having said that, I don't know of any maps/mods that still break with the fix mentioned by others in this topic.

Native:
-tyrquake WORKS

Hear, hear

FTE and DP build a (non-linked) list of entities that should touch, and in a separate step touches them.
This makes list management atomic as far as the gamecode can tell, and fully prevents associated crashes/freezes/runaway loops.
Nothing may edit the list while the list is being traversed.
Having said that, I don't know of any maps/mods that still break with the fix mentioned by others in this topic.

I just got my first report that this fix actually breaks otherwise functional maps. In this case "White Room" by willem breaks in fitzquake 0.85, which implements the fix from this thread: http://www.celephais.net/board/view_thr ... 7&start=93

So I guess the more robust method of FTE and DP is the way to go.