What Preach said. Also I looked into menk source and found that I used frame 93 and.. I used class viewthing instead of func_illusionary, I saw it in someone's map. 

Is there any bsp compiler that parses func_groups, so I wouldnt need to 'move to world' each time I want to check the map in game. ( Im resistiing to use that java mapconverter)

This would be a really really good idea, to support func_group in a q1 bsp compiler (*wink* *wink* aguirRe ^_~).

I'm using gtkradiant now, after being spoiled rotten by all the grouping and layer functionality of WC/Hammre, and I so yearn to be able to select a whole bunch of stuff with just one click again :{ 

.. 

I so yearn to be able to select a whole bunch of stuff with just one click again :{

You can use a limited func_group in GTK for editing purposes with Q, you just need to add the relevant stuff to the def file. You can't actually select with one click, but maybe 2 ;)

(bare with me, I have just formatted and reinstalled and haven't got my editing stuff installed and set up yet, to busy with Q4, so I may not remember some stuff, I just do it on auto pilot without thinking about it)

When you have grouped your stuff, you can select it by bringing up the little window that lists the entities in your map(forget the shortcut, you don't seem to be able to select it by just clicking one of the components), highlight the one you want, and hit select or choose whatever it is. I usually give each group a name so as I know which, is which, otherwise you'll have multiple entries of the same entity and not know which you are after. It's not perfect, but it's better than nothing..., maybe. This is what I've got added to my .def,

/*QUAKED func_group (0 .5 .8) ?
This is not an entity as such. It is strictly an editor utility to group world brushes and patches together for convenience (selecting, moving, copying, etc). You cannot group entities with this.

-------- NOTES --------
The TAB key can be used to flip through the component pieces of a selected func_group entity, isolating individual components. To make a func_group into a terrain entity, refer to the Terrain Construction documentation

If this is useless to you, or not what you are on about, or already know, just disregard it as the ramblings of a mad man. 

Does anyone here know the origin (and source code) of the custom monsters in alk11 ? 

I'm building with WC and using AguirRe's tools then testing in fitz.

I've finished building a start level that uses switchable lights. I fully compiled the level, and everything tested out fine except the exit portals pointed to the wrong levels. I went back in and changed the "next map" field in the trigger_changelevels then did an -onlyents compile. The switchable lights no longer work. I followed up with a full compile and the lights work again. Just to be sure I wasn't missing something, I then went back in and changed the "message" field of the trigger_multiples in front of the exit portals and ran an -onlyents compile. The lights cease to switch.

Does this seem strange? 

you need to run aguire's light with -onlyents to relight only the switchable lights and reassign the targets to the proper lightstyles 

... just adding another beer to the total I already owe you :) 

is there a way to avoid "ugly rocks syndrome" in d3 engine?

http://img418.imageshack.us/img418/8317/shot000043gb.jpg 

d3 engine noob here, but you could try just putting some small non shadow casting lights to try to light up the darker faces?

it seems to work ok on angular geometry, but i've never tried it with terrain, so it might not look any better...

also, i don't know how much performance hit non shadow casters make on a large scale as i've only done it in small quantities. 

Check out this screenshot from your engine:
http://img475.imageshack.us/my.php?image=foghuh1cj.jpg
What causes that black triangle in the back there?
The sky is RGB 0 0 0, fog parms are RGB 0 0 0, density 0.0666, so in theory the sky and fog should always be of same color. Yet I do see this black "clip plane" there. Tried messing with the gamma and it still shows up.

Would like to know really! 

from the shot, but in general if you're experiencing weird artifacts with sky and fog, you can try tweaking the gl_skyclip cvar (default 4608). It controls the farclip distance of sky in fog.

There seems to be an inherent conflict between sky and fog projection in the distance, therefore I added this cvar to adjust for various combinations.

The basic problem is that the skybox is supposed to be infinitely far away and when fog is added, it will always hide the skybox. Since this destroys the whole idea with the skybox, you can use this cvar to find a balance between skybox size and fog density/colour.

Other artifacts may also appear when using certain fog density/colour combinations, typically banding triangles that follow the current player view. This occurs even in 32-bit colour.

This can easily be seen e.g. in the Nehahra map neh2m3, where a dark and dense fog is covering a very bright skybox.

Please see if any of this applies, otherwise I'll have to take a look at the map. 

you can try tweaking the gl_skyclip cvar (default 4608).
Haven't been messing with that value, but the black triangle appears at a much shorter distance, ~1500 units or so.
PreEdit: I just tried a few different values and it had no effect.

Other artifacts may also appear when using certain fog density/colour combinations, typically banding triangles that follow the current player view. This occurs even in 32-bit colour.
I think this sounds more like my problem, I'll try perhaps to mess around with the fog density and see if anything happens.
PreEdit: Ok just tried that too. It's definitely a banding issue, the "distance" to the black area varies with the fog density.

So yeah I dunno. Probably not much I can do about that. 

like darker fog in general causes more visual artifacts than brighter. The OpenGL fog might not be well suited for that. There's also the occasional "dust bunny" effect; in a dark skybox with thin and bright fog, the skybox corners get revealed due to fog congestion.

With some tweaking it's usually manageable. Make use of the engine fog command; it makes trimming a lot easier. 

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