and fishes are crazy, they follow you around everywhere. I'm not sure about spawn, but I think I've seen them misbehave too. I haven't seen any code that explicitly should let them do this. 

it's option 4: bastards! evile bastards at that. 

Option 4 ?? What's this ? Again a ununderstable joke for non anglo-saxon native, or is it a real feature ? 

it's a bug, apparently in the engine code that lets flying and swimming monsters sometimes clip through walls for no apparent reason but can sometimes be brought on by having a few of them in an enclosed space. 

I there a way in Quake to print a message when the player has died? 

to my knowledge at least. 

to everyone who helped me. The door stopped being touch-openable when I removed the "requires silver key" -spawnflag. Now if someone would upload the speedmaps... 

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) 

meant you had the problem solved. I probably could have saved you some time there. Sorry. 

Hi hi.

How can I get a dead player inside a single player map?

I've seen it on Menk (http://speeddemosarchive.com/quake/maps/menk.zip). I'd like to copy it.

Any ideas? 

Make a point entity in your map, and give it a classname of func_illusionary. Then set it's model field to "progs/player.mdl" and it's frame to the corresponding frame number in player.mdl for a dead body - I think 53 is one such frame. For more details, see http://www.celephais.net/board/view_thread.php?id=37116 

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.