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 ;) 

I want an invisible player barrier that I can remove by a trigger. Is there such a thing?

Func_wall doesn't work witout a texture, so can't be invisible.

Is it there but I just can't see it? 

... with clip texture ?? I don't know if it works.. 

func_toggle_wall is for Quoth ;) 

Mike

Make your main wall out of clip brushes and then add a small cube with a real texture on it, embedded in the surrounding geometry or something. That should allow you to have a func_(whatever) that is effectively invisible. 

Err, in other words : No, you can't create a func_something made entirely of clip brushes. Trickery is required. 

You're not quite getting the problem which is leading to your original setup not working. Each info_sound_triggered entity has it's own set of 7 channels, playing a sound on channel 1 of the second play_sound_triggered doesn't stop the sound on channel 1 of the first, because those are different, distinct channels.

The reason behind this is obvious for players, which have a channel for weapon sounds, and a channel for pain noises. You wouldn't want the sound of player 2's rocket launcher to cancel out the sound of player 1's shotgun. However, you would want player 2's latest pain sound to cancel out the last one if it's still going. In any case, this is all done by the engine, it's fundamental.

There would be a way to do things in the manner you desire. The QC would create a single shared entity which would act as the "speaker" for all the info_sound_triggered entities, sounds would be played by that entity rather than the info_sound_triggered itself. Then since it's always the same entity which owns the sounds, the channels are the same from info_sound_triggered to info_sound_triggered. However, I don't think this is the most intuitive way of setting up the entity, so I don't think it will get changed. Maybe this way can be added as a separate, new entity, but the existing one is behaving as intended, not a bug. 

How in the hell do I run a map without getting stuck at the waiting for players screen? All I want to do is run around with the scout in the official levels and get a proper feel for dimensions and stuff. 

Have you tried setting maxplayers to 1? I think that's what I did to make it work. 

Tried it. Did not work. 

I'm sure there's a way to disable it properly because I've gone running around exploring maps as scout. But I can't remember it, so use "mp_waitingforplayers_cancel 1" once you get into the game to start the round proper. 

That just ends the round in a draw. 

I don't mean to be that guy that answers questions by telling you your whole map is wrong, but what's the context where you need the player to be blocked by something he can't see? Is there an aesthetic/gameplay reason you can't bar his path with a cage or a door? Players won't be expecting clip brushes to disappear, because they don't do that ordinarily. 

Preach:
OK, if it is not a bug, it is that I didn't understand how it works... sorry for this :P Anyway, I achieved the sound effect I was looking for, and this is the most important for me :D


Lunaran:

It is not me, it is Mike Woodham who want such effect :P Check post #7877

This "transparent clip wall" effect has been used in Travail start map, where the shambler protects the nightmare skill entry: there is a kind of shield that isolate the shambler and prevent the player from shambler attacks, and that looks like a transparent clip wall.. but once disabled, the shambler can run after the player, and you can walk through the shambler "cage"... Good example of transparent xlip wall there ;)