OK, it seems to be a little complicated to add fog feature... so I have to forget it.. grrrrr... :(( but I continue thinking it should be great to add foggy environment directly with a level editor: this can clearly increase player insecurity feeling... foggy effect (near the ground or globaly in a full map) is pretty cool to prepare monsters trap, adding secret area without teleport, etc..
Perhaps future Quake engine and level editor will fully support the this stuff.. I hope..
Thanks for your response... 

If you'd map for the Nehahra, you'd be able to manipulate with many such features as fog etc from the editor.... 

I apology for my ignorance but... what is exactly Nehahra ?? 

It can be done in a sort of hackish way. Just use a progs.dat that lets you send commands directly to the console with a trigger (hipnotic would work) and set up concentric triggers for increasing density of fog.

It would give the illusion of the player walking *into* fog, but you wouldn't see it from afar.

Although from what Vondur said... Nehahra supports real fog? huh. 

I apology for my previous stupid question... I found the stuff on planetquake server after an internet quick search... I've seen your are involved with CZG in this projects... Nice work really reagrading the screenshots...
Bye... 

Thanks for the info...
I will try it in the future on a litle test map...
It is difficult for a beginner like me to ensure a correct performing of this feature, so I'm pretty sure that when my first map will be released (hoping it will be done one day...), foggy environment will not be included.... even if I found the correct way to include it.... Anyway, I seriously have to improve my mapping effort to build maps as good as some designer do... and so to be able to create some cool feature like foggy environment in a map...
Thanks again... 

just wondering if either of you got my messages. my email has been pretty wierd lately. 

yeah i did, i tried to get the mod running with fuh with -mem 32 and it still said out of memory, i will mess with netquake clients tonight and check it out 

i don't know what's wrong with the other engines, espcecially because fuhquake uses the quakeworld code and not regular netquake code.

i do know it works fine in fitzquake, regular glquake, tyr-glquake and software tyr-quake. it doesn't appear to work in regular winquake though, but it does work in tyr-quake which is essentially the same thing.

i've been using 32mb of ram all the time and it works fine.

i'm posting this here incase Headthump is having the same problem, so he can check this post out... 

I'm afraid the e-mail didn't come though. 

is you're email the one listed in your profile here? 

That is the one. I'm missing an email today Nengt as well. It may have something to do with file size. I have a 1.5 meg restriction on things sent out on the account but have never had a problem recieving e-mails larger than that. 

because both times i emailed you, i gave a link to the url.

have you tried emailing me? i haven't gotten anything from you yet if you have... 

Did you get it? 

i replied directly, so if this doesn't work then... heh :P 

<no topic> 

Hence the odd time delay. 

whee! 

aguire: what is the theoretical maximum amount of brushes your qbsp can handle?
These brushes would be very small (roughly 8x4x16 units, not necessarily rectangle) and mostly detail type stuff, not sheer size of the map type brushes.

what other problems can crop up from having a lot of detail type brushes?

say the actual map size is actually small to medium in size, maybe 1.5 times the size of e1m1, or like my nesp16. 

are in TxQBSP 64k and TreeQBSP unlimited. I've recently tested with one of Mike Woodham's maps that had 32k brushes and neither of my compilers had any problems with the brush amount.

However, having extremely many brushes will significantly increase compile time and increase the risk of float errors piling up and finally create leaks, clipping errors and HOMs.

Also, normally it's not the # brushes that kills the large map, it's the resulting # clipnodes, nodes, leafs, marksurfaces or other objects that have limits, either in the tools and/or the engines.

Not to mention vis processing times when vis leafs/portals go through the roof ...

I'd suggest that you start easy and check often that the tools/engines can still handle it. 

I made a brief test of your ne_lend_q1 map with the latest FuhQuake and it seems to have problems with it, even with -mem 64.

I checked the source too and it doesn't seem to have done anything at all to the limits I've fixed recently. That may explain why it can't deal with your map.

Even FitzQuake 0.75 has problems with it if you e.g. set -heapsize 29000. After loading, the engine starts to choke, consumes a lot of virtual memory and then finally aborts with an error message.

I hope metlslime can find a cure for it, it's a bit tricky. 

Hello,

I' about to finish my map, and I started to add some monsters... but in order to play several game skill (easy to nightmare), what are the requirements when adding a monster entity in the map ?? ... I mean, do monster entities need a special field to specify clearly the skill they are involved to ??? Or does the game upgrade monsters aggressivity itself ???

Thanks 

You can use the spawnflags to control at what skill levels an entity appears. On Nightmare skill they automatically have a more aggressive AI. The other skill levels all use the same... you just get more difficulty by having more monsters appear in those skill levels. 

Hello,

OK, thanks, I have to add a value to spawnflags field... but what are theses values ?? I think easy skill have its own value, medium as well, etc.. How these values are used ???

Thanks 

I think monster agressiveness varies a bit between easy, medium, and hard.