Thanks, metlslime. With that information Dietz should be able to get everything working 100% now.

bascule: Try it. I just did. I get the same error message that Dietz gets. 

that's the thing i said didn't work. 

Okay, so in Q1 I want this key door to play doors/baseuse.wav when the player has the key and touches it. When "sounds" is set to "2" on the door, baseuse.wav does not play; however, when it's set to "5" baseuse.wav does play. Of course, it also complains about the sound files not being precached because there is no corresponding set of .wavs for that sounds number.

If I play some trickery on Quake and set "noise1" to "doors/baseuse.wav" and "noise2" to "misc/null.wav" then the sound plays, but only after the door has stopped moving. This feels odd and is not the desired effect.

Any ideas on how to get this working how I want? 

in the id progs.dat where it tries to play both the door open sound AND the door unlock sound on the same channel, thereby cancelling one out.

If you don't want do include new progs.dat, try this hack: make another func_door hidden in the wall or something, and have it open at the same time. the locked door will play the unlock sound, and the hidden door will play the open sound. 

Thanks to metlslime and czg for helping me out with this. If any of you want the solution, here is the info:

"classname" "func_door"
"sounds" "5"
"noise2" "misc/null.wav"
"noise1" "misc/null.wav"
"angle" "270"
"target" "goldkeydoor"
"wait" "-1"
"spawnflags" "8"

"classname" "info_notnull"
"use" "train_wait"
"sounds" "1"
"noise" "doors/baseuse.wav"
"wait" "-1"
"targetname" "goldkeydoor"

This creates a func_door that requires the goldkey, and plays no sounds when opened. It targets the info_notnull which plays the baseuse.wav. 

<czg> RPG, you could just have set the doors "sounds" to 0, then you don't have to set the noise fields yourself

Yes. So, if "sounds" "0" is used in the func_door, then you don't need to set the "noise1" or "noise2".

Just an FYI if anyone here is trying to use this. 

cool, thanks. That is very helpful! No im not being sarcastic :) 

Do func_trains in Q1 not like "wait" values that are decimals? It doesn't wait at a path_corner when I set "wait" to ".25". 

Why would you want it to wait .25 instead of 1? :) 

Because I have three func_trains. They all move together at 64 units/second to form a single structure. I want one of the trains to pause while the other two trains move 16 units in opposite directions, and then I want them to all start moving again in sync.

d/r = t. 16/64 = .25 seconds to pause.

And since the trains move about 384 units before coming to this spot, I don't want all of them to move at 16 units/second because then the player would have time to shit, shower, shave, and do whatever else they wanted before the train got to the final destination. 

"because then the player would have time to shit, shower, shave, and do whatever else they wanted before the train got to the final destination." 

I set "wait" "1.5" and it actually waited one and a half seconds at the path_corner. I still want to know why "wait" ".25" (or "0.25" for that matter) doesn't work on func_trains. 

Try using 0.2. Just for a laff. 

does the q1 entity/whatever file gtkrad uses have 'wait' as an integer value? if so, maybe its getting sliced to 0 somehow? probably not, but worth checking out i guess. (more likely a quake thing though) 

Okay...

Partly influenced by Kell, partly influenced by SPoG, and partly on a lark, I set "wait" ".5" and it waits the perfect amount of time and everything is in sync. This makes no sense to me, because the main bit is only supposed to wait while the other two bits move 16 units at 64 units/second. Unless all trains automatically pause 0.25 seconds at each path_corner, this is beyond my comprehension.

But hey, it works. I'm happy. Sort of. Now I don't have an excuse for czg as to why I haven't released the map. 

release the map!

make sure its hard though :D 

If a wait is set for the corner, the train will wait for exactly� that time. If the wait is not set, or the wait is zero (they're the same thing), it'll wait for 0.1 seconds.

�: I think. check sv_phys.c in the engine. 

 

Can anybody who's using TreeQBSP or WQBSP please clarify when you use the options "-oldaxis" or "-alternateaxis" for correct texture alignment of 45 degree brushes?

It's my impression that people who are using WorldCraft must use one of these options all the time although compiler documentation tells the opposite. What gives? 

download valve hammer and use dubsp, it makes texturing and aligning SO MUCH EASIER! :) 

I use QERadiant and always use -oldaxis or -alternatexis. I remember from the time that I was helping Killjoy finish KJSP1 that if he used -alternateaxis on WQBSP that the texture alignment was off. He was using WC1.6. 

All Quake textures are aligned to the nearest of the xy, yz, or xz planes. However, WC gets confused with 45� angles and sometimes aligns the tex along the wrong plane.

I'm not sure I've explained that correctly, but all you need is -alternateaxis to make stuff line up. 

WC gets confused with 45� angles

Oh gods, I remember that :/ IIRC though, it only happens on one plane - so if you have a pyramid whos sides slope at 45 degrees, two flanks will look right, two won't. Or something. 

Cant you just simply rotate it 90 degrees? 

input. If I understand correctly, normally (except in the case RPG mentioned) these options should be used to get [45 degree] textures to align properly.

Then, why are these options there? In what case is the (new?) default texture axis handling better? Is there an editor where the default axis handling makes sense?

The "old" (or "alternate") axis handling is the same as in TxQBSP (which only has one variant) and also the same as in the original qbsp from iD.

Why are there repeated claims that this "old" axis handling is invalid for WorldCraft? It really doesn't make sense.

I've tested on several WorldCraft maps and they all get correct texture alignment only if I use the options above (with Tree/WQBSP). Using TxQBSP it's always right.

Another funny thing is when using YQBSP (Yahn Bernier's), there is yet another option "-alt45" which works completely opposite of the "-alternateaxis" option in WQBSP. I.e. running without this option seems to work great for WorldCraft maps. Confusing to say the least ...

It appears to me that I should consider removing the "-oldaxis" option from TreeQBSP and make it default instead. Would that be wise?