1/ when sound 1 is triggered, but the player cannot hear it as too far away (at the beginning of the map, as the player shall enter a base to hear it), then sound 1 is not played, or cannot be heared, not even when close to the source. Pushing the button allows sound 2 to be played as expected

this is a limitation of the quake engine. only looping sounds set up at map spawn time will play properly. looping sounds that are out of the player's range will be cleared from memory.

the only way to do it is to make the looping sound loop manually with play_sound_triggered, setting the toggled flag and setting the 'wait' to the appropriate duration.

as for func_hordespawn/info_multispawn
i believe the monsters spawning awake feature of the entity is broken in quoth2.
you are supposed to be able to set the 'awake' key to '1' and make monsters go after you. 

The awake key doesn't work, even though it is advertised, but lardarse is correct that setting SPAWN_ANGRY on the info_multispawn or info_groupspawn will pass that flag on to any monsters spawned. Probably the forthcoming fix to the awake key will be to apply the same effect as the spawnflag, so give it a go.

I should warn now that there is a subtle bug with the info_multispawn and this spawnflag: it looks for the "activator" at the time of spawning the monster when deciding who to get mad at. The problem is there can be a delay between the activation of an info_multispawn and the actual spawning of the monster(why else would you use one over the teleport spawnflag?). The "activator" might change in that time, in which case the monster could end up mad at the wrong player, or not at all if activator isn't a player. info_groupspawn should be safe from this, and it will be fixed in the next release. 

Thanks a lot for the infos: I'll give a try this morning to:

Sound as necros described... and if does not work, I could simply change the effect.. not a big deal :P

Func_hordespawn: well if not possible to make monsters anger easily (i.e at least for those that need to, and not all spawned monsters), I will simply remove it and replace it by normal triggered monsters.

Thanks men: you rock ;) 

The spawnflag goes on the info_groupspawn(which is the new name for a func_hordespawn), so you can do it selectively - only on the ones for which need awake monsters. So what you would like to do is possible, the bug I described doesn't apply to what you want to do. 

I tested the wait field in play_sound_triggered, and it worked well. I had to remove loop indicator in the .wav sound to make it properly. Well, the result is quite acceptable, while there is a small sound break (around a 10th of a second) when the sound is triggerd again, and sthen restarted... maybe an engine issue... :/

BUT, it is not yet possible to stop it with another signal that overrides it onto the same channel, I guess it is a Quoth issue there...

So I removed the wait field, and added a trigger_delay that loops on the initial trigger with the exact sound duration for the delay field, enabling the sound loop as it triggers again the play_sound_trigger.
Using a button push, it allowed me to kill the trigger_delay, then breaking the loop: as a result the second sound can be heared: done !!!

Don't know if it is clear :P

Well, I still have some minor improvement to add in order avoid some sound glitches, but at least it works ;)

Still have to work on spawning ;)

Thanks a lot for the help provided :D 

How do you avoid this:
http://gaetm.free.fr/3d/2008/UnearthlyChallenge/VC_Pb.jpg

The vertex light fucks up between 2 ground meshes, works better with lightmaps, but I'd rather be using vertex light. The actual vertices are all overlapped fine etc, can bake vertex light perfectly in maya/max... Any idea? 

Are those all static meshes? One thing to try would be to turn off shadow casting on the ground meshes since they won't be shadowing anything anyway. That will stop their corners from turning dark. 

And the sidewalks as well. That's probably what's boning you. 

Yeah they are all static meshes, thanks I'll try tonight! 

the reason play_sound_triggered isn't stopping the sound when triggered again is because you haven't set the sound channel.

the default for that entity is to use channel 0. channel 0 basically tells quake to use whatever channel is available to play a sound.

the way the entity stops a sound playing is it plays a 'silent' sound on the same channel, but if the channel is set to 0, then the engine just chooses another channel instead of cutting off the one already playing. to get it to work, you need to set the 'impulse' key to a value between 1 and 7 (inclusive). 

I did it, but it does not work, I'm pretty sure I'm missing something

Nevermind: as I already exceed some standard limits in this map (clipnodes, max marksurface, max visible leaf, max faces), I will certainely exceed edicts as well, so unfortunately, I think I will not save that much there...

Anyway, I'll give it a try with a test map ;) and thanks a lot for the support. 

Is it possible to create a new monster skins without creating a whole new PAK file? Can you simply throw them into a directory structure of some sort and have Quake use them? I'm guessing not since the textures for the standard creatures are embedded inside the MDL files but I figured I'd ask. 

textures without .mdls or .mdls without .paks?

You can have stuff loose no problem, but AFAIK skins must be inside a model unless they are external skins - high rez or some such.

But that means the mapper can't turn them on or off, they're always on, or they're not, engine side. 

Right, sorry. So skins must be contained inside of an MDL, but the MDL files can be loose. Is that correct? 

the way quake searches for things is:

1. mod pakfiles
2. mod loose files
3. id1 pakfiles
4. id1 loose files

so you can't override files in #3 by putting them in #4, but you can if you put them in #2. 

If you're running with -hipnotic or -rogue in the command line, the pak files and loose files from the hipnotic or rogue directory are also searched, not sure when, but I'd guess in-between the mod and id1 step. This caused the missing sounds in quoth2, it was very annoying. 

I always thought a loose file would override a file in the pak. Wouldn't it be 2143 rather? With the engine "override" starting on the right and overriding everything from there that comes in the steps to the left.

Are engines that "allow replacement stuff" rewritten for this? (This is no stupid sarcasm in case you are wrong, I am genuinely interested in this). 

this search pattern only applies to multiple files with the same exact filename. So if you want soldier.mdl to override another soldier.mdl, you need to be aware of that search order.

If you have soldier_mdl_skin0.tga, that is going to override the soldier.mdl skin no matter what location the .tga is in, as long as there isn't already a soldier_mdl_skin0.tga located earlier in the search list. 

Sound issue is solved. Actually I think the issue came from a kind of synchronization that was required between the sounds to play (i.e when sound 1 stop, sound 2 has to start, as sound 1 was looped using wait field in pay_sound_triggered). I think the sound 1 was not overriden cause play_sound_trigger wait field forced a restart at some point, that overrided again sound 2, so the effect was not there.

I solved it using trigger_relays, creating my loop there, killing the main trigger relay when button is pushed.

Anyway, thanks a lot for all the help you provided ;) 

i think i misunderstood the first time.

you mean you were trying to get sound 1 to be overridden by sound 2?

yeah, that's not possible. :( the sound channel you specify in the 'impulse' field means the sound channel on that specific entity. if you had two play_sound_triggered, one wouldn't override the other because multiple entities can play sounds on the same channel.

it's an idea though, to expand the sound playing entity to incorporate functionality which uses more than one sound. 

Hence my idea to create a loop with 2 trigger_relays (very old method for loop creation :) ) and use button's killtarget function in order to stop sound 1 to be repeated (killing one trigger_relay), and at the same time triggering sound 2.

Actually, the overlap is possible if you rework the both sounds:
- sound 1 needs to be a looped sound, but you have to remove the loop markers, otherwize it will never stop
- sound 2 is reworked adding sound 1 + sound 2 as a result, but it delays sound 2 effect...

Also, you need to repeat sound 1 faster than its duration (for sound 1 looping) and then you can stop sound 1 without fearing any sound break during "sound 1 stop to sound 2 start" transition.

I also think a good idea would be to make ambient_generalpurpose sound switchable: it would have helped me a lot there :D

Anyway, thanks for the support ;) 

you shouldn't need to killtarget a relay though.

play_sound_triggered still does have the ability to stop a looping sound from playing. as long as impulse is set, if a play_sound_triggered (with the toggle flag on) is triggered again, the sound will be stopped.


also ambient_generalpurpose: that's not a bad idea, but i'm not sure if that will work or not.
the reason has to do with why ambient sounds with that entity (and all other ambient ents) play correctly looped while a looped sound started with play_sound_xxxx does not.

the function used to set up an ambient sound is different from the function to set up a regular sound (play_sound, monster noises, guns, etc). the ambient sound function can ONLY be used at map start. in fact, i'm not even sure if the ambient sound is tied to the entity at all.. could someone try killtargetting an ambient_sound entity? 

been meaning to ask about these... are they possible with code modifications? Wrong thread, I know... 

That trick doesn't work, the sound lives on. 

I set same channel on both play_sound_triggered, but when sound 2 is trigger, it does not override sound 1, so it does not work actually, hence the trick I had to build with the trigger_relays, and explained in #7872.

I also tried to killtarget an ambient_generalpurpose, and a play_sound_trigger, but unfortunately it does not work neither...

I think there's maybe a small bug there, but nothing impossible to solve by other way ;)