This one by any chance?

http://forums.inside3d.com/viewtopic.php?t=1431&highlight=engine+killing+teleporter 

I saw that message, too, a couple of times and wondered what it means. For apparently, it's not THE sv_touchlinks issue, the one that crashes unprepared engines (like in E2M2). Check the pent secret in my coag map for reference. 

it's a fix for what mh linked to.

However this fix ended up being a problem because it crashes White Room, so i need to figure out how to fix it correctly for my next release. 

My implementation of the more robust fix is here: http://forums.inside3d.com/viewtopic.php?p=23987#23987

Works with both proxmap2 and whiteroom. 

Seems like the issue doesn't always necessarily lead to a crash/freeze then. 

Depends on the QC. Apparently calling remove while touching links is what can cause the lock-up, but no doubt it's possible to construct QC that does other lesser but still nasty things. 

It seems like quite a dangerous restriction on the qc, because a lot of the time you're writing code for which you have no idea if it's going to be run in a touch function or something safe like a think function instead. For example, a death function might get called from a collision or a hitscan attack originating from playerpostthink.

Still, it's nice to think that the original QC authors have made sure to take this instruction to heart. They would never call remove directly within a function used as a touch function, Especially not one as common and clearly labelled as spike_touch

Oh, wait...

In conclusion, I'd guess that removing one of the entities involved in the collision is generally safe, and it's when you start removing 3rd party entities that the problems arise. Can anyone who understands the e2m2 crash better than me confirm or deny that? And would making sure killtarget uses SUB_Remove on a short-delay think fix that case? 

I'm not certain that I'd see it as a restriction on QC, but more a case of QC authors either not knowing their tool or not testing well enough. It's possible to write software that crashes in any language, and QC should be no exception. If writing in C for example I'd conform to the rules of the language, and not expect something I write to always work just because I wanted it to.

If it breaks in ID Quake then by definition it's broken is my opinion, and this one breaks in ID Quake.

I think the short-delay think sounds like a good idea, but my own QC knowledge is quite limited. 

What I'm saying is that it's virtually impossible to write QC which guarantees it doesn't remove things during touches - calling that a case of QC authors either not knowing their tool or not testing well enough. is disingenuous. A mapper could potentially apply any function in the progs as a touch function to an entity, including SUB_Remove.

Even if you argue that this one is the mapper's fault, that's just the least subtle problem. When I cited the example of a death function which could be called from both touch and non-touch functions, the important thing to note is that the two cases are indistinguishable from the QC. There's no flag you can read, and you can't create one yourself because any function could be made into a touch somewhere.

If you were willing to compromise some responsiveness in removing entities and guessed at the most likely circumstances, you could probably reduce the amount of "remove during touch" by 90% compared to the original progs. But totally preventing it on the qc side isn't just a case of a little bit of care - it's so hard I don't even know if it's possible. 

Here's what's used in quakeworld clients like Zquake, that I've used in Qrack with 64bit windows 7 without any problems.

/*
================
Sys_InitDoubleTime
================
*/
void Sys_InitDoubleTime (void)
{
timeBeginPeriod (1);
}

/*
================
Sys_DoubleTime
================
*/
double Sys_DoubleTime (void)
{
static DWORD starttime;
static qboolean first = true;
DWORD now;

now = timeGetTime();

if (first)
{
first = false;
starttime = now;
return 0.0;
}

if (now < starttime) // Wrapped?
return (now / 1000.0) + (LONG_MAX - starttime / 1000.0);

if (now - starttime == 0)
return 0.0;

return (now - starttime) / 1000.0;
}

Hope this doesnt reitterate what someone else said as I didnt read the whole thread :P 

i think it's great to raise awareness of this issue as more of us pick up dual (or more) core processors and 64 bit operating systems. 

regarding this feature from the readme:

- god, noclip, notarget, and fly can now be explicitly set. example: "god 0" will disable god mode

how possible would it be to make cheats, specifically notarget, be enableable from the command line? ie, by adding +notarget 1 to the end of your batch file or whatever so the map loads with it turned on... unless i am missing another way to do this? 

have you tried it? It sounds like it would work. 

yes, and no.. 

try the different possible orders of command:

+map e1m1 +notarget
+notarget +map e1m1

I'm not sure which order things are executed from the command line, it might be reverse order. And since i think "notarget" etc. gets reset at map load, that might be the reason it doesn't always work. 

And since i think "notarget" etc. gets reset at map load, that might be the reason it doesn't always work.

yeah that's what i figured. neither combination works (whether it has a '1' after it or not)

say i wanted to make it function like 'skill' - ie, carryable across maps, would that be qc-side or engine-side? 

+notarget +map e1m1 works ok on WinQuake. Best way however to make something carry across maps is to use the changelevel command instead of map. Unfortunately changelevel needs an active server to carry over state from so it won't work on the command-line. 

I need some help. When I try to run fitzquake it says it could not load gfx.wad I don't know what that is or what I should do does anyone know? 

are you trying to run fitzquake using a shortcut, or using a batch file? Or are you simply double-clicking on it directly? 

Looks like typing r_stereo 1 in the console in FitzQuake 0.85 causes a crash or some sort of infinite loop. 

hmm, i thought that was fixed already... Or maybe the old bug was r_lightmap 1 + r_stereo 1.

Anyway, i'll look at it when i get a chance (crunching at work right now, so it might be a while.) 

Sorry if this as been answered already; I don't want to look through 400 posts.

How exactly are you supposed to get the music to work? I saw a link posted somewhere of fitzquake with MP3 support, but sadly the link is dead. 

I would also like to add that I do have a physical copy of Quake I, purchased about 14 years ago (god I feel old). I read on the Steam forums that the music should play if you have the CD in the CD drive while you play, though I'm not sure if that applies to fitzquake. I also tried mounting it to the E drive with Daemon Tools. 

It should play from the CD if you put it into the drive with the "highest" letter. So if you have 2 ROM drives F and G, you would put it into F. I am not sure if they need that ancient cd audio cable to the motherboard/soundcard or if those even exist anymore. 

Whoops, my Daemon Tools virtual drive was D and Quake I was E. Going to disable the virtual drive and see if that fixes it. Thanks for the fast reply.