negke:
1) just Quoth
2) spawnflags vary between cases, which is part of what makes it so weird.
3) It happens in FitzQuake every time just like the other engines

Preach:
I'd love to send it but I'd rather not post it. Got an email address?

FWIW the problem seems to appear pretty regularly when the ogres are hit with quad damage and to almost disappear when I take out the quad. I really wanted that quad secret because it's an awesome area for one, but I might just replace it with something more tepid like a cross. :P 

n/t 

I forgot we even HAD profiles. 

Wondering why the bug almost always appeared when Quad damage was enabled and very rarely otherwise, I experimented a little further and figured something out. I was using the "remove head gibs" Quoth optimization and ogres became immortal instead of gibbing. Severed heads are back in and now they die like decent monsters. Maybe it's just a bug in Quoth itself (related to the ogre models now being merged?) that no one noticed because no one bothered to have ogres, quad, and optimized gibbing in the same part of one map before :P

Preach, feel free to disregard the email, or laugh at how much my map sucks. your call. 

That makes it very easy to investigate, and even without running your map I can see how to fix that. I think the ogre must have been the first monster tested with the flag, and it has a single vestigal line of code which no other monster has. So I've fixed this bug (and a related one where eliminators would still precache their head mode even with this flag set). It's now in a potential 2.2 patch for BUG FIXES ONLY.

I say potential because it might be worth holding on until a more severe bug comes to light, before going to the trouble of getting everyone to get a patch. The 2.1 patch fixed an unavoidable crashing bug in an existing map, and this is the only change in 2.2. If anyone has any good crashing bugs in Quoth 2.1 now's the time to share! Fern: let me know if it's impossible to get the map to run on a stock engine without that optimisation, as that would probably sway me. 

And I really had no good reason to enable the optimization in the first place, so overall using this experience as an excuse for a patch seems unnecessary. Thanks for your attention though. It's not every day you find a reproducible bug in software everyone's been using with satisfaction for years. :) 

if you're going to do a patch, it might be nice to fix the bug with multispawners and auto-awake monsters. 

Which way round was it broken? It was failing to wake monster with the flag set, right? Not waking everyone without the flag 

yeah, basically nothing happens when you turned on the setting. They would spawn in one at a time, but because they weren't awake, only the first would spawn and the spawner would wait until the space was free before spawning again. 

FitzQ .85 - is it possible to slow the frame rate down by some command? I have an effect that doesn't quite look right and I want to slow it down so that I can see what's happening. (Intel i7 is just too damn quick!) 

This is the multicore timing bug. The only way to fix it is to use a different engine afaik. Quakespasm is a good alternative. :) 

...me trembles with fear...

Wish me luck, and if I don't return I leave my goldfish to Mildred, and my conkers to Jeremy. 

Mike, if you just want to turn on slow motion for testing purposes, the command you are looking for is:

host_framerate.

I find that setting it to 0.002 gets me a slowmo which I can study animations by, but my understanding is that the appropriate setting varies depending on the computer (so you couldn't use it to make good a bullet-time powerup) 

My bacon is saved, and I get to keep my conkers after all. Thanks Preach. 

Oh sorry, I misunderstood when you mentioned the i7. :)
You can also try host_timescale which is in fitzquake engines only. 0.5 is half speed, 1.0 (or the default 0) is full speed. 

It's staggeringly pretty in slow-mo.

(but it does show nails appearing from the side of the gun and not from the end of the barrel) 

yeah i created host_timescale because host_framerate is sort of confusing to use. 

Put succinctly, my map currently runs awesomely, until I light it. After running light, the monsters start spawning above the ground, getting stuck in the air, and walking through walls.

Any idea how the HELL this is possible? 

... do you have flying shell boxes that attack you with Scrag green fireballs ?
If it is the case, then it is because you loaded a saved file generated from the previous version of your map... I experimented this kind of behavior and it indeed a kind of "surprising" :) 

what? 

.. sorry Von, I've been screwed by the green color of Fern's name. Actually post #12166 was for Fern :P 

I had the same on responding you for jtl.
Someone must have made that teleporter, falling out in small cubes. 

Is it possible to create an entity in Quoth that would sit and quietly emit a rocket/grenade trail? 

Search the teaching old progs dat thread. What you need is to assign a mdl - either the rocket or grenade (or create a new one which is empty but still has the rocket or grenade trail flags on) to an entity.

I think the method is to apply such a model directly to an info_notnull.

The difference between the two trail types is that the rocket has the glow decal. 

One caveat to that: non-moving particle emitting entities do not emit particles. :(

What you could do is make a one vertex model with an emitting flag set, attach that as a model on a func_rotate_train and have it move between two path_rotates 1 unit apart at a very slow speed.