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. 

I'm not sure what editor you're using but in Worldcraft, setting flags is a fairly simple affair. Screenshot...

http://www.suspenlute.com/stuff/objprop.gif

Look for something like that. 

I'm currently using QuArK 6.4, I'm sure that spawnflag is visible in the entity description, but I can't verify now what are the avalaible fields (I'm currently at my job office, not at home...). I don't know if skills can be set like Worldcraft, or if the required value are directly number (0,1,2 or others... ) 

Let you know,
I've got it up and running without any problems. It slows down in the first large open area, giving the Tenebrae Crunch, but other than that it plays smoothly on my GeForce2 MX series. Officially this system is 733 mhz (pIII) but it actualy clocks substantially better than that.
I have to run in a little bit but I'll be able to give you a full e-mail update this evening E.S.T. time. 

you're playing in tenebrae? jesus crap i didn't think that was possible!

aguire: i don't know what you mean, when you say FQ has problems with the map if you only allocate 29000kb of ram. if you allocate more, those problems vanish.

it also perplexes me why fuh can't load the map while normal glquake can... the original is better than the port? hahaha :D

---

and yes, i do know about the clipnode limits. :( i've run into problems with that already. although, that's not a problem because all you need to do is throw clip brushes on top of the detail geometry and you're fine.
i don't know about Nodes and leafs though...

and, if you have a big map, with an upper area that mostly is there for the sky (think, beginning of nesp09 at the top), if you clip the whole area, does vis not have to do calculations for that area or no? 

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

That's a little known fact. The time delay between attacks decreases each time the difficulty setting is raised, until you get to Nightmare where there is no delay at all. Try it. On Nightmare, if you stand under a ledge where an ogre can see you but not hit you with its grenades, it will keep firing indefinitely with no pause between each shot.

AFAIK, the only other difference between skill settings is the speed that Vore balls fly at. They fly faster and faster for each incrementally more difficult skill setting, until they are traveling faster than the player on Nightmare.

So, if you know how to exploit it -- and if the map is built in such a way -- Nightmare can actually be easier than Hard. 

The delay between attacks and the voreball speed only changes on nightmare skill. On all the other skill levels they are the same.
Exception is Chthon that has only 1 health on easy and 3 on other skills, and his fireballs try to lead the player on hard and nightmare.
Also, on nightmare monsters don't go into their pain animations more than once per 5 seconds 

I can't see any reason for any program to start consuming all virtual memory just because you manually haven't figured out the magic limit yet ...

As for clip brushes, they can only reduce # clipnodes, they won't affect the visible hull at all (and therefore cannot help vis). 

there's no way to tell regular vis to 'forget' about processing a certain area? would that be doable without changing the engine? 

I know is through manually changing detail world brushes into e.g. func_walls. It's without doubt the fastest way to significantly reduce vis leafs/portals, but it has some drawbacks (e.g. no shadow casting). See my ToolTips for more details.

Newer games have e.g. area portals or explicit detail brush attributes that help reducing vis times, but I believe they also need careful planning to be used effectively.

In theory, you could change qbsp's portal handling to automatically cluster small leafs to help vis, but I don't know how to do that. I'm not entirely sure that it wouldn't require specific engine support either. 

well, it was worth asking anyway ;) 

That problem is easily solved by placing a simpler poly go version of the func_wall object inside the func_wall to cast the shadows in its stead. 

<nt> 

but then you get like double the r_speeds... O_o that can't be good! :) besides, i don't really like wasting a bmodel slot for just details/reducing vis time when it could be better spent on a cooler door or something like that. ;)