I suppose this planemerging creates leaks in hull 1?
Instead of having visible gaps between brushes (hull 0 leak)? 

I always assumed .map stored verticies

SleepwalkrR: this doc explains Quark ETP:
http://quark.sourceforge.net/infobase/src.topics.face.html 

On the contrary, the planemerging fixes leaks! At least that's the intent, it's meant to merge two adjacent brushes where some kind of rounding error occurs*. Of course, it can sometimes cause more problems that it solves if it starts affecting brushes further afield. I'd have thought it would affect hull 0 primarily; if there's no leak in hull 0 then the expansion of the brushes for the other hulls should overwhelm any chance plane merging has of creating a leak there.

* Rounding error is a constant worry, even with the best case integer coordinates. Imagine two adjacent brushes formed from a diagonal cut along a single brush. The editor has even been so good as to make sure the touching faces are defined by the same three integer-snapped points. Even so, because the two faces point in opposite directions, the order that these points are listed is reversed. This is enough to produce slightly different floating point plane values some of the time. 

Here are 3 brushes, all the same size and in the exact same space.

{
"classname" "worldspawn"
"wad" "quake101.wad"
{
//"0000" "0"
( 128 0 0 ) ( 128 1 0 ) ( 128 0 1 ) COMP1_3 0 0 0 1.0 1.0
( 0 384 0 ) ( 1 384 0 ) ( 0 384 1 ) COMP1_4 0 0 0 1.0 1.0
( 256 0 0 ) ( 256 0 1 ) ( 256 1 0 ) COMP1_5 0 0 0 1.0 1.0
( 0 128 0 ) ( 0 128 1 ) ( 1 128 0 ) COMP1_6 0 0 0 1.0 1.0
( 0 0 128 ) ( 0 1 128 ) ( 1 0 128 ) AFLOOR1_8 0 0 0 1.0 1.0
( 0 0 64 ) ( 1 0 64 ) ( 0 1 64 ) CEILING1_3 0 0 0 1.0 1.0
}
{
//"0000" "0"
( 128 256 128 ) ( 128 128 128 ) ( 128 128 96 ) COMP1_3 0 0 0 1.0 1.0
( 256 384 128 ) ( 128 384 128 ) ( 128 384 96 ) COMP1_4 0 0 0 1.0 1.0
( 256 128 128 ) ( 256 256 128 ) ( 256 256 96 ) COMP1_5 0 0 0 1.0 1.0
( 128 128 128 ) ( 256 128 128 ) ( 256 128 96 ) COMP1_6 0 0 0 1.0 1.0
( 128 128 128 ) ( 128 256 128 ) ( 256 256 128 ) AFLOOR1_3 0 0 0 1.0 1.0
( 256 256 64 ) ( 128 256 64 ) ( 128 128 64 ) CEILING5 0 0 0 1.0 1.0
}
{
//"0000" "0"
( 128 160 128 ) ( 128 128 128 ) ( 128 128 64 ) COMP1_3 0 0 0 1.0 1.0
( 272 384 128 ) ( 144 384 128 ) ( 144 384 64 ) COMP1_4 0 0 0 1.0 1.0
( 256 128 128 ) ( 256 160 128 ) ( 256 160 64 ) COMP1_5 0 0 0 1.0 1.0
( 128 128 128 ) ( 256 128 128 ) ( 256 128 64 ) COMP1_6 0 0 0 1.0 1.0
( 128 128 128 ) ( 128 160 128 ) ( 256 160 128 ) AFLOOR3_1 0 0 0 1.0 1.0
( 256 160 64 ) ( 128 160 64 ) ( 128 128 64 ) CEILING4 0 0 0 1.0 1.0
}
}
{
//"0000"
"angle" "270"
"classname" "info_player_start"
"origin" "192 256 192"
}

My point, eh I don't got one yet. 

is there a sound-emitting texture manifested in Rubicon2s progs.dat?

I�ve got an annoying watersplashsound all over my map, and i�m using the animated waterfall texture.

This drives me mad, maybe fullvis gets rid of this? 

On your vis command line:


-noambientsky
Disable ambient sound generation for textures with names begin-
ning with 'SKY'.

-noambientwater
Disable ambient sound generation for textures with names begin-
ning with '*WATER' or '*04WATER'.

-noambientslime
Disable ambient sound generation for textures with names begin-
ning with '*SLIME'.

-noambientlava
Disable ambient sound generation for textures with names begin-
ning with '*LAVA'.

-noambient
Disable all ambient sound generation.
 

Or do i have to set up triggers for them instead then? 

that is quite nice. I'm sure some mods have support for external sounds, maybe quoth? 

Those only affect sounds added automatically by the vis process, produced by textures.

All your ambient_whatever entities will still work fine.

We already have several custom sound ents; this is for the RRP project.

You can use the ambient_general for a looping ambient sound, the only restriction being that it needs to have 'loop' data setup.

the fx_sound is for single shot sounds, although it also has replay capability. 

Thanks Ijed! 

there shouldn't be any automatically generated sound from the waterfall. Aside from the vis.exe-generated ambient sounds, there are of course mapper-placed ambients.

The only special rubicon2 code in this regard is, there is an underwater loop that plays whenever the player is underwater. If you are not underwater you should not hear it. (There is also a loop for when you are on fire.) 

I got it fixed with the -noambient switches, ambient_general "survives" this. Still curious where it came from then.
It was one of the curnt.wavs, i�m sure.
Ijed? 

can those ambient_generals be triggered?
Starting off? 

i believe they can't be triggered, they are implemented the same way as other ambient_* entities which means they spawn a static sound that gets sent to the client on connection.

With quakec changes it might be possible? I haven't looked at the code in several years. 

oh but... there are some technical issues with triggering looping sounds. The engine won't play the sound if the player is outside the range of the sound at the moment that it is activated. If this happens, the player will NEVER hear the sound until it is retriggered, and then the same range check applies. This is a huge problem and if you look at my steam traps, there is a lot of hacking to make the sound trigger continuously right around the outer threshold of the sound. At that time its' quiet enough that you won't hear it clipping/popping, and it mostly guarantees you will hear the sound when you walk closer. 

The engine is doing the range-check, so any triggered sound is muted for the player when he�s out of "reach"?

Basically the mapper would have to make sure that the player is "reached" by the sound when activated, if i get it right?

Having looked at the setup you made in rub2m2,
that�s a workaround yeah, and btw those maps are fantastic (i mean not only playin them, but looking at them in an editor). Those hollow torus brushwork amazes me with its flawlessness:)

Enough praise given!

Thanks for your quick response! 

correct, player needs to be in range for the sound to play.

Oh and also: the sound won't restart if you save and load the game. There was another hack i had to do to restart sounds condtionally, when a savegame is loaded. 

True, _ambient code can't do much in this respect, but the fx_sound is a bit more flexible.

You can set it to play a sound every x seconds, so if you set it to play an ambient sound, that isn't looped (but sounds as if it is) then you can kill the entity and the sound will stop playing. Same works for starting the sound.

Fx_ will start replaying after a reload! but only if you've got your triggers very carefully set up. I always thought the trigger_always of q2 was a clever hack. 

this was the solution i came up with for looping sounds that are started out of ear-shot: http://pastebin.com/0xpehM8C

maybe it'll be useful to someone. 

That'd be truly looping, clever stuff.

The fx_sound will have a few seconds of silence from some save game reloads! depending on how long your sound file is. 

 

I'd like to know which version of Radiant works best for Quake. Also links to the better tutorials on using it may help. I tried using it several years ago and I found it difficult to even get basic stuff done so I haven't looked at it since. 

Trenchbroom? 

NetRadiant, imo. Or, if you want to use detached editing windows, the latest build of GtkRadiant 1.5 (=26 April 2007). Some people prefer 1.4 or earlier versions. 

Is there a way to update the textures in a bsp from a wad?