the only person who used DMM for several years was QMD... he ended sadly... ;) 

I agree with you, all editors have its own advantages and problems, and that's the mappers's job to find turnaround in order to release good maps..
BTW, I understand that some mappers can prefer an editor more than one other... but it's not a good reason, IMHO, to do "lobbying" against QuArK ;D 

I think Mark Shan used it for his huge Q2SP maps, e.g. Progetto Genoma. 

since I tried that example everyone is kiddin' about it, practoscope, proctoscope.
I don't mind, but Jean Plateau deserve a better answer than his invention sealed forever in Quake!

I bought DeatMatchMaker Quake1 on Ebay for $3,00
Now wait untill these boardsurfers claim it "unworthy".

But my question:
does it make sense trying to convert the Quake1 monsters to Quake2?
Or is it just whisfull thinking? 

i would play quake2 if there were q1 monsters in it + [i]good[/i] maps. 

also, regarding quark, you really need to try gtkr or wc to see the difference.

quark has it's strengths, but those other two just have more... 

Well, while I need for sure to test other editors to clearly have a good idea of these differences (differences that everybody seems to be convinced here), I just can say that QuArK works fine for me today... I think it's clearly the most important for many mappers: having an editor that works fine in order to have fun while mapping... even you need to fight against some "bugs".... But I guess it's not enough for most you... I'm not so "perfectionniste" ... ;P 

at http://user.tninet.se/~xir870k . Main features are major speedup of Light, increased model capacity and improved edict check in both engines and many other fixes/improvements. Please also see readmes for details.

Any comments are welcome. 

i'm not knocking quark. i used it to make four maps, so i do know what it's like. 

when he says major speedup of Light he means major. like 4 to 5 *Times* faster on some maps. a map i'm working on used to take 32 minutes to light. down to about 7 minutes.

it mostly affects maps with lots of spot lights and delay 1,2,5 lights.

it's one of those things that is really worth your time to download. it makes fine tuning lighting much less painful. ^_^ 

same here a map took 56 min before now it takes 20. I never use the fast option anymore since a normal -soft -extra compile only takes a few seconds more.

AguirRe is the man! 

I've used the new Fade Gate feature on many different maps and it actually works well for almost any map, no matter what lights are in there.

Typical speedup is about 2-15 times faster without any noticable visual degradation. 

On my new map, the -fast light compile used to take 25 minutes. Now it barely takes 5. AguirRe rocks. 

*** ERROR 73: Vertexes in map exceed 65535

uh oh... will sealing the map reduce vertices? i am inclined to believe so because the error appeared right after qbsp failed to fill the outside... 

fix0r teh leak0r and you will be good2go. 

I'm looking for a mapper(s) to help me work out stanards for my CTF, arena, and normal dm within my mod. So, I have something that mappers will like to create with. Contact me through the javascript link on my website.

http://planetquake.com/ud/

as 

What DaZ said; most values go down pretty much when the map is sealed.

Btw, if all goes well, I might have found a way to increase #clipnodes from 32k to almost 64k in the engines. 

wow! that would be great! i haven't clipped anything yet, so naturally clipnodes is over the normal limit and all my bmodels have become non solid. :P
it would be a nice way to continue testing gameplay before i finish clipping stuff. ;) 

Now you've lost me. My understanding was that clip brushes are used to force the players/monsters to not reach specific areas in a map. What else do clip brushes do? Sounds like I am missing something here... 

well, say you have a big swath of terrain. this terrain is bumpy and lumpy. all these angles take up clipnodes.

now, you put a big clipbrush over all the terrain. that means in hull1 and hull2 (but not hull0) the terrain is completly filled in where the clipbrush is, therefore less clipnodes are required.

same goes for details in walls and floors that the player can never get to anyway. you can always clip those to reduce clipnodes. 

You've mixed up clip brushes and clipnodes. The former are what you manually put in the map to block (or help) player/monster movements.

The latter is automatically generated by qbsp when transforming your map into a bsp that the engine can load. As necros points out, the more complex geometry, the more clipnodes. However, you can use clip brushes to reduce # clipnodes by doing what necros describes.

Check out my ToolTips document at http://user.tninet.se/~xir870k . There is more info regarding clipnodes and hulls. 

Just to support what is being said, fmb100 was tens of thousands of clip_nodes over the limit. If you have a look at the .map file you will see that I have some massive clipbrushes over the tops of the terrain that I thought players would not want to climb over, and also over some of the fancy ceiling areas. If you walk about on the roofs of the buildings you will hit some clipbrushes.

Clip_nodes are now just over 31K and therefore not causing a problem. 

I downloaded Texmex and am trying to convert the Tenebrea textures for Quake1 to Quake2.
As I converted the *.pgn textures to *.wall, all the maps I try to compile shut down of a GLQuake error.
How do i convert these textures to a Quake2 wad? 

marksurfaces... these are visible faces, right?

i'm guessing 51k marksurfaces is too high to run in glquake?
also, visleafs @ 9200 (8192 (?)limit): will performing a level 4 vis reduce these? (it's only fast vis atm)

lightmaps: at 78 atm. limit is 64(?)... how would i reduce these? is my only option to remove lights? 

exactly what marksurfaces are, but in normal engines they cannot exceed 32k without trashing internal heap memory with more or less random/erroneous results.

Vis leafs in excess of 8k will most likely crash normal engines and running fast/fullvis doesn't matter; map complexity is the problem.

As for lightmaps, check out my ToolTips doc. Exceeding 64 will immediately generate the dreaded AllocBlock: full error in most GL engines. Removing lights won't help at all; it's the total size of visible faces together with texture scaling.

If you send me the zipped map+wad, maybe I can see if there are any easy ways to cut down on the numbers.