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.
Oh, does this mean the Fitzquake can't support Neh fog? (Aguirre's can support both, but that engine, like Nitin said, isn't widescreen friendly)
When I ran directq 1.8.7, it looked like this:
I have the June 10 version of Directx, My system is a Dell XPS 1640, 4gb ram, p8400, ATI 3670 with 10.6 drivers.
Directq 1.866b works perfectly. Thanks.
Thankfully it's a beta release...
A few people have got this bug and it seems confined to ATI users. I've a good idea what causes it and will have a fix coming in Beta 2.
Bug In Beta 2
When you start a map, you're not facing straight fowards. Seems to happen with any map.
Doesn't happen with any of the ID1 maps. Can you be more specific?
This is how I start at Menk. I've tested Fort Driant, and ijed's Maelstrom. All like that.
This bug does not happen if you load the map from the cosole, only via a batch file.
My batch file for load Menk:
directq -nocdaudio -current -game id1 +map Menkstart -id1 -bpp 32
This bug did not exist in 1.866b. Thanks
It also happens in 1.8.7 beta 1, so it is the changes between 1.866b and 1.8.7 beta 1
Directq 1.8.7 beta 2 crashes when I run Five Rivers Land by JPL
this is my commandline:
Directq -nocdaudio -current -hipnotic -game quoth -heapsize 48000 +map 5rivers_e1 -bpp 32
said something about Directq being toast.
Directq 1.866b worked fine.
5 rivers has corrupted TGAs for it's skybox which D3D's TGA loader doesn't like. A fix I had before was bypasssed by some of the new code.