Player voice-over spawnarg?

[Springheel]

What's the spawnarg you add to a speaker to designate it as the player's internal voice?

[Sotha]

You use atdm::voice. I cant remeber the setup, but you can check LQD .map. the voice setup is in the chasm in the starting area.

 

IIRC, you have have a single voice speaker entity, which you target with entities that define the lines that the speaker entity should emit.

[Springheel]

I was able to find a little about that entity in the wiki:

 

How to use:

1. Place an atdm:voice entity in your map (location does not matter, and you need only one)
2. Place multiple atdm:voice_trigger entities in your map
3. link your atdm:voice_trigger entities to your atdm:voice entity (CTRL+K in DarkRadiant)

Give the following spawnargs to the atdm:voice_trigger entities:

"snd_say"    "sound_you_want_to_play"                       // generic, male or female"as_player"  "1"                                            // if the player should say things"as_player"  "0"                                            // if the speaker (from off) should say things

The difference between "as_player" "0" and "1" is the volume as set in the menu.

 

 

I have no idea what the difference between "as_player" 1 and 0 is though. "If the speaker (from off) should say things" What does that mean? Is it just the difference between having the sound affected by the Player menu slider or not?

 

edit: What a weird setup. So you need a trigger that targets a atdm:trigger_voice that targets a atdm:voice...? What's the point of having a third entity in that chain?

 

If I want to change the volume, does that spawnarg go on the atdm:trigger_voice or the atdm:voice?

[SteveL]

I have no idea what the difference between "as_player" 1 and 0 is though. "If the speaker (from off) should say things" What does that mean? Is it just the difference between having the sound affected by the Player menu slider or not?

Yes, apparently, according to the notes in tdm_voice.script, that spawnarg controls which menu setting controls the volume: player voice volume or ambient volume.

[Springheel]

Seems odd, given that the whole point of that entity is to create player voices.

[Sotha]

I think I changed the line volumes in the soundshader declaration.

[SteveL]

You can almost certainly tweak the volume on the atdm:voice entity too.

 

atdm:voice is just the standard speaker entity with s_global and s_omni set to 1, and with a default s_volume of 60.

 

Edit: Oh, and with a script object too, which I guess is kind of important to its behaviour

 

 

 

entityDef atdm:voice

{

"editor_displayFolder" "Sound"

"inherit" "speaker"

"scriptObject" "tdm_voice"

 

"s_looping" "0" // does not loop

"s_global" "1" // is a global speaker

"s_music" "0" // is not music

"s_volume" "60"

"s_omni" "1" // omnidirectional

 

"editor_usage" "Place one in your level, then link it from any 'atdm:trigger_voice' (under Targets) entity."

"nodraw" "1"

"solid" "0"

 

"editor_color" "1 0.5 1"

"editor_mins" "-4 -4 -4"

"editor_maxs" "4 4 4"

}

 

 

 

edit2: the script object ignores the spawnarg. It uses the game menu slider level plus the sound level in the shader. Maybe the game takes account of the s_volume spawnarg and maybe not, I can't tell just from reading the code.

Edited October 10, 2015 by SteveL

[grayman]

After re-reading the script object code, here are my thoughts:

 

The object handles two modes: a player voice and a narrator voice ("from-off"). I'm not sure what "from-off" means other than possibly "from offstage". I never got a clear explanation as to why we needed two modes to essentially play a voice that appears to come from the player.

 

The "as_player" "1" mode plays the sound on channel SND_CHANNEL_VOICE. This lets it play along with any global ambient sounds that are playing (like background music).

 

The "as_player" "0" mode plays the sound on channel SND_CHANNEL_BODY3. This lets it play along with any global ambient sounds, and also along with any sounds playing on SND_CHANNEL_VOICE.

 

Since there are two modes, there are two volume sliders on the menu page. The "player" slider adjusts the sound volume on SND_CHANNEL_VOICE and the "narrator" slider adjusts the sound volume on SND_CHANNEL_BODY3. Volume is adjusted by adding the slider value to the volume setting in the sound. The sliders are set up so that if they're slid to the left, volume goes to zero, and if slid to the right, you get the volume setting in the sound.

 

The question left unanswered is: why have two voiceovers? Since you can play any sound you want (it doesn't have to be a human voice), perhaps this allows the player to say witty things using "as_player" "1", and emit other sounds at the same time using "as_player" "0". Why the latter is termed "narrator" is beyond me. IIRC, Tels might have said that's what it should be called.

 

 

[grayman]

edit2: the script object ignores the spawnarg. It uses the game menu slider level plus the sound level in the shader. Maybe the game takes account of the s_volume spawnarg and maybe not, I can't tell just from reading the code.

 

The script object ignores the s_volume spawnarg. It uses the volume in the sound shader.

[Destined]

Maybe the two modes were designed as an "inner" voice (narrator) and an actual conversational voice for dialogues with AI. So I would assume, that AI react to the "as_player" "1" sounds, as the player actually emits the sound, while the "as_player" "0" are just thoughts and thus not noticeable by AI. That would at least be an explanation that makes sense to me, as to why you need this setup.

[grayman]

Maybe the two modes were designed as an "inner" voice (narrator) and an actual conversational voice for dialogues with AI. So I would assume, that AI react to the "as_player" "1" sounds, as the player actually emits the sound, while the "as_player" "0" are just thoughts and thus not noticeable by AI. That would at least be an explanation that makes sense to me, as to why you need this setup.

 

This is a reasonable theory. For AI to react to a sound, however, there has to be a companion propagated sound defined for the emitted player sound, and I don't think anyone who's bothered to make player voice sounds has concerned themselves with this.

 

Also, the "as_player" "0" sounds are described in the script comments as being able to be played at the same time as "as_player" "1" sounds, and it doesn't make sense that the player would be talking to himself and talking out loud at the same time.

[Springheel]

The question left unanswered is: why have two voiceovers?

 

 

You're right, that makes no sense. You can't play two narrations at the same time, and you wouldn't use this method for a conversation, because each line has to be triggered separately.

 

You can already create narrative voices by just linking a regular speaker to a trigger and giving the speaker the qualites of "omni" and "global". The only benefit I can see to using the atdm:voice entity is so that the narrative speaker volume can be controlled by the main menu. It's actually MORE time consuming to set it up with a atdm:voice entity, since there are three entities involved instead of 2, so I'm not even sure the net benefit is worth it.

 

Isn't there a way to just designate a regular speaker entity as "this speaker is controlled by the Player volume slider on the main menu"?

[SteveL]

 

You're right, that makes no sense. You can't play two narrations at the same time, and you wouldn't use this method for a conversation, because each line has to be triggered separately.

 

You can already create narrative voices by just linking a regular speaker to a trigger and giving the speaker the qualites of "omni" and "global". The only benefit I can see to using the atdm:voice entity is so that the narrative speaker volume can be controlled by the main menu. It's actually MORE time consuming to set it up with a atdm:voice entity, since there are three entities involved instead of 2, so I'm not even sure the net benefit is worth it.

 

Isn't there a way to just designate a regular speaker entity as "this speaker is controlled by the Player volume slider on the main menu"?

 

I suspect there isn't a built-in way, but it could be done with one line of script at map start.

 

Or we could add a built-in way. Maybe add a spawnarg for speakers that lets them specify a cvar where they get their volume? Quick work if people think that's how it should work.

[Springheel]

Or we could add a built-in way. Maybe add a spawnarg for speakers that lets them specify a cvar where they get their volume? Quick work if people think that's how it should work.

 

 

That's how I expected it would work when I went looking for it. I can't see any reason for an entirely new entity unless that's the only way it's possible to do it. That's how all speakers should work IMO.

 

"narration" "1" = This sound is a voice-over heard in the player's head. Its volume is affected by the "Narrator Volume" option in the Sound Menu.

 

"ambient" "1" = This sound is non-directional ambient music. Its volume is affected by the "Ambient Volume" option in the Sound Menu.

 

If the spawnargs could also automatically set s_global and s_omni to 1, so much the better (though that should probably be already set in the soundshaders).

[SteveL]

I don't know anything about speaker set up so I'll wait for you or someone to tell me when there's been enough discussion I could add a "volume_cvar" spawnarg for all speakers in about 5 mins. It'd just override the default "s_volume" and still be overridden by special setups like atdm:voice's script object, so it wouldn't change the behabviour of any existing speakers.

[grayman]

Isn't there a way to just designate a regular speaker entity as "this speaker is controlled by the Player volume slider on the main menu"?

 

We already have a mechanism to play the player voiceover, and that's atdm::voice. 9 maps have used it so far. Why create another way to do it?

 

Just do these three steps and you're done, and we don't have to add more code:

 

1. Place atdm:voice in your map (location does not matter, and you need only one).

2. Place atdm:trigger_voice in your map, and give it the following spawnargs:

"snd_say" "sound_you_want_to_play"

"as_player" "1"

3. Then link your atdm:trigger_voice to your atdm:voice entity (CTRL-K in DarkRadiant)

[grayman]

I don't know anything about speaker set up so I'll wait for you or someone to tell me when there's been enough discussion I could add a "volume_cvar" spawnarg for all speakers in about 5 mins. It'd just override the default "s_volume" and still be overridden by special setups like atdm:voice's script object, so it wouldn't change the behabviour of any existing speakers.

 

What does this accomplish? Doesn't it make things more confusing?

[SteveL]

 

What does this accomplish? Doesn't it make things more confusing?

Possibly. I don't know. I'll wait to be told what to do.

[Springheel]

We already have a mechanism to play the player voiceover, and that's atdm::voice. 9 maps have used it so far. Why create another way to do it?

 

 

I just find the current system unnecessarily complicated.

 

The difference between player/narrator is completely unnecessary, as you pointed out. And this system requires 3 entities (1 regular trigger, 1 atdm:trigger_voice, 1 atdm:voice) rather than all other sounds that just require 2 (1 trigger, 1 speaker).

 

Having two simple spawnargs that get added to speakers to designate them as either ambient or narrator would be both simpler and more consistent. Yes, it would make the atdm:voice redundant, but it wouldn't affect any of the maps that currently use it.

[grayman]

And this system requires 3 entities (1 regular trigger, 1 atdm:trigger_voice, 1 atdm:voice) rather than all other sounds that just require 2 (1 trigger, 1 speaker).

 

 

If there are 20 witty sayings in the mission, using the current mechanism requires

 

20 triggers

20 atdm::voice_triggers

1 atdm::voice

 

So 41 entities.

 

With the proposed system, the requirement isn't much different:

 

20 triggers

20 speakers

 

So 40 entities.

 

Nut much gain there.

 

And how do you get the proposed system to play the sound on the player's VOICE channel?

[Springheel]

With the proposed system, the requirement isn't much different:

 

 

Except that you have to target every one of those voice_trigger entities to the voice entity, so you're creating 40 targets instead of 20.

 

Not that it's the end of the world, but this method seems to add extra clicking and extra spawnargs that don't seem to be necessary (it's quite possible they ARE necessary, but that's why I was asking).

 

I've already got working narrative sounds in my map with two entities and 1 target each...they do exactly what I want them to do, but it would be nice if the player had the option of controlling their volume separately (allowing him to turn them off if he doesn't want to hear them). Having to do the sounds an entirely different way just to get that functionality seems like an odd design choice to me, if we could accomplish the same thing with a simple spawnarg.

[grayman]

I don't find it to be an odd design choice. I'm guessing the designers wanted a way for the player to turn down background noises w/o affecting the player voice. A good example is Shadowhide's second map (I forget its name) where the voiceover was way too unbearably loud (at least for me) and he didn't use the atdm::voice method, so when I wanted to bring down the voiceover volume to a tolerable level, I lost all the other sounds. I don't think the atdm::voice method was available back then, and it wasn't until I made the volume sliders visible and got the existing scriptobject code to actually work that it became available.

 

If you want an alternate way of doing this, I guess that's fine, but given that you have to set extra spawnargs on the speakers (omni? global?), it's probably six of one / half dozen of the other as to which is easier to use or remember.

 

So, Steve, can you add the speaker code to access the cvar that provides the slider value? You can read how that value is used in the script object and apply the same method to the speaker code. You want the slider that gives you the "as_player" "1" behavior. Then we'll need a bugtracker issue to track the changes, and an addition to some wiki page that describes how you can use this alternate method of providing voiceovers. Thanks.

[Springheel]

I'm guessing the designers wanted a way for the player to turn down background noises w/o affecting the player voice

 

 

Well yes, that's the goal, but is an entirely new entity needed for that? There are 3 useful volume sliders (SFX, Ambient, and Player/Narrator). SFX is the default, and if the mapper wants a sound to be affected by one of the other two sliders, they put an appropriate spawnarg on the speaker. Done.

 

Anyway, I don't feel strongly enough about it to push if there's opposition to the idea.

[Tels]

After re-reading the script object code, here are my thoughts:

 

The object handles two modes: a player voice and a narrator voice ("from-off"). I'm not sure what "from-off" means other than possibly "from offstage". I never got a clear explanation as to why we needed two modes to essentially play a voice that appears to come from the player.

Yes, it means "from offstage", this was a typo (it's called "aus dem Off" in german. My mistake.

 

The reason why you have is two, is so you can have a narrator (a voice which does not belong to the player, but tells the story) and the player voice, which says witty lines.

 

These two need different sounds, so you need to have a setup for both and mix them two, without having to specify individual sound files and both can have their

own volume control. Some people might want to mute narrators, but not the player voice, and some might want to hear the narrator but never the player.

 

If both would be delivered over the same speaker, this would not work (or at least that was the reasoning back then).

[Tels]

Maybe the two modes were designed as an "inner" voice (narrator) and an actual conversational voice for dialogues with AI. So I would assume, that AI react to the "as_player" "1" sounds, as the player actually emits the sound, while the "as_player" "0" are just thoughts and thus not noticeable by AI. That would at least be an explanation that makes sense to me, as to why you need this setup.

Actually, the AI should not react to any of both sounds. Both are "inner voices". The narrator says something like "It was a dark and stormy night, and so our story begins." while the player says (to himself) "I love the dark and quiet nights" or "I'm afraid this would happen." etc.