Just the job. Thanks very much.

232 models :/ I guess that means I have at most 24 more triggers, doors or additional precaches I can use, though I suspect there are some engines that precache their own extra things for enhanced explosions, shotgun shells etc.

Do you know off the top of your head the max number of edicts? Is edicts something that can be increased at the command line in a regular Quake engine? 

Oldest engines (DOSQuake?): 450
Old engines: 600
Old Neh engines: 1000
Joe: 2048
Fitz: cvar, up to 8192
My engines: 4096
DP: 32768

Other engines may be different. I haven't seen any cmd line option for edicts.

Usually, it doesn't help much increasing just the edict limit, as having many edicts will just generate packet overflows or SZ_GetSpace errors instead. The only engines I know that can handle many edicts are DP and my own. 

I'm working on a level where you are at the top of a tall cliff and you're shooting rockets down far below. Is there a limit to the size of a room in Quake? I get a lot of tearing in the distance I think because the room and blocks are too big. 

By tearing - it sounds like HOM (hall of mirrors). It also depends on your engine. In AguirRe's the only limit is created by including fog, which sets a clip plane before it's end that can chop long distance stuff (not sure how far, 1024 units or so).

If you include fog with a low density and have long distances this'll crop up. If not you should be able to see from one corner of a max extents box to the other. Though it does depend on the engine.

Other than that you can try looking for tiny brush misalignments - the usual cause for HOM's. 

I'm using WinQuake and might start using DOS. I made my giant room smaller and now it doesn't tear much (unless you get in a certain corner with a lot of enemies around). It was just a test map. I was curious if there was some set limit you weren't supposed to go past. Thanks, ijed. 

try setting

r_maxedges 100000
r_maxsurfs 100000

or just use my Enhanced WinQuake and save yourself a lot of trouble. 

I know the game is ten years old, but I want to design it for the original. 

thanks for the info, you fountain of knowledge you. 

... looks like you found some trax for your pack, but if you need sound in the future drop me a line. 

What is the best program for drawing your own Q1 textures? 

Thanks for the offer, though I found some that fit really well. I thought about asking but didn't want to because it'd be alot to make in a short time.

But now I've got some computer issues so I don't know how long it'll take for release; bah. 

search Wally or Texmex

http://www.quakeone.com/navigator/ 

Thanks, Madfox. 

I'm currently working on a big project (i.e Doom3 Hell level remake), and I exceeded this evening the maximum marksurface value (i.e message is WARNING: Marksurfaces 34803 exceed normal engine max 32767 , with aguirRe's TxQBSP v1.12). I'm able to load the map with aguirRe's engine, but it is choppy as Hell with FitzQuake...
I just would like to know if there's something I can do either to dicrease Marksurfaces in a map... without removing any poly (and it is not yet finished....), either if there's something to do with engine options... or if I have to restrict the map to aguiRre's engine ?
Any advices ? 

if you're planning to expand the map further, you likely have a problem. you can try to lower marksurfaces by turning some structures into funcs, moving them away from adjacent brushes, or reducing faces by merging them into individual textures. 

According to other mappers, marksurfaces might go up and down while adding more brushes, so you could try continue working on it and see if they drop.

Furthermore, if Fitz is just choppy, I doubt that it's the marksurfs that's causing it (normally it would crash if the marksurfs were exceeded). You could also check with e.g. JoeQuake.

Try upping heapsize instead and see if that helps, e.g. 48-64MB. 

Sometimes they go up other times they go down.
I'm having trouble with marksurfaces as well on the map I have in beta.
I have found that Fitzq can handle marksurfaces up to around 38000 and then it crashes! Anything under this seems to be safe although it's over the max. 

...if you can build it over the limit Fitz will handle it to where Hrimfaxi indicates. But, JPL if this thing is as big as I think then you might seriously consider chopping it up at some logical point. The only way I could get qte2m3 to work in the end was lop off everything past the GK door and turn that into a separate "end" level...that and simplify some of the natural rock formations in the main map (that was painful =/ but necessary)

Good luck with it either way. 

I am currently having problems with the number of marksurfs in my large map, but fitzquake still loads it. The thing you need to be careful of in fitz is that when marksurfs, clipnodes etc. are exceeded, memory gets randomly overwritten. I don't know exactly how random this is, because at the moment there are no noticeable problems with my map. However, when I had too many clipnodes as well as marksurfs, the last func entities that I created were becoming nonsolid - I guess this is just because there were too many clipnodes to fit into memory and the solid entities were the last things being loaded so they became nonsolid.

I have had fitz crash because of exceeded maxsufs before, but oddly it doesn't crash as soon as you pass the limit. Anyone know why? 

Thanks a lot for all the advices... I think I will continue my work as I just need one more corridor and a room plus the final area to finish the map... Maybe it will pass with a fullvis process... In anyway, I already have an idea where to split the map... I'll see that later when all the design will be done. Maybe FitzQuake will be able to load it without choppy thing... I don't know what happened, but it occurs after the first monster spawn... pretty weird... I have to re-test it to see if the problem is persistent....
Thanks a lot again ;) 

The limit *is* 32768, any engine that's not fixed to handle a higher amount will behave unpredictably due to memory being trashed. Depending on how that memory was/is being used, you'll get different results.

JPL: did higher heapsize help the choppyness? 

I still not tested it yet... but I think I've always a -heapsize 48000 added in the command line.. (note I'm not usre of the value ;P ...) 

Well, having -heapsize 48000 option doesn't help much with FitzQuake: the result is that i need to cut the map in two pieces.... Not a big deal....
Anyway, I already said it but, thanks a lot for all the help above :) 

C:\Program Files\worldcraft\Q1Tools>txqbsp -quiet -numpercent capacitance
TxQBSP 1.11 -- Modified by Bengt Jardrup

Inputfile: capacitance.map

Building hulls sequentially...
Processing hull 0...
100%
100%
WARNING: Reached occupant at (512 -1240 8), light
Simplifying ... Leak file written to capacitance.pts
100%
Processing hull 1...
100%
100%
WARNING: Reached occupant at (64 -256 32), info_player_start
Processing hull 2...
100%
100%

34 warnings

So, yes, my map leaks. I don't know why.

The map is completely sealed. I do have complex brushwork, as in 3/4 of a pipe wrapped around curved corners. Could this type of manipulation cause a map to leak, even if it is completely sealed in the editor? 

If you are using Worldcraft, the answer is yes. The most likely problem you are likely to face regarding leaking maps and worldcraft is that you have used vertex manipulation to create an invalid brush (i.e. a non-convex volume, or non-planar face). When you try to compile a map with such a problem, the brush shape will be changed by the compiler so that it is convex, which can result in leaks appearing.

You can check for invalid solids by hitting alt-p (should also be in the map->check from problems menu), which will give you a list of problems with your map. DO NOT let Worldcraft auto-fix your problems, as it can sometimes make things worse by deleting things that only required minor modification. The go to error option is, however, completely safe, and is VERY useful for tracking down solid entities that don't have any brushes (if you merge two solid ents, one always remains and causes problems, but can be selected by checking for problems and deleting it manually.)

There are other reasons that a leak might occur, but I think the above mentioned vertex manipulator abuse is the most likely problem. Try checking it out.

By the way, if you add a lot of fields manually to entities rather than modifying your FGD files to include them, Worldcraft's problem checker will report the key/value pair as being an error ("entity has unused key/values") These errors can be ignored completely.