This situation is a bit weird to me anyway. I can see two or three valid ways to have fog and skybox interact.

Option one is that the sky is totally, fully fogged (like fitzquake.) This is realistic assuming you think that global, same-density fog is realistic. Since the sky is really far away, you shouldn't be able to see it. The main problem is that it's not actually realistic becuase fog in real life doesn't fill the entire universe with equal-thickness fogginess.

Option two is that the skybox is not fogged at all. This allows the skybox designer to put exactly how much fog he wants into the sky, in order to match the level's fog. They painted fog along the horizon of each skybox. This is how Medal of Honor did it, and it seems to work well almost always. The main problems are when you have really tall objects in the scene, becuase when far away they may still be tall enough to be sillouetted against the part of the skybox that has not been painted with fog.

Option three is to draw the skybox, but fog it slightly in the engine. This seems sort of silly, but does have the advantage that maybe people can use the same skybox with multiple fog colors. Anyway, if you do this, it should be fogged the same amount across each entire face of the box.

The way that doesn't seem valid is to actually fog the sky based on its true distance, since seeing that it's actually a giant cube totally destroys the illusion skyboxes are supposed to create. Extra-fogged corners, fog changing as you rotate the camera, these are ugly giveaways of a sky that isn't a sky at all.

Probably the best way to handle it is to have a standard fog blend variable. A value of 0.0 would use option two, a value of 1.0 would use option one, and any value in between would use option three.

But this only really works if there's a standard among engines, I guess. 

Option two doesn't really work with the scrolling cloudy sky, becuase there's no way to paint fog into it. 

would there be a way to control the maximum amount of fog that can be applied? currently, regardless of density, eventually, fog will become opaque given enough distance.

would it be possible to specify a maximum fog density that the engine would then stop fogging furthur when it's been reached? ie: a max fog density of 0.5 would mean that the skybox would be fogged at 0.5 along with all the other brushes, and since it would be a constant amount of fog, you wouldn't actually need to fog the skybox with the actual opengl fog, just tint it based on the value of 'max fog density' (assuming that's even possible) 

is there a way to blend fog and farclip together to actually make farclip useful? ie: fogging and when fog reaches 100% opacity, farclip everything behind that point in a sphere around the player. 

Not using the hardware fog functions. Opengl offers three falloff formulae: 1. linear fog with a start and end depth (end is where it becomes opaque) 2. exponential fog with a density (never gets fully opaque but gets damned close) and 3. "exp2" fog which is exponential with a different formula. (also never gets truly opaque.)

darkplaces and fitzquake (and probably others) use exponential with a "density" as the nly variable. However, darkplaces actually does this in software, which means that darkplaces could theoretically provide new and unusual falloff formulae, including ones with a density cap. Fitzquake and most other engines do it using the hardware features. 

1: my latest speedmap (sm110) crashes some engines, but i have no clue what the problem is (or at least i don't know the exact technical reason): the crashes occur when the player is teleported to a teleporttrain which is thereby also triggered to start moving along its path. glquake says "movetype push with a non-bsp model", winquake says "R_RenderView: called without enough stack", winquake-bjp already crashes when loading the map with "unbalanced unlock".
what do (could) these error messages mean? i know the first one, but it most likely is not caused by a trigger/func without a brush - i checked the .map file line per line several times.
you'll be able to play the map on sunday or so, depending on when headthump releases the pack - i probably won't be able to read possible answers until next week, that's why i'm asking now.

2: a question that came to my mind recently: is it possible to reduce the size of the monster's bounding boxes with qc? because the hit radius of some is way to big (or high). would something like this make sense/be useful? would it bring disadvantages of some sort? 

but in answer to 2:

one important thing to keep in mind about bounding boxes is how quake handles the collision of these suckers.

as you know, bsp makes 3 hulls, one is the hull you yourself made in the map editor, and the other two are progressively more extruded versions of that original hull.

quake does collision by using whichever extruded hull of the bsp corresponds to the proper size of the bbox as a point entity.

This means, there are only two possible sizes for bboxes for movement collision: player size and shambler size. (well, and point sized, but that's mostly useless for a monster)

However, you can use different sized bboxes for tracing weapons and collisions of point entities on those bboxes.

the problem is, quake will still use one of the three bbox sizes.

if all you are doing is *reducing* bbox size, you should be ok, since quake rounds bbox size to the highest bbox size when it decides what collision hull to use, ie:
a bbox of 48x48x70 would use the 64x64x96 bbox size and a 23x30x40 bbox would use the 32x32x64 bbox size.

this just means that you can't make a monster's bbox smaller so that it will be able to move through thinner areas. the only impact it will have is to make it harder to shoot.

this won't work very well if you are *increasing* the size of the bboxes, because monsters will be able to move inside walls (well, not the models, but the box will) and if you increased the size of a smaller bbox monster (player size) then it would start using the larger sized bbox (shambler size) for movement collision and wouldn't be able to fit through passages it used to be able to.

bleh, i'm too verbose and too lazy to go back over it and fix it. o.0 

Try running my WinQuake in a window instead (there's a bug I've fixed for the next version) or just run my GLQuake. You'll then get more information about this problem.

I'd suspect it's the same problem as with the rat in your sm100turtle map; there's a brush entity without a brush. Using my engines will hopefully tell you which one. 

aguirre: i suspected the same, but couldn't find such an entity. your glquake doesn't tell which one it is (it does not crash there, either) - or do i have to use any special commands (besides developer 1)?
fitzquake and dp work, as well.
i'll check it again and if i really made that dumb mistake again, i'll try to send a fixed version to headthump.

necros: thanks so far. yes, it is supposed to make the monsters harder to hit. i wanted to take the ogre's bbox as an example, as it extends over the full length of the chainsaw (idle mode) with a lot of unused space above, but i just realized that making the bbox generally smaller would leave the arm with chainsaw - which the ogre holds up while running - out of the hit area...
is there a way to individually adjust the each side of box? like making it a rectangle or something? 

If that error occurs, you'll be thrown out of the engine with a messagebox, so you don't need to do anything other than provoke the error. If it only happens in software engines, did you try running my WinQuake in a window (use option -startwindowed)?

If you wish, you can send me the zipped map+wad and I'll take a look at it. 

i typed out an answer, but i pressed the back button on my mouse. �_� the short answer is that yeah, you can do it, but that it will suck and won't work properly, so don't do it. :P 

After CDA project, I'm starting a new project based on DKT1/DKT4 episode texture sets. I have a small issue with these "fullbrights" texture, which are considered as "lights" ingame (i.e. FitzQuake), and which have a very bad look ingame (BTW I didn't modified the initial textures to fit Q1 palette... like I already did in CDA without so much problems)... I found a quick turnaround setting gl_fullbrights to 0, and also adding this setting in my config file (in order to not have typing the line in console each time I test the map)... Anyway..

My concern now is much more about the method to add this feature in a pack file: how to include a config file without causing troubleshouting with the player's current settings ?
OTOH, I could add a note stating that it is recomended to set gl_fullbrights to 0 in order to have a better rendering...
I guess the answer will be obvious, but I would like a good advice there ;) What do you think ? 

You can add the custom commands/cvars to a new xyz.cfg file, copy the original quake.rc file and insert a call to this xyz.cfg file just before or after the call to autoexec.cfg.

You put it before if you want to let the player's own settings override yours (nice) and after if you absolutely want to force the player to use your settings (less nice).

This way you can distribute a pak without forcing the player to modify his startup procedure and still get your console commands to run.

Both files xyz.cfg and quake.rc, you just put in the game directory outside the pak file to make it easy for the player to alter or get rid of them if he wants to.

You can of course also put them inside the pak in its root directory and finally put the whole pak as usual in the game directory.

In any case, be sure *not* to add or alter any other commands or the sequence in the quake.rc file, e.g. loading the map. 

Thanks ! 

For me at least, the answer is obvious... don't try to turn off my fullbrights... just fix the textures.

Its pretty easy to do it on a per-texture basis in TexMex... open the .wad file, select the texture you want, right click, adjust brightness, remove brites.

This should replace the fullbright color/s with the closest possible substitute in the palette. Unfortunately it seems you can only do one at a time this way, but perhaps someone else can suggest a way of doing a whole .wad at once.

Generally, this will probably produce acceptable results, but watch out for any dodginess (i.e. just make sure the program doesn't swap the colour to something completely inappropriate).

Its far preferable to modify the textures than to change the engine settings. Consider the following points:

- you can then also use fullbright textures on your buttons and lights
- Other people may copy and use the textures from your .bsp file
- doesn't require engine specific commands... gl_fullbrights 0 isn't going to do much for someone using WinQuake...
- I like fullbrights and I don't want you to turn it off for me! 

Regarding the DKT1/4 texture files size, considering I don't have TexMex installed, and also considering I don't know how to use it... (RTFM I know ;)... ), I guess it will take much more time to convert the texture to Q1 palette (one by one, unless there's a way to convert the full file at one time) rather than typing the gl_fullbrights 0 command into console...
OTOH, I can understand your point of view... And like you, I wouldn't like to change my personnal settings..
Furthermore, as you already noticed for my previous projects, I'm also very "slow" to produce a map (i.e remember CDA took me around 9 months, regardless of fullvis process runtime... I only map 1 or 2 hours per evening, and not all days of the week...:(... family stuff there...).. so "wasting" time to convert a wad file to Q1 palette sounds ungood to me... I would not like to spend 1 year before releasing another map...
In anyway, I will try to take a look to TexMex (download ans use), and see if it's possible to use it for a "massive" texture conversion... Otherwize, I will not use it... ;P
Thanks for your point of view :) 

It's not like you are using thousands of textures, you can really easily eliminate fullbrights in TexMex, texture per texture, shouldn't take more than a couple minutes.
If you really wanted to you could set up a batch process in photoshop or something too, and do it all in one go (but you'd need to extract the textures from the wad first).
Looking forward to your next maps anyways. =) 

answers are almost certainly easy but i found it frustrating trying to get textures showing up in gtkradiant.

i've installed the 1.5 beta from www.qeradiant.com, set the engine to quake, set the correct path and opened a .map file (it was bambuz's 108 speedmap), and all the textures are "not found". ok so i have to extract the textures from the .bsp file, or i can download something like quakewad.zip to get them (assuming the map uses only the original textures).

i downloaded quakewad.zip, opened the .map file again and all but one of the textures appeared in the "used textures" frame. i'm assuming the texture still "not found" was because it was a custom texture or quakewad.zip isn't the way to go.

so my first question is if something like quakewad.zip is a good way to get the original quake textures for use in an editor?

then when starting a new map and making a brush i want to apply a texture to it. with a brush selected i bring up the "surface inspector" and i can type a texture name in, and can't see a way to select a texture from any kind of list unless it was already used.

so my second question is if this is how you do it? or if things are configured correctly are all the available textures meant to be displayed in the texture menu after the separator? 

the lava texture is from the team fortress pak file. (pak0 or pak1.pak) Get the equake tf addon pak (from quakeworld.us) if you want that tex :)

You can rip textures of maps and paks with programs. One at least comes with worldcraft. 

of course you can get the texture directly from the bsp too with some util... :P 

How do i prevent cracks on bezier patches?

how *do* i prevent that? :P

http://www.planetquake.com/necros/temp/patch.jpg

you can see that the highlighted patch doesn't match with the one joined to it (they are seperate patches)

how can i get them to have the same amount of sides so they line up? 

Apparently, GTKRadiant 1.5 will read .wad files directly from quake's id1 directory. You would have to extract the textures out of a bsp file manually, with a program like Wally. 

This will also disable fullbrights on torches, muzzle flares, and lightning bolts. 

works perfectly. 

i'm hopelessly behind the times, but help me out here... :P

basically, for my d3 map, i wanted to have a few specific settings that will be used for that map only, and they are all cvars... (namely, wanting to tweak g_kickamplitude and g_kicktime a bit to reduce 'owl neck' and pm_walkspeed to a *ahem* proper movement speed.

is there some kind of way to exec a cfg file or something? i can't even get an autoexec.cfg file to work-- i added g_kicktime 0 to my autoexec, but it gets reset on every level anyway. :P