Huzzah !! Just experimented as per post #11382, and it works perfectly... Just remains to find sound replacement for drown1/2.wav !
It sounds I have found a good way to emulate wero gravity in space... now I can start to map my spaceship.... even if I do not have clear idea about what I'll do ;P
Again, thanks a lot for your help :D 

... I've found exactely what I was looking for.... :E 

i did a little bit of testing on this issue.

1. yes, it also occurs in FQ085.
2. it wasn't actually that the map had >512 sounds.

what seems to happen is that, when loading a new map, the engine doesn't flush the precaches or something. the reason it crashed before was because i was loading it from the console after another map had already been loaded.

if i start the map up first, from scratch, it's fine.
if i try to load another map that uses a large number of sounds, it will crash.

this sounds like not a big deal at first, but it means that you can't have a map pack with more than 1 map that uses many different sounds. :( 

and looking forward to see the map then, jpl. :) 

What would happen if you load a map with many sounds, then a map with few sounds, and then another map with many sounds?

Just an idea. 

eventually, if you, say, had 512 maps, each with 1 unique sound, it would end up crashing.

if, as i believe, the precaches are not being cleared, then every map that adds any extra unique sounds will bring the crash that much closer to happening. 

The problem is often masked simply because practically every mod to date has
a) offered no means to import custom sound into a map and
b) contains fewer than 512 sounds itself

So it's likely a bug that has long survived in practically every source port of the engine... 

i'm certainly not blaming anyone for not noticing it. 

Is there any way to have glass in current engines? 

Quoth - make a func_wall, give it a texture called "skip" (Use newskip.exe after compiling), make a waterbrush in the same place as the func_wall, give it a water texture with a flat grey or white colour. Use a trigger_command to set "r_wateralpha 0.#" on mapload.

Cannot be done in vanilla progs without the player having to type a wateralpha value into the console. 

Will have breakable glass. func_breakaway FTW. 

On bmodels though. FitzQuake i think? Just set an "alpha" key on a func_wall - is the easiest way, and probably better than the water hack, because there is no waterwarp on a func_wall or other bmodel unless it has a water texture. GlQuake will do wateralpha, hence the water hack's universal compatibility. But you can have a nice glass texture is you use the alpha key.

RMQEngine
FitzQuake?
Darkplaces?
DirectQ? 

http://necros.slipgateconstruct.com/temp/split.jpg

i've mostly just ignored this kind of thing as down to the way bsp works... but is there any way to reduce or eliminate this seemingly needless poly splitting?
in the shot, the rock path is made up of 3 brushes per segment, the large center bit and the two small side bits, all 3 are split into tris. in theory, since none of the faces are larger than 240 in any direction, qbsp should have never split them at all, and just left them the way they were in the editor.
instead, you get that weird split in the center brush that runs up the slope until it meets the right-hand side where there are all these tiny little tris.

every compiler i've tried makes the exact same shape.
this is what it looks like in the editor, for reference:
http://necros.slipgateconstruct.com/temp/split_ed.jpg

am i just missing something? 

ok, in true necros fashion, i figured a little more out right after posting... -_-

it seems this has to do with how similar the planes are between those brushes. there's a setting in aguirre's txqbsp -epsilon that you can set to smaller to have more precision on identifying unique planes which reduces the unnecessary splits.
looks like if a plane is similar enough to another plane qbsp thinks they're the same plane(?) and tries to split it or somesuch.
unfortunately, even at smallest settings, it doesn't completely remove the extra splits. i think there must be a lower bound built into the compiler, since values smaller than 0.001 had no noticeable effect. 

.. you should directly contact aguirRe for this. He will certainly be really happy to help you ;)

It has indeed something to do with precision in clipping Hull (Hull 1 ?).. I've seen several test map compiled with different epsilon, and the lower it is, the better the rendering is (i.e smoother planes, less "corners").. though... it seems to not be valid for all maps..

Some quotes from aguirRe's TxQBSP readme file give a little bit more details


Improved handling of complex maps such terrain. This is done by increasing precision when identifying unique planes (faces) and modifying hull expansion logic. This reduces the risk of clipping errors and creates much smoother clipping hulls which can help player/monster movements.

All maps don't benefit from this, therefore two new options have been introduced; "-oldexpand" which just disables the new expansion logic and "-epsilon x" (default 0.01) which sets the plane identifying tolerance. To revert to previous compiler behaviour, just add options "-oldexpand" and "-epsilon 0.05".

The default settings have been chosen for overall best results. If you have a big map that still doesn't build correctly, you can try lowering the epsilon even more, e.g. 0.001. In most maps the default settings have little effect on # clipnodes, but some maps can see either a significant increase or decrease. Thanks to Tyrann for this one.

I hope it clarifies the stuff ;) 

you just cnped the text from his website. that's how i found out about -epsilon. :P 

... hence I suggested since the beginning of my post to directly contact aguirRe ;) 

If the -epsilon factor has to do with with monster/player clipping hull adjustment, then JPL's post makes sense. I think I now know why sometimes a player gets stuck on some brushwork ingame. It's sometimes not bad brush alignment, but maybe odd hull expansion the player gets caught up on. 

Personally I think what you're trying to do is overkill, to be completely honest. How many people are going to appreciate the little subleties of the corridor floor, especially when it's all plastered over by a low-res rock texture?

Maybe there's an easier way to get the same effect that uses less brushes and generates less splits.

Ideally you'd do this in a model editor and then import it into the map and fake collision somehow. 

You could make the floor-trim into a func_illusionary. This would make the floor a lot less complex, but there would be little or no visual difference because the floor trim cannot cast a shadow anyway. 

i experimented with -epsilon more and the original change i saw didn't have anything to do with it, but rather some change in geometry in another place that affected the spot i was looking at.

from what i can tell, -epsilon does absolutely nothing! i tried with settings of 0.5 and 0.0001 with absolutely no change in geometry.

i think the changes are very subtle and will only show up on a large, completed map.

hence I suggested since the beginning of my post to directly contact aguirRe ;)

yeah, i think i will now that i've had more time to look at it. :)

Personally I think what you're trying to do is overkill, to be completely honest. How many people are going to appreciate the little subleties of the corridor floor, especially when it's all plastered over by a low-res rock texture?

/shrug this is what i appreciate in maps, so it's natural that i'd do it in my own mapping process. subtleties, for me, is what makes a map great. if you walk up to a cliff and you see the edge has been beveled and there are chips taken out of it, that, to me, is far far more impressive than someone just making a flat cliff with a 1024x1024 texture. 

Is there a command to force VIS to cut off at a certain distance (which would be hidden by fog)? Can't find my copy of the tools readme :( 

hmap2 has -farplane 

tuna's fixed version of willem's modified version of aguirre's vis has -visdist #.

yeah, i totally just wanted to type out that line. ^_^ 

And everything seems to be going well except for the old "no textures in game" crap. Yes, I've got a worldspawn key for the texture wad, and I've put the damn wad in the id1 directory, the id1/tools directory (with the compile tools) and in the /id1/maps directory (with the maps) -- no dice. Any flashes of wisdom would be appreciated.