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. 

...Ionous is mapping again! I thought we'd lost you buddy, welcome back. 

If you can't sort it out, send me the zipped map+wad and I'll check it out. 

i got 311 on mine :\ and i dont have leaks to... 

One thing I found with terrain mapping (lots of wedge brushes) is that if it's a long thin wedge then it won't break, but usually breaks any thicker wedges nearby so that the leak goes straight through a solid brush. The only decent way to het round this is avoid thin wedges, or else have a big block inside your terrains, usually alot of em, though that's a ugly and wasteful fix.

Other than that turn all pillar / pipe / cable flanges into func_wall or else leave them 2 units from touching the wall or floor. The second can still produce vis crashes if you have lots of them but the first is completely safe, as long as you don't breach edicts.

As than says use the check for problems function, but don't auto-fix. If you do have invalid brushes you may not be able to fix them without creating from scratch, though that depends on how complex they are.

Can't think of much else (I assume you know about the pointfile command - type it ingame at the console and it's show a particle line pointing at the precise location of the leak).

Hope that helps.