... 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. 

Yeah, i am using Worldcraft.

Than:
It appears i have been caught. I was using the method outlined in CZG's curve tutorial to bend a 3/4 piece of hollow pipe (roughly 256 in diamter, with 32 thick edges). When using this method, i found that the edges weren't aligning on the vertices with exact precision, so i using vertex manipulation to get it right. I then got lazy and started doing it purely with vertex manipulation. I'm guessing that might be the problem part.
I have used the "problems" feature, and it claims that the map is without error. It once had errors, but i fixed them manually, and then worldcraft seemed to like it enough to not give me an error.

Distrans:
Thanks, it's been a long time, my mapper's block had gotten so bad that i just decided to stop for like 6 months. Things seem to be going good now. Hopefully Travail isn't giving you splitting migraines.

aguirRe:
Thanks for the offer. I'm not going to be able to touch Worldcraft again until maybe tomorrow, most likely Friday, so if i still can't make the bad leaks go away i'll drop you a line.

ijed:
I wasn't specific enough in my post, but the "pipe" i spoke of is actually the hallway, so i'm not sure if making something like that would work as a function_wall. I may be mistaken, but i'm not sure if i could use a function_wall as a border to the void.
What you said about terrian is interesting though, since i do plan to use a good amount of terrain in my map. What do you mean by breaking brushes, wedges and leaks through solid brushes? I don't quite understand the explanation.

Thanks for the help all. 

Nope, you can't use a func_ to stop void ;)

The pipe thing (I use the czg method as well) is awkward, you've got to figure out the system of thinking in base 8 and even now I end up redoing it a few times to get it right for a corridor or whatever. I wouldn't recommend vertex manipulation for this - it'll drive you up the wall.

Also, you can just make a blocky corridor when seen from outside, then make it round on the inside with the 12 sided cylinder and double-wedge corner piece. Since the outside is void and not world nobody'll see it.

By blocking off broken brushes I meant putting a quad brush inside your terrain, sealing any hole it has from the void - but this is a big waste and will fuck vis.

When making terrain copy and paste a single unmodified wedge as many times as you'll need it then vertex adjust each piece seperately - WC tends to create errors when copying multiples of these. Either tiny misalignments (leaks) or a slight lip in the ground, so that you hit an invisible wall in the game when walking in a certain direction and then can't get unstuck. 

One other thing, probably something else you already know, but I didn't figure this out until a long time of using WC - you can move the camera (not just rotate it) in the 3d view with right click.

If that helps. 

Thanks for the heads up on the camera deal. I always found it annoying that the camera use was limited. That makes it better to use.