The mysterious engine killing teleporter
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)
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)
Last edited by Spirit on Wed Feb 11, 2009 10:18 am, edited 1 time in total.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
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:
Pop it after the call to PR_ExecuteProgram.
Confirms the theory that something sexy is going on in the QC.
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: Select all
// 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;
}
Confirms the theory that something sexy is going on in the QC.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
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.
So it seems like this is just another chapter in the book "Quake engines and their non-existing error handling". Damn, heh.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Actually if it doesn't work in ID Quake it's non-standard behaviour. But we could go round in circles on this one...Spirit wrote:So it seems like this is just another chapter in the book "Quake engines and their non-existing error handling". Damn, heh.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
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.
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
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
Benjamin Darling
http://www.bendarling.net/
Reflex - In development competitive arena fps combining modern tech with the speed, precision and freedom of 90's shooters.
http://www.reflexfps.net/
http://www.bendarling.net/
Reflex - In development competitive arena fps combining modern tech with the speed, precision and freedom of 90's shooters.
http://www.reflexfps.net/
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?
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.
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=93Spike wrote: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.
So I guess the more robust method of FTE and DP is the way to go.