Flag a speaker as an ambient?

[Sotha]

TDM has separate audio volume sliders for ambient and sound effects.

 

How do I tell TDM that this specific speaker should be an ambient sound and should be affected by the ambient volume slider?

[demagogue]

One way I know for sure you could do it is if the voice is playing on the location_settings like a location ambient, since it takes the volume directly from the ambient slider. I realize that playing an AI bark on a location ambient is illogical & probably buggy though, not that it couldn't be done.

The ambient slider might also work for certain audio channels, but IIRC I couldn't figure out which one (if any)... Worth experimenting with though... Maybe the music_channel, or maybe there's even an Ambient_Channel...

[Sotha]

The reason I'm interested is this:

 

Half-Life games have normally no music going on. At times a single music piece is played to emphasize the power of some scene the player witnesses. The silence between the music pieces makes you pay attention to the environmental sounds. Music in turn is aggressive power guitars for action scenes and sad moanful tunes for desolate corridors. I realized this is very stylish. The music is a nice spice and it is not overdone. It enhances the mood.

 

TDM location system based music makes the music loop. This means music gets repetetive and annoying very fast. It works poorly as a mood-creator. You can't change the music piece played suddenly to empower a scene.

 

I know I can easily make omni speakers in TDM and play music via that, but the problem is it is not controlled by the ambient volume slider. Thus if I go with HL style 'music empowers scenes occasionally' concept the player will not have any control over the volume of the music. This is bad and will ruin the idea.

 

Thus, I'm interested how TDM know what is ambient and what is not. Is it in the soundshader? Is it in the speaker? Or are only location system based ambients counted as real ambients for the volume slider? If so, the ambient wiki page speaker style ambients should be frowned upon as player cannot adjust the ambient volume at all.

[demagogue]

You may be interested to know the first iteration of the location ambients system I coded up worked all by scripts and in-game triggers (trigger brushes or buttons). The instructions are still up on the wiki now.* It's only later it got tied to the info_locations.

 

*Edit: Those instructions need some fixing and updating though; they were basically obsoleted so I didn't keep working on it to fix it up perfectly. They also have the problem that script-calls can't "pass self", something Tels fixed ages ago only for the team to strip it back out because it broke a unfortunately-designed FM puzzle... Fair enough but so unfortunate. We desperately need that ability(!), it's probably so easy to fix, but I don't know how to get it back now. Well anyway, the instructions on the wiki work at least.

 

So anyway, that original set-up would be ideal for the kind of HL like system you're talking about, where changes in music are triggered specifically by in-game events, anything that can trigger a script call. It basically works like a radio, and anything you want can trigger the radio-station change. Then you'd use basically the same script it had. And then, to tie it to the ambient-volume slider, you just take the same code that does it in the location_settings.script. It's all done in scripts, not sourcecode, so you could package it with your FM. I believe everything you mention in your post is quite do-able for an FM.

 

The only catch is that trigger-based ambient sounds can be a bit harder to control 100% than location_based ambients (which are more failsafe), e.g., because people can sometimes slip around trigger-brushes or the events mis-cue or something... It just means the mapper has to be extra careful to make sure all the triggers are cuing properly 100% of the time and the player won't break a trigger (whereas the location system is much more just "drop-in and go").

 

Edit2: To save you the trouble, here's the code you put in a script to set the volume of a speaker to the ambient-volume slider:

 

  // Tels: the location did not change, so see if the menu_volume changed
  // read out the current volume value from menu slider (0..1.0) and compare it to the last seen value
  // normalize -40 ..0 => 0 .. 1
  float new_music_volume = (sys.strToFloat( sys.getcvar("tdm_music_volume") ) + 40) / 40;
  // conversion decimal to decibels: decibels = (10 * log2(decimal#)), NB sys.log is in base-e, so divide answer by ln(2) = sys.log(2) = db_factor
  // conversion decibel to decimal: decimal = 2^(decibels/10)
  // conversion method: convert "volume" spawnarg decibel to decimal, multiply by slider cvar decimal, convert result to decibel for fadeSound
  if (music_volume != new_music_volume)
  {
  float fadeInVolumeNow = locEnt.getFloatKey( "volume" );
// DEBUG
// sys.println ("tdm_music_volume changed from " + music_volume + " to " + new_music_volume + " for current ambient volume " + fadeInVolumeNow);
// save new value
volumeFactor = (fadeInVolumeNow/10);
fadeInVolumeNow = sys.pow( 2, volumeFactor );  // convert spawnarg to decimal
music_volume = new_music_volume;
// multiply music_volume slider (0..1) by fadeInVolumeNow spawnarg (0..1)
fadeInVolumeNow *= music_volume;
volumeFactor = fadeInVolumeNow * 100; // For the console message
if ( fadeInVolumeNow < .015625 ) // This is the lowest boundary of volume, to avoid log() going to -infinity
 {
  fadeInVolumeNow = .015625;
  volumeFactor = 0; // For the console message
 }
fadeInVolumeNow = sys.log(fadeInVolumeNow) * db_factor; // convert to decibels
// yes it changed, so fade to the new volume rather quickly
fadeSound( channel2, fadeInVolumeNow, 0.01 );
sys.println ("The ambient volume is now " + fadeInVolumeNow + " decibels (range: -60..0), i.e., " + volumeFactor + "% of full volume.");
  }

[Sotha]

The instructions are still up on the wiki now.* It's only later it got tied to the info_locations.

 

Urk.. If getting stuff play on the ambient channel requires that kind of scripting and the other way involves just placement of an omni speaker and a trigger, screw player control over ambient volume levels..

 

Despite that sentiment, I'll have a look at the location_setting script. If I could make a script thingy like this:

void playsong1 ()

{

Play song1 in the ambient channel and then stop

}

 

Then it would be doable. Trigger placement is not an issue: I could even use the location settings to fire a trigger_once that executes the script for the music...

 

Edit2: To save you the trouble, here's the code you put in a script to set the volume of a speaker to the ambient-volume slider:

 

Oh, thanks a lot!

[demagogue]

Trigger placement is not an issue: I could even use the location settings to fire a trigger_once that executes the script for the music...

 

It's even easier than that. The location_settings can call a script "on entry" directly. Then your little script could act just like a location ambient, except you can change the radio station for arbitrary events like AI proximity too, and get the best of all both worlds. Great idea.

 

For that ambient-volume code, the only thing to keep in mind is you have to either call up the script whenever the volume is changed & kill itself, or you'd just have to have the script perpetually running so it makes its own check every second or so (what the location ambient system does).

[demagogue]

Thinking aloud, there's another thing you could do.

 

You could copy/paste a replacement location_settings.script in your FM .pk4 that just replaces the TDM one. Hear me out... Then you could tweak only one line, where it gets the "current ambient to play" not from the "location I'm in" but from, e.g., a simple "getKey" of a property on a dummy object (and if that property is null, then it could even revert to the location-ambient if you made a simple If/Then check), something like "force_ambient".

 

Then when you want to change the ambient, all you have to do is have some simple script that "setKey's" that property, triggered by anything you want, or sets it back to null when you want the location ambient to start back up. Then you get all the advantage of the existing ambient system, the nice fades from one ambient to the next, the ambient volume control, etc, and still get to do what you want, force ambients by arbitrary events.

 

BTW, that's such a good idea, I'm thinking about coding it myself for 1.09 (it'd seriously just be 1 or 2 lines tops), so people can have their own ambient changes by trigger in just the way I explained (they setKey a property to the new ambient they want to force; otherwise it reverts back to the location ambient).

[Sotha]

That is very cool!

 

If I happen to have something requiring this before 1.09, I'll contact you. If you happen to have the thingy ready at that time, we can package it with the FM itself and we get to see how it works out before 1.09 rolls out with it.

[Tels]

I'd say its better to enhance the current location script to have callbacks that say basically "something happened, please play this ambient music here once (or twice in a row etc), then fall back to what is current".

 

Then the mapper can just place triggers with "callobjectFunction" and make it call "forceAmbient()" on the location entity.

 

(In a similiar idea,I'd also like the ability to have random ambient sounds thrown in, so that there can be things like drips, creeks etc that happen at irregular intervals around the player. Right now its one music, or another, but nothing random).

[demagogue]

I'd say its better to enhance the current location script to have callbacks that say basically "something happened, please play this ambient music here once (or twice in a row etc), then fall back to what is current".

 

Yes that's what I was thinking about, except I'd open up how long it plays before it goes back to current, so they the mapper can have another trigger for the "event is over" to transition back (e.g., when the guards don't see them anymore or an AI is KOd or killed), and if they don't specify that then it defaults to something like play once, or they can set how long it plays directly (like in seconds or loops or whatever). It's all variations on the same simple theme.

[Tels]

Yes that's what I was thinking about, except I'd open up how long it plays before it goes back to current, so they the mapper can have another trigger for the "event is over" to transition back (e.g., when the guards don't see them anymore or an AI is KOd or killed), and if they don't specify that then it defaults to something like play once, or they can set how long it plays directly (like in seconds or loops or whatever). It's all variations on the same simple theme.

 

Yep, sounds good.