How does it look just with -extra (not 4)? 

That looks like a fog error, doesn't it? I can't imagine that has anything to do with his lightmaps. 

Shots taken in the same session or different sessions?

If different, launched with the same shortcut or batch file, or different shortcuts/batch files? 

That's probably gamma or brightness or something like that. Both look terrible on my night time red tint and 0.8 monitor gamma setup. If I disable that, the first one is find. 

it really does look like 32bpp vs. 16bpp to me. Even the down to the discoloration on the statusbar graphics in fitz0001 

A similar thing when using the SetGamma utility - which I use so that the worldcraft 3d window isn't too dark. 

Not the same session of FZ. Because I was running from batch files, I closed the FZ session between maps.

You might be pointing me in the right direction: I will now go and check the two batch files for differences in calling the -game and -map. 

From the config file:-

vid_bpp "32"
vid_fullscreen "1"
vid_height "768"
vid_refreshrate "60"
vid_vsync "0"
vid_width "1024"
viewsize "100.000000"
volume "0.7"
vid_restart
+mlook


However, one of the batch files has -bpp 32 in the command line it produces, and the other does not.

If I run the maps from the same FZ session using the command line with the -bpp 32, NO BANDING!

Is it correct that the config file does not take precedence over the command line? And is it correct that with no -bpp 32 in the command line, the entry in the config file is ignored?

And I suppose the default -bpp is 16? 

default bpp is 16, yes (glquake legacy, probably should default to 32 now)

if any video options are on the command line (-window, -width, -height, -bpp, -refreshrate) then the config file is ignored and the command line settings are used.

Otherwise it should use the config file during startup.

You can always verify by looking at the console for something like "video mode 1024x768x32 60Hz initialized" 

Got there in the end. Thanks.

But now the end is near and so I face the final curtain...

Stand by onetruepurple, it's on its way of that I'm certain (well give me a day or so to recover from this trauma) 

an autoexec.cfg file for your settings so it always uses the settings you want. (I don't know why it doesn't always save) 

Does anyone know why some editors have different texture projection axes which made it necessary to have -altaxis/-oldaxis on QBSP? Was it just a mistake or was there some reason for it? 

Note : TreeQBSP behaves slightly different than other QBSP variants. To make it behave more like
the others, the following command line can be used :

qbsp -oldaxis -oldleak [mapname]

In most cases, the new style leak line (default) is considerably easier to follow in Quake,
but if it doesn't seem correct (e.g. the line goes right through solid brushes) you might
want to try the old style line. You can always use the "-leakdist #" option to reduce the
amount of dots in pointfiles. If Quake cannot load the entire pointfile, use the Quake
command line option "-particles #" to increase the capacity.

Also, transparent water is not default (like in TxQBSP), but can be enabled via the
"-transwater" option. Beware of the performance hit in some maps.

Some lighting problems might occur when using most light tools together with a compiler
that supports enhanced texture positioning (e.g. QuArK ETP or Valve 220 Hammer). Light 1.27
and TyrLite 0.94 (see Tyrann's site below) or later versions support ETP. 

I'm not sure about this, but I suppose it was a programming error on some editor. The algorithms for both variants are exactly the same except for a < in one and a <= in the other. This is TB's implementation which is basically the same as the one in the compilers and in Radiant:


unsigned int bestIndex = 0;
float bestDot = 0.0f;
for (unsigned int i = 0; i < 6; i++) {
float dot = faceNormal.dot(*BaseAxes[i * 3]);
// no need to use -altaxis for qbsp
if (dot > bestDot) {
bestDot = dot;
bestIndex = i;
}
}


BaseAxes is an array of 3-tuples of vectors. This is the version to use without -altaxis/-oldaxis. The other version has dot <= bestDot. 

So it looks like the original treeqbsp had the 'wrong' projection code as well? Or the creator used an editor with the wrong projection and thought it was the correct on..? 

I've just noticed that one of my trigger_once has an 'angle' set to '-2'. This has crept in somehow but is entirely wrong.

The effect is that the player does not seem to activate the trigger without "wiggling" at the place where the trigger is sited, and it will not be obvious to the player that a wiggle is needed.

Can I remove this field directly from the .bsp file - I do not want to remove the trigger? I seem to remember that you can edit the bsp provided that... you don't alter the file length, or something like that?

The player does not actually pass through the trigger, they simply touch the trigger (it's against a wall).

I can change it in the editor of course but this is the level that took a gazillion hours to compile so I am trying not to compile again. 

You can remove the field and then run qbsp with the -onlyents commandline. 

I don't know who started this, but I suppose that some editor got it wrong and the original author of Tree tried to fix it. Or maybe he just got it wrong. It's super annoying, though. 

Remember to run light -onlyents as well if you have switchable lights in the map. 

Wow, now I understand why when I did onlyent compiles all the lights were screwed. Awesome tip, should be in quake wiki! :D 

I thought qbsp ran on the map file, and output a bsp file that you then had to run vis on to optimise visuals.

If I run -onlyents on the modified map file don't I end up with a bsp that still requires vis to be run on it? (That's why I was hoping that I could just manually modify the entity in the bsp file and leave all the compiled visual stuff alone.) 

No, because the entity lump is seperate from the BSP lump. It can update the entity keys/values without throwing away the BSP info. 

I found the entry in the bsp file, changed the '-2' to '00', saved it and ended up with the same file length. Ran it and it worked, so I guess the answer is that you can. 

I am clearly not understanding how this all works.

qbsp: takes a map file and turns it into a bsp file?
light: takes a bsp file and applies the lighting as defined in the entity list saved within the bsp file?
vis: takes an existing bsp file outputs a visually optimised version of the bsp file? 

yes, but each of those compilers puts their data into different parts of the bsp, so when you do -onlyents on qbsp, you're telling it to only update the entity list and not touch the lighting or vis.
and when you do -onlyents on light, you're telling light to only redo the lighting on switchable lights and update their connections with the entity list.