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. 

...should have fog in it i'm sure; kind of an orangey yellow colour. nehahra handled fog differently though - i think it was via an info_start entity rather than a worldspawn value so that might be why certain third party engines aren't picking it up? i may have misinterpreted parts of what mh has said above...

i'll admit i like adding fog (and skyboxes) to maps that don't have any. i don't mind it resetting when a new map loads but i do kind of wish it would remember the settings when you die & reload; i'm not sure how possible that is engine-side... 

> ...should have fog in it i'm sure; kind of an orangey yellow colour. nehahra handled fog differently though - i think it was via an info_start entity rather than a worldspawn value so that might be why certain third party engines aren't picking it up? i may have misinterpreted parts of what mh has said above...

Right, that would make sense. If it expects to use the old gl_fogenable/etc cvars there may be cases where sometimes it gives results that look like they're working and sometimes it doesn't. I'll need to test fully, but it's definitely a viable-sounding theory.

In my specific case I went for FitzQuake fog, the reasoning being that it's the current standard and is used by more recent maps and mods. Not sure if it's even possible to make this compatible with the old method.

> i'll admit i like adding fog (and skyboxes) to maps that don't have any. i don't mind it resetting when a new map loads but i do kind of wish it would remember the settings when you die & reload; i'm not sure how possible that is engine-side...

Perfectly possible. One solution I have (don't think it's in a released version yet though) is to not wipe the fog if the map name hasn't changed. The same could be done for skyboxes. 

There is a bug with directq regarding the map rc1 by fat controller. I can't move at the beginning of the map. RC1 works fine in Fitzquake085. Thanks 

Hmmm - every engine I've tried this map with - including GLQuake - sticks at the start, with the exception of the latest Darkplaces. This includes a freshly downloaded Fitz0.85 - sticks at the start.

ProQuake (Win and GL), EngineX, Fitz, RMQ, DirectQ, ID Quake, older Darkplaces, all stick at the start.

I'm finding it difficult to accept it as a DirectQ bug. More likely a config setting, a QuakeC bug or a map bug (bad clipping hulls perhaps?) 

More info; I've just read the readme for this map, and it's clearly stated in there that it's a beta map. Unless there is an obvious engine-related bug that's common to everything except the latest DP this one is going in the "won't fix" bin. 

There is a bug with the first two ammo boxes in the map sm28 for Directq, when viewed from certain angles the sides of the ammo boxes are missing. This does not happen in Aguirre Quake, Fitzquake 0.85 or RMQ engine. 

Known bug, will be fixed in the next one. 

Is the next version going to support Neh fog also? 

> Is the next version going to support Neh fog also?

No. Neh fog is a completely different implementation of fog that's incompatible with the way DirectQ does fog, and will never, and can never be supported. DirectQ's fog is based on FitzQuake, which is an established, clean and sane standard for mappers, whereas Nehahra is a bunch of dirty hacks (technically impressive for the time, but still a bunch of dirty hacks).

It's just not possible to support both as there is no way of differentiating between them when reading fog values from worldspawn. Given the choice between supporting one standard that was only ever really used for one mod, versus supporting a second that is in widespread use, is what mappers expect, and which will continue to have content released that uses it, it seems obvious which to pick.