But you're a hotshot Quake IV mapper - so I guess it's a win. 

Bleh. There are a shitload of people in the mapping community who are just as talented as I am (or more).

A fair part of getting that gig was previous experience, persistance, and simply being in the right place at the right time.

Granted, my absolutely gigantic genitalia might have had something to do with it. 

Granted, my absolutely gigantic genitalia might have had something to do with it.

Cool. Any chance of working that into some sort of Quake IV easter egg? 

Put a Quake IV version of RPG's Penile Devestation in there as a secret level.

I'm just glad that there are those who scored higher than me, but then again, I am more freak than geek. 

this is not really mapness, but more of a technical question on quake. so it's more a question for engine coder dudes (metl, aguire...)

specifically, how does quake handle sound playing?

channels: how do channels work? i know basically that you can only play one sound on a channel, but there are only 8 channels available in quake, and i've heard more than 8 sounds at once coming from different entities (like maybe 10 different monsters awakening and all playing their sight sounds)
but a single monster playing sounds on the same channel will cut off the previous ones (an ogre playing it's sight sound will cut off with the pain sound if shot)
so exactly how does sound playing work? 

I've always wondered what the exact correspondence is between the attenuation value and the "radius" of the sound. If I knew these values I guess I could place ambient sounds in the most optimised positions possible; ie maximising sound coverage of an area whilst minimising sound overlap. 

there are different attenuations for different emissions. regular sounds like monsters and guns are attenuation 1, whereas ambients are 3. obviously, this is some type of multiplier that the engines uses to calculate the volume from distance value. i find ambients tend to be heard about 512 units in diameter with origin as center... can't verify this however. 

Related to RPGDM1 last DM map, I would like to have some information about Vertical up or down movement.... I tried to extract RPG's map with my editor in order to understand how you built the ladder... but I didn't find what I was looking for very clearly (perhaps I didn't look in the right direction...)... I mean, how do you allow the player to walk verticaly up in front of the ladder ??
Thanks 

Are just very steep staircases made of clip brushes. Nothing more, nothing less. 

OK !! It explains why I didn't find the stuff: all staircases were not fully translated into polygons after conversion (it appears some "hullxxx" in the .map file) and thus they were not clearly visible in the editor.. Thank you very much... It was another stupid question from the beginner I am... ;P.... 

RPG kindly released the source map for RPGDM1 along with the bsp, so you can load that into the editor instead. 

Thanks, I'll take a look with a lot of care this evening...
Bye... 

ok, my new map is way over max. clipnodes (about 46K). Covering detailed areas in clip brushes should reduce this, right? Also, say a clip brush covers a "broken" floor (like the floor at the very start of Bastion) I've noticed that the floor is still sort of sticky: i.e. it's flat, but the friction seems very stiff. Is the clip brush still reducing clipnodes if it's 'flush' with the unbroken parts of the floor, or does it have to be raised slightly off the entire floor surface? 

I guess you've already checked my ToolTips for this issue. Clipnodes only add up in hulls 1/2 (the clipping hulls), so covering with clipbrushes help.

AFAIK clipbrushes melt together with other brushes normally, so you shouldn't need to raise the level (at least I've never seen such a requirement).

I'd absolutely recommend that you check out the map in hulls 1/2 using the -hull # option, to see if there are any major enclosed volumes in those hulls that need filling (or open to the void).

Noclip outside to see if such orphaned volumes exist, they can add quite a few clipnodes to the total. It's not enough to seal hull 0.

If you wish, you can send me the zipped map+wad and I'll see if I can spot something. 

Sorry for any delays in my responses--I've been gone a few days.

As Kinn said, the "ladder" effect is created by making a very steep staircase using the clip texture. I used 16 units high, 112 units wide, and 1 unit deep. And as aguiRe said, the .map source is released, so you should be able to get a good look at it in your editor. Unfortunately, as aguiRe mentioned to me in an e-mail, there seem to be some floating point errors, but that isn't always a problem, especially if you don't compile it. 

JPLambert uses QuArK so he should be fine with float maps. QuArK can even read the original Q3 format as well, so there are several options.

The ones most likely to have problems are those that use the BSP editor (WC seems actually to be fine with floats too).

My compilers are OK too since they handle floats, even the technical notation in your converted Q1 map (otherwise you wouldn't be able to build it). 

With your latest compile tools, my map builds ok (with no leaks), and it can be loaded in custom engines that can tolerate it. I'll give it a good going over with clip brushes first; but if it's still giving me problems I'll hand it over to you. :) 

How many marksurfaces does your map contain? As far as I can see there are usually more marksurfaces than clipnodes.

I found that map crashes in almost 100% cases when it has >35000 marksurfaces. That goes to vanilla glquake or winquake.
But I may be wrong. 

46688 clipnodes
28732 marksurfaces

unusual? btw, what are marksurfaces exactly? 

exactly what they are, but AFAIK they are bad ;)

My map has 29k clipnodes and 34k marksurfaces.
Marksurfaces grow faster than clipnodes for me, but that's the experience only from one my map. 

in how the exceeded limits affect the engines. The excessive marksurfaces (>32k) cause strange behaviour in most engines due to a coding bug, the limit should actually be 64k.

Clipnodes appear to be related to nodes which by specification cannot be >32k, since they'll otherwise be interpreted as leafs. If they are, the engine won't be able to tell how the bsp tree looks like and anything could happen.

However, I've never seen any engine actually crash due to excessive clipnodes. 

uses a staggering amount of triangle brushes; i guess that's what is causing the clipnodes to skyrocket 

earlier with PuLSaR's map, I found out that marksurfaces are affected by both world and entity brushes but they're only affected by the visible hull (0). Adding clipbrushes won't reduce them.

AFAIK marksurfaces are somehow related to surfaces (i.e. visible planes) in the map. 

Kinn, your prevous post has a cool #2222 

show that the map with ecsessive amount of marksurfaces becomes very sensitive to adding thin detail brushes and curve constructions.