in any case this sounds very interesting :) 

Thanks a lot for all these good advices. I now have to build the mod for this, and start the map.. I have a rough idea about what I'll do, but nothing clear today... And if it gives idea to other mappers, it is even better ;)
Again, thanks a lot for your support :) 

S_FindName: out of sfx_t
at map loading.

o_O 

Apparently means that you've tried to precache too many sound effects. The limit is 512, which is twice as generous as for models. You have some lengthy conversations going on? 

thanks :)

how do you find out these error meanings? are you actually looking through the source? 

is that fitzquake? Seems like it should handle that more gracefully. I.e. if you haven't exceeded max_sounds, it shouldn't fail in other ways. 

well, it was quakespasm085.4
i'll try to remember to test it in fq085 tommorow. 

Yeah, it's often easier to google the error and find a result in a quake engine svn directory. This time it was easier because it's an error people used to run into in Sven Co-op. 

i guess i should try the self help a bit more eh? :P

it was just such a strange error that i kind of laughed and just posted it.

thanks! 

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