What is it? 

There seems to be a small issue of sometimes not getting the green armor at the beginning of the Map "Return to Dust" with directq. (you have to jump to get it Has anybody else encountered this? 

I have an animated lavafall texture on a func_illusionary which I had to light quite heavily to make it look right in Glquake (as bright as the regular lava). But now it's totally overbright in DirectQ (and one or two ports from the Proquake pack, for example): screenshot. Even the latest version (1.8.666a) doesn't display it correctly - the first frame of the animation is fuglified like that while the others are fine, so it flickers. What's going on there? 

... you didn't applied Quake palette to the first frame of the moving texture... Export your image from wad, apply quake palette and then import it back to wad.
It should solve you issue 

It's the engine, not the texture. 

I don't understand why the engine would crap the first texture frame only... hence my answer :P 

Neither do I... hence my question :) 

I'd guess the excessive brightness is because of overbright lighting. The same would happen in software Quake if so, so that's a useful test. (Also FitzQuake and any other engine that supports overbright lighting). gl_overbright 0 will revert DirectQ to GLQuake lighting if necessary.

I don't understand why the first frame would act strange either. Cross-checking with other engines might also be a useful test there. 

I tested it with Winquake, Fitz, and DP (all of which support overbright lighting). The texture looks right in all of them. 

What's the map? I'd like to test this in the debugger to see if I can figure what's going on. 

http://negke.quaddicted.com/files/mappi.zip 

Fixed it. Your frame 0 texture was generating the same checksum as the standard lava texture which caused animation cycles to get messed up when both were visible on-screen at the same time. 

I thought unique file names were enough. Cheers for fixing it. 

I was comparing checksums though, not filenames. I just added a check for filenames too and it worked. :)

Just waiting to see if I can fix one more thing and I'll release a patched version for this. 

I have a question regarding Directq, when I use 1.866b, I can see the fog fine, but I thought Directq didn't support fog since 1.8.3? 

 

then's what with the "getting fog back in 1.9"? 

I lied. :)

I actually restored fog a few versions ago; it only works with shaders (OpenGL vs D3D differences here) but it's there. 

I noticed although fog works, it is not loaded automatic in some maps, such as neh2m5, I have to manually set the fog value in the console. Why does it load for some maps and not others? 

For the same reason as it behaves this way in Fitz. It only loads automatically if the mapper has set a worldspawn key, and is cleared between maps (and the reason for that is because apparently that's the way mappers prefer it).

I did write about this back in October... http://mhquake.blogspot.com/2010/10/questions-about-fog.html 

I am not a mapper so the technical stuff is beyond me, but basically what you're saying is that the mapper didn't intend for that nehahra map to have fog by not setting a worldspawn key? 

More or less, yeah. Another possibility is that the map was made before fog via worldspawn in engines was common, but we can discount that in the case of Nehahra. It is a problem with older maps though, and unfortunately I can't see a solution that would make everyone happy. :( 

for the users that do want the fog, is there a quick way to enable it? Right now, I have to load it up in Aguirre, get the fog values, and manually input them. 

well, i suppose you could put those settings in a cfg file and just run that all the time. 

Really, this is something that players and mappers would need to trash out between themselves. I don't want to be stuck in the middle of this argument. Whatever the accepted solution is, I'll do, but until such a time as there is an accepted solution I'm preferring to keep my head down and leave things as they are.

The only exception is if we come up with something for RMQ that handles this situation; that has a higher probability of also being done in DirectQ.