see if you can get in contact with Lunaran, he's written all sorts of .map format converters in his day, he may have a python script laying around that does it 

tbh though, now that i think about it, by the time I've nerfed all the detail, filled in the bits that used to be covered by patches/models, and retextured everything, I may as well have just built the blimmin thing from scratch anyway... 

Is this 'fixable'?

I have it in an earlier FMB map where I use a trigger_once to killtarget a trigger_push. I know that FQ intercepts the bug and there is no crash, but not everyone uses FQ. 

I mean is it fixable via the editor in some way - I need both triggers, even though the trigger_once is only there to accommodate speedrunning shortcut merchants; 'normal' players won't experience any problem anyway. 

The engine problem is removing an entity during a touch function - this is illegal but in fact quite hard to always prevent. We can make a special bit of code for this case though. Instead of directly removing the entity in the killtarget code:

1. Set the targetted trigger .touch function to SUB_Null so that it can't be touched any more. This renders it effectively inert without breaking the link list.
2. Set .think = SUB_Remove and .nextthink = 0.1 to tidy it up later. This way we'll be safely in a think function when the removal occurs.

The trick is to detect when we can remove directly and when we need this trick. The safest thing is just to special case it - make a new special kind of entity which performs this "slower, safer" removal on killtargets, and just use it here when needed. 

Fitz displaying a sv_touchlinks warning every now and then doesn't automatically mean the game will crash with other engines.

Preach: If SUB_Null is supposed to disable the touch function, why does it work so flawlessly in all my hack triggers? What is it I fail to understand about the functions here? 

SUB_Null is just an empty function. setting .touch to SUB_Null just makes the touch function do nothing at all (as opposed to not having a touch function, if you want to make the distinction). 

I phrased that badly, but in my defense when I wrote that half of the sentence I was going to set .solid to SOLID_NOT. I then worried that this might stomp on some other part of the engine's collision code by leaving the entity in the wrong linked-list, so I decided that replacing the touch function would be safer.

Word of caution: This method might fail when dealing with a shootable trigger. In theory you could shoot it in that window between the touch being removed and the think executing. This might then stomp over the think to be executed with the trigger_reset function instead. In this case you'd also need to reset .damagetype and/or .th_die when you prep for removal.

Don't even get started on how hard it would be to remove a monster like this - things like the monster getting woken up in the split second before it gets removed would be enough to spoil things. This would of course be a very obscure bug because of the small window of manifestation, but it would be hellish to diagnose. 

I followed Scampie's tut for pipes but stranded at this region.
I'm using GtkRadiant 1.5.0 and as long as I try to submerge the horizontal phase everything turns right with ctrl-U.
If I try the turned region the merge doesn't work.

http://members.home.nl/gimli/curves.jpg

What do I do wrong. or is it my window32 and no64? 

If it's touch that causes the problem, why not just use a trigger_relay to kill the trigger_push?

I've done it that way before without problems, not sure if I had a delay in it or not though. 

Yes, a trigger_relay with 0.5 delay worked. Thanks all. 

I updated the qbsp and light sections of the quaddicted map compilers page. http://www.quaddicted.com/tools/map_compilers 

Missed some vertices on grid.
Trisouping merges well.
Me bloated sheap. 

So, we clear the E2M2 bug outlined above - great! Now we are just play-testing through the map. I've got architecture (nice), I've got trim (not painted on), I've got monsters (loads), I've got lights (dark and scary), I've got music (totally immersive). I have a simple teleport; I go through and get the SV_TOUCHLINKS error. I have another teleport in another map, set up in the same way (target and targetname, no flags) and do not get the error. Same progs.dat.

I do a test map: a box room, the player, a trigger_teleport, a info_teleport_destination, one monster; I get the error. I use the standard progs.dat with the test map; I get the error.

I actually thought, "Easter weekend, cold outside, let's stay indoors and finish the map". Now I'm thinking I'll just juggle chain-saws in the garden whilst hopping naked on broken glass, it's bound to be easier than finishing the map.

What's on TV, mum? 

trigger_teleport will fire it's targets when it teleports something.
is there something else that shares the targetname of your teleport_destination? 

I did check the main map (because it does break some limits) but I cannot see anything untoward.

I then created the simplest map to test the issue:-


//BSPGROUPS0001
//BSPGROUPINFO"None" "255 255 255" "1"
//BSPFAVORITES0010

//BSPCAMERAS0005
//"582.0 -665.3 1088.0 0 0 238"
//"4.8 -138.3 128.0 0 0 180"
//"0.0 -128.0 128.0 0 0 180"
//"0.0 -128.0 128.0 0 0 180"
//"0.0 -128.0 128.0 0 0 180"
//BSPMAPTYPE0000
{
"classname" "worldspawn"
"wad" "c:\games\bsp96b\quake\wads\onion.wad"
{
//"0000" "0"
( -768 -768 384 ) ( 768 768 384 ) ( 768 -768 384 ) ROCK18 0 0 0 1.0 1.0
( -768 -768 368 ) ( 768 -768 368 ) ( 768 768 368 ) ROCK18 0 0 0 1.0 1.0
( -768 768 384 ) ( -768 -768 384 ) ( -768 -768 368 ) ROCK18 0 0 0 1.0 1.0
( -768 -768 384 ) ( 768 -768 384 ) ( 768 -768 368 ) ROCK18 0 0 0 1.0 1.0
( 768 -768 384 ) ( 768 768 384 ) ( 768 768 368 ) ROCK18 0 0 0 1.0 1.0
( 896 -584 384 ) ( -640 -584 384 ) ( -640 -584 368 ) ROCK18 0 0 0 1.0 1.0
}
{
//"0000" "0"
( 768 -768 1280 ) ( -768 768 1280 ) ( -768 -768 1280 ) ROCK18 0 0 0 1.0 1.0
( 768 -768 1296 ) ( -768 -768 1296 ) ( -768 768 1296 ) ROCK18 0 0 0 1.0 1.0
( 768 768 1280 ) ( 768 -768 1280 ) ( 768 -768 1296 ) ROCK18 0 0 0 1.0 1.0
( 768 -768 1280 ) ( -768 -768 1280 ) ( -768 -768 1296 ) ROCK18 0 0 0 1.0 1.0
( -768 -768 1280 ) ( -768 768 1280 ) ( -768 768 1296 ) ROCK18 0 0 0 1.0 1.0
( -768 768 1280 ) ( 768 768 1280 ) ( 768 768 1296 ) ROCK18 0 0 0 1.0 1.0
}
{
//"0000" "0"
( 768 -768 0 ) ( -768 -768 1280 ) ( -768 -768 0 ) ROCK18 0 0 0 1.0 1.0
( 768 -784 0 ) ( -768 -784 0 ) ( -768 -784 1280 ) ROCK18 0 0 0 1.0 1.0
( 768 -768 1280 ) ( 768 -768 0 ) ( 768 -784 0 ) ROCK18 0 0 0 1.0 1.0
( 768 -768 0 ) ( -768 -768 0 ) ( -768 -784 0 ) ROCK18 0 0 0 1.0 1.0
( -768 -768 0 ) ( -768 -768 1280 ) ( -768 -784 1280 ) ROCK18 0 0 0 1.0 1.0
( -768 -768 1280 ) ( 768 -768 1280 ) ( 768 -784 1280 ) ROCK18 0 0 0 1.0 1.0
}
{
//"0000" "0"
( 768 768 0 ) ( 768 -768 1280 ) ( 768 -768 0 ) ROCK18 0 0 0 1.0 1.0
( 784 768 0 ) ( 784 -768 0 ) ( 784 -768 1280 ) ROCK18 0 0 0 1.0 1.0
( 768 768 1280 ) ( 768 768 0 ) ( 784 768 0 ) ROCK18 0 0 0 1.0 1.0
( 768 768 0 ) ( 768 -768 0 ) ( 784 -768 0 ) ROCK18 0 0 0 1.0 1.0
( 768 -768 0 ) ( 768 -768 1280 ) ( 784 -768 1280 ) ROCK18 0 0 0 1.0 1.0
( 768 -768 1280 ) ( 768 768 1280 ) ( 784 768 1280 ) ROCK18 0 0 0 1.0 1.0
}
{
//"0000" "0"
( -768 768 0 ) ( 768 768 1280 ) ( 768 768 0 ) ROCK18 0 0 0 1.0 1.0
( -768 784 0 ) ( 768 784 0 ) ( 768 784 1280 ) ROCK18 0 0 0 1.0 1.0
( -768 768 1280 ) ( -768 768 0 ) ( -768 784 0 ) ROCK18 0 0 0 1.0 1.0
( -768 768 0 ) ( 768 768 0 ) ( 768 784 0 ) ROCK18 0 0 0 1.0 1.0
( 768 768 0 ) ( 768 768 1280 ) ( 768 784 1280 ) ROCK18 0 0 0 1.0 1.0
( 768 768 1280 ) ( -768 768 1280 ) ( -768 784 1280 ) ROCK18 0 0 0 1.0 1.0
}
{
//"0000" "0"
( -768 -768 0 ) ( -768 768 1280 ) ( -768 768 0 ) ROCK18 0 0 0 1.0 1.0
( -784 -768 0 ) ( -784 768 0 ) ( -784 768 1280 ) ROCK18 0 0 0 1.0 1.0
( -768 -768 1280 ) ( -768 -768 0 ) ( -784 -768 0 ) ROCK18 0 0 0 1.0 1.0
( -768 -768 0 ) ( -768 768 0 ) ( -784 768 0 ) ROCK18 0 0 0 1.0 1.0
( -768 768 0 ) ( -768 768 1280 ) ( -784 768 1280 ) ROCK18 0 0 0 1.0 1.0
( -768 768 1280 ) ( -768 -768 1280 ) ( -784 -768 1280 ) ROCK18 0 0 0 1.0 1.0
}
{
//"0000" "0"
( -1144 32 104 ) ( -1144 0 104 ) ( -1144 0 88 ) ROCK18 0 0 0 1.0 1.0
( -1336 800 72 ) ( -1352 800 72 ) ( -1352 800 56 ) ROCK18 0 0 0 1.0 1.0
( 1040 -152 104 ) ( 1040 -120 104 ) ( 1040 -120 88 ) ROCK18 0 0 0 1.0 1.0
( -1144 -832 88 ) ( -1128 -832 88 ) ( -1128 -832 72 ) ROCK18 0 0 0 1.0 1.0
( -1144 0 104 ) ( -1144 32 104 ) ( -1128 32 104 ) ROCK18 0 0 0 1.0 1.0
( -1088 32 -160 ) ( -1104 32 -160 ) ( -1104 0 -160 ) ROCK18 0 0 0 1.0 1.0
}
}
{
//"0000"
"origin" "496 160 136"
"classname" "monster_army"
}
{
//"0000"
"classname" "info_player_start"
"origin" "-736 -720 408"
}
{
"classname" "trigger_teleport"
"target" "test"
{
//"0000" "0"
( -512 -624 -576 ) ( -512 -752 -576 ) ( -512 -752 -608 ) NONE 0 0 0 1.0 1.0
( -384 -592 -576 ) ( -512 -592 -576 ) ( -512 -592 -608 ) NONE 0 0 0 1.0 1.0
( -384 -752 -576 ) ( -384 -624 -576 ) ( -384 -624 -608 ) NONE 0 0 0 1.0 1.0
( -512 -752 -576 ) ( -384 -752 -576 ) ( -384 -752 -608 ) NONE 0 0 0 1.0 1.0
( -576 -752 496 ) ( -576 -624 496 ) ( -448 -624 496 ) NONE 0 0 0 1.0 1.0
( -400 -624 384 ) ( -528 -624 384 ) ( -528 -752 384 ) NONE 0 0 0 1.0 1.0
}
}
{
//"0000"
"classname" "info_teleport_destination"
"origin" "-72 -680 408"
"targetname" "test"
}



and it still shows the error, although FQ85 reports it but does not crash. 

if that map you posted is causing the error, then at this point, all i can ask is: are you SURE you also tested with the stock progs.dat? 

"classname" "info_teleport_destination&qu...

is "classname" "info_teleport_destination" in the map file.

Ah, 'preview' shows me that somebody doesn't like too many quotes in a post.

The map file is correct 

Did you test it in a non-Fitz engine? Does it crash there? 

Is dated 25/11/1996.

But I am assuming that if I run FQ directly from the .exe file, it will link to the ID1 folder and will not somehow use another -game setting? 

I moved everything out of the Quake folder and just left the ID1 folder in there.

Anything in the config file that might affect things?

No, hang on; I have a map using my progs.dat that does not display the problem. FMB_BDG has a teleporter to get you to a secret area and there are no issues at all. The map that displays the error is the next map in this series. 

I only have FQ and have never used anything else. I will down load something else and try it - any suggestions? 

My point is, even if Fitzquake displays the warning, it doesn't prove there's a serious issue. It may just as well work fine in other engines. I also get the sv_touchlinks (engine) warning in some of my maps, and they still work flawlessly. 

It's true that the map does not crash (because FQ mugtraps the error) and the teleporter works. So it can be released like that. I just don't like the message popping up on screen: it's wrong.

I also find it annoying that sometimes it errors and some times it does not.

Now here's a funny thing. In one instance, a teleporter is actually being used as a short-cut. If you use it (by finding a secret) you teleport to immediately behind a monster (shhh, he does not know you're coming), and you get the error message. However, if you kill that monster first (he is nothing to do with the secret, and he is not targeted, he's just an ogre plain and simple) and then go and do the secret teleport, there is no error.

I know my maps are not exactly state of the art, but I do try to get them looking good and playing good. I guess this is compromise time, but as it is my last map, I would have preferred if it did not stutter over such a thing. 

I think I can eliminate the message! If you avoid spawning the tdeath trigger during the teleport touch function, instead just spawning a helper entity with a think function that will spawn the tdeath as soon as possible. The think I wrote was:

void() spawn_tdeath_wrapper =
{
spawn_tdeath(self.origin, self.enemy);
remove(self);
};

and the replacement for the spawn_tdeath call in teleport_touch goes like

tdeath = spawn();
tdeath.origin = t.origin;
tdeath.enemy = other;
tdeath.nextthink = time;
tdeath.think = spawn_tdeath_wrapper;

Trying your test map in glquake doesn't cause a crash though, even before the fix. I think I can see why the error message occurs intermittently and is essentially benign. When a touch even is fired, the engine is in the middle of an internal physics function which holds some state information about the world. That state is an except of a linked list holding the physical entities in the world.

When the tdeath gets added, this is a physical entity which need to be included on the list. If we are very unfortunate then the little bit of the list that the function already has is now out of date. In less careful engines the function does not even notice that it's bit of information is out of date. Does this matter?

Well, that depends. If you care that the function might be skipping our new entity then there is a bug, but we've already acknowledged that we don't expect reliable collisions this frame (that's why force_retouch is set to 2).

I think there's also a more dangerous problem which can arise in this code if the mismatch is because the QC removed an entity, because then the engine is using out of date information to access a dead entity. Dead entities get their physical properties removed so expectations might get violated.

Since we're adding not removing, that class of error can't happen, so I'd expect we are safe. If the error message is irritating the QC workaround above exists, although it might add an extra frame worth of delay to telefrags so it's not entirely without tradeoff.