I've been doing some more investigation of this one and have traced the cause - it's hinted at by the header comment of SV_Physics_Step:

"Monsters freefall when they don't have a ground entity, otherwise all movement is done with discrete steps."

Some tests confirm it (basically just not sending an entity that meets the freefall conditions in SV_Physics_Step) - a monster on a lift isn't MOVETYPE_STEPping, it's in freefall. 

sorry to interrupt but: groundentity is exposed in qc, does it do anything there? ie: will it report a lift that the player/monster is standing on? 

Whatever you do, just don't break the suspended monsters trick like DP does. 

don't worry, this would be a cosmetic change only (purely client-side.)

BTW, darkplaces has a lot of cvars that control features that break compatibility, you might be able to un-break that trick too if you know the right cvar (i think they are all named sv_gameplay_fix_*) 

why does fitzquake (and quakespasm) put the qconsole.log file in /quake/qconsole.log instead of /quake/mod/qconsole.log?

is this the original functionality? just seems a little odd (and had me searching around for it!) 

Is there anyway to force fitz to start in a windows mode via the command line? I tried with config files and it just keeps going full screen and then back to windowed mode. 

-width 1680 -height 1050 -bpp 32 -window 

Because it is the engine's log. Besides, the mod directory can be changed when the game is still alive, so there is no point in putting it under /quake/gamedir/ 

I tried the -window command line and it worked perfectly but the +mlook no longer works, even if I do a vid_restart console command.

For some reasons if I start the engine normally and tell (via config file) the engine to go windowed the +mlook still works. (it also grabs the mouse pointer permanently, I have to close the engine down to use the mouse with other window apps. 

sock: try pulling down the console before tabbing? that works in quakespasm anyway. i agree though, it would be nice if mouse control was release as soon as focus was lost. 

Ok, maybe I'm an idiot (well, ok, maybe might be understating it a bit) but how do I get FQ 0.85 to play the ripped tracks (I've tried both formats)?

I've tried placing the files (named track02.xxx through track11.xxx where xxx is the two different format extensions) in:

QUAKE\id1\sound\cdtracks
QUAKE\id1\sound\music
QUAKE\id1\cdtracks
QUAKE\id1\music
QUAKE\cdtracks
QUAKE\music

I know that the music works (ogg plays fine in DarkPlaces and the mp3's work in a few different media players) and when I put in the game CD it plays just fine. I'd just rather not risk damaging the original CD if I don't have to.

Is this not supported in this engine or am I missing something obvious? 

i know baker made a version where he added it in himself, so i don't think the stock fq085 does. 

Yeah, I saw that but the link to the binary is dead and I don't really want to mess with compiling a new exe. I'd probably just screw it up.

Oh well, maybe in the next version... 

quakespasm does play mp3/oggs (in /id1/music) and it's very similar to fq.

name them track02-11 and they will play normally. 

incidentally, you can make your own custom music by making music files track13 and up, then just using the sounds field in worldspawn or the builtin SVC for cd playing in the qc. 

Spiffy! Thank you. 

many engines support arbitrary filenames so for custom tracks please avoid numbers but use distinct unique filenames Instead. 

numbers are better because you can use the builtin qc function to start music as well as the worldspawn key, which, if the engine integrates the mp3 playing PROPERLY should redirect to the mp3 reliably as opposed to stuffcmd'ing console commands that may vary between engines. 

engines should support any filenames for both of these options. the "cd play" command should be fully transparent/oblivious. 

"cd play 5" should play the 5th file in the list - easy as that. No need for requiring any track naming convention at all. 

5th file in the list.... the list being all music files located in the id1 music dir + mod's music dir? So if someone adds "aaa.mp3" to their id1 dir, then every other level you own will now play a different track? 

cd play 5 must play the cd track 5 or the equivalent external files which is track005 or track05 or something like that. 

"cd play 5" playing the 5th file in the list is unreliable and also is against the purpose of the cd command which is "playing track 5 of the cdrom in the drive" and nothing else.

The reliable solution is using a unique filename for every different music which what hexen2 did 15 years ago: see svc_midi_name of hexen2. In uHexen2, I further extended its use for music files other than midi such as ogg, mp3, wav. (Of course the drawback of the server message is that it dictates a new protocol.) 

How somebody adding an extra file to the directory is any way different to somebody popping in a different CD. Other problems arise. What if somebody puts both track01.mp3 and track01.ogg into the directory for an engine that supports both mp3 and ogg formats? What if somebody deletes one of the files? What if the author of another popular engine decides to use a different naming convention because they feel that it's somehow superior? There's only so far you can go to protect against this kind of thing before it becomes counter-productive. Ultimately I favour the approach that is most pragmatic and that offers the least surprise and least unexpected behaviour to the player - not the engine coder, not the mapper/modder - the player. If the player puts an extra music file in there, what do you think the player's expected behaviour is going to be? So code to that. 

since everyone has their own protocols anyway, i'd rather see a new builtin svc.