I'll try to address some of the issues you've mentioned.

than: It's possible to have more than one protocol in the engine; both DP and mine have several. The only big catch I know is something I discovered rather recently; progs can inject any arbitrary bytes right into the protocol stream via the server without any supervision (design: argh!).

This can cause major damage as the progs isn't aware of any protocol negotiations between the client and server, but fortunately most progs only use a pretty small subset of the services and they typically don't cause any problems.

In my engines, protocol handling is fixed from the server side, but the clients adapt to the current server. This means backwards compatibility, i.e. clients can connect to (or playback demos from) older servers. In the latest versions, this also means handling of the slightly extended Nehahra protocol (actually a "bastard" variant of std protocol 15, pretty common in custom engines), either by actually handling the extra info/services or just silently parse them and continue with the next.

DP has a user selectable protocol set controlled by a cvar and it has (like mine) several extended native protocols as well as the possibility to generate std Q1 protocol 15 (although it can actually produce too big messages in this mode - you can use my ConvDem to fix demos with this problem). DP might have more related features that I haven't delved into yet.

However, I can't see how the server can switch protocols midway, as the client will immediately abort if you're not imposing a new, incompatible soft protocol negotiation (which most likely will rule out any std client and which then basically nullifies the whole idea).

A console command for executing triggers (basically a use command I guess) has been suggested before by Kinn, I didn't do it then because I was unsure of implications. I haven't done anything yet about it. IIRC, Kinn solved it himself in the progs (which is maybe a better way to do it).

Engine sparklies (I assume tjunction effects) should either be already fixed by a better default setting for cvar gl_keeptjunctions or not easily fixable because the bsp is built without padded tjunctions (e.g. with TreeQBSP 1.63). Waterwarp can be disabled just like in WinQuake; r_waterwarp 0. Slow sky rendering is also fixed by a better default value of gl_subdivide_size (more sky distortion as usual though, but it doesn't bother me).

paneon: I'm unaware of the flickering console bug you mention, do you actually mean the flickering status bar when gl_clear is enabled? Have you tried different drivers/resolutions/colour depths, window/fullscreen operation or adding "-no8bit", "-nomtex" or other similar remedies? It sounds like a hardware/driver issue.

Mindcrime: Yes, you can watch the whole Nehahra movie (and all demos of course) in my latest GL/WinQuake. The only drawbacks are more or less limited visual features supported and that you'll have to restart the engine somewhere near the end of the four hour movie (i.e. you can't watch the whole movie in one engine session). The movie looks pretty good in WinQuake; you'll just have to enable your brain's "software filter" ...

As for Nehahra (or general) transparencies, JoeQuake also supports that AFAIK.

All my engines are of course also already prepared for the upcoming Nehahra Revamp material and if nothing major comes up along the way, I'll try to keep it that way. 

aguirRe client is like having a life colet is water... always in my Quake directory and is tools for mapping is a need :) they rockzzzz keep good work aguirRe ;) 

nice post :) 

I get this in fitzquake whenever some other program pops up a dialogue that doesn't steal focus fully (and minimise fitz). For example, when I change the volume on my laptop, a little volume level meter appears on the screen. When it dissapears, the statusbar flashes. It stops when I toggle the console. It might also stop when the screen is affected by some kind of flash or effect, such as picking up an item or going underwater, though I'm not sure.

Anyway. this problem is not severe for me, and I haven't noticed it in any other engines. I didn't notice it in Aguire's engine whilst I was playing Masque, so presumably it is a different bug to the one that paneon is on about. Fitz defaults to 0 for gl_clear. 

qw engines have different physics and netcode, but i find ezquake to feel very nice for map development (sp and dm) 

Does it support the extension system ? 

I can't show you a screenshot view of the console flicker bug - because all screenshots I make with any engine show perfect Quakey goodness. To see what my view of GLQuake looks like, type 'disconnect' into the console. See how the console then covers the whole screen? Imagine that Quake constantly flickers back and forward between this full-screen view of the console and the normal view of Quake at 85Hz while you're trying to play. That's the Intel integrated video 'console flicker bug.'

The console flicker bug is definitely a software error (my GMA900 card works fine on toChris and Darkplaces, not to mention all other ID games from Quake 2 to Doom 3) - but ATI and nVidia (and previously 3dfx) obviously have much greater corporate focus in developing decent graphic cards/drivers than Intel, so I guess their drivers must be written to preclude errors like this. 

if you by that mean that you can call a builtin to see what's supported. 

Have you tried the suggestions I mentioned to see if they make any difference? 

I've used all of the major engines and so far fitz was the only gl-engine one that could handle the requirements of Per-kr's models and still run on my system. but sounds would cut out and packets would overflow at a regular rate. Fitz also had good network playing-ability... until i downloaded aguirre-quake and had no packets overflowing (so far, not thoroughly tested) and no sounds cutting out. i haven't tested network stability however. the only other concern i have and this would just be icing on a rather tasty cake, is if BengtQuake supports file handling from qc. that would be sweet. 

no extensions except the Nehahra ones yet. This is basically the few that seem originally intended for Q2 (e.g. tracetoss). 

Yep - I've tried your suggestions, but no cigar.

(I think I'd better buy an OpenGL textbook, download the Quake source and VS Express 2005 and try and come up with a fix for this myself. I can't be the only odd person that doesn't believe that any good games have come out since 2000, and hence doesn't have any good reasons to upgrade from integrated video apart from this annoying Quake bug.) 

gl_finish 1 and see if that helps. 

... gl_finish 1 doesn't help. Looks like I'll just have to play around with the code. 

option -condebug when running my GLQuake on the start map, you'll get a qconsole.log file. Zip it up and send it to me and I'll take a look at it. Please also include the full command line. 

damn fine job on that aguire. So so smooth. 

If I start the glquake.exe an error tells me:
(in german)
"Der Prozedureinsprungpunkt "_FMUSIC_loadSongmemory@8" wurde in DLL "fmod.dll" nicht gefunden"

I tried to get a new fmod.dll from fmod.org, but that didn't help. :( 

From the NehQuake readme:

If you get an error message regarding fmod.dll when starting, make sure to use the file from the Nehahra pack. Later versions are for unknown reasons not backwards compatible.

Please see if that helps. 

From the NehQuake readme:

If you get an error message regarding fmod.dll when starting, make sure to use the file from the Nehahra pack. Later versions are for unknown reasons not backwards compatible.

Please see if that helps. 

Seems to work. Thanks! :) 

HAS ANYONE FOUND A WORK A ROUND FOR THE INTEL FLICKER BUG, ITS A RIGHT PAIN, ONE WAY AROUND THAT I DO IS TO HIT CTRL UP ARROW AND ESCAPE AS IF IM GOING TO SHUT IT DOWN, THEN HIT X AND GO BACK INTO THE GAME THAT WORKS FINE AND IT PLAYS FINE AS WELL, IF IT GOES BACK TO FLICKERING AFTER A MAP CHANGE DO IT AGAIN, IT USUALLY WILL SETTLE DOWN AFTER ABOUT TWO MAPS 

OBLIGATORY REPLY ABOUT CAPITAL LETTERS 

NO WONDER I HATE FUCKING GAMERS SO MUCH 

HAVE YOU EVER CONSIDERED THAT SOME OF US MIGHT NOT HAVE EYESIGHT AS GOOD AS EVERYONE ELSE AND TYPING IN CAPS ESNURES IT MAKES SENSE 

HAVE YOU EVER CONSIDERED THAT SOME OF US MIGHT NOT HAVE EYESIGHT AS GOOD AS EVERYONE ELSE AND TYPING IN CAPS ESNURES IT MAKES SENSE