Jump to content
The Dark Mod Forums

Player voice-over spawnarg?


Springheel

Recommended Posts

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.

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.

As far as I remember, there where specific reasons for the atdm:voice entity:

 

* it has a script object. You can't have a script object without an entity. And you cannot call procedures without a script object. So it becomes hard to trigger a speaker via scripting. (IIRC)

* the script object changes the voice for the player between male/female, depending on a CVAR (you cannot do this with a single speaker). That feature got somehow lost, because nobody seems to like it. Guess we are all male players here...)

* the trigger system and the "how to call a procedure" system also often need a target entity. Sure, you could target speakers (I forgot if there was another technical reason for not being able to target speakers), but the script object f.i. ensure that you never get two messages at the same time.

* with the atdm:voice entity you only need one entity with the script object - if you wanted the script object features, you would need to put one on each speaker, which could conflict with other script objects (one entity can have only one).

 

If the same setup can be achieved with a spawnarg, that might be fine. I forgot if the atmd:voice was added before we had access to the source code, so another reason might be that back then we simply couldn't modify speakers.

 

Hope that sheds a bit of light onto this setup.

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?

Wouldn't that be just 20 atdm:voice_triggers and 20 links? Why one extra trigger for each? *confused*

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Wouldn't that be just 20 atdm:voice_triggers and 20 links? Why one extra trigger for each? *confused*

 

Thanks the the explanation. That clears it up for me.

 

If you need to walk through a trigger brush to activate the voice_trigger entity, you need both to make it work. You can't touch the latter.

 

If you're targeting the voice_trigger entity some other way (like completing an objective), then you don't need the touchable brush trigger.

Link to comment
Share on other sites

Is there also a separate entity to designate sounds that you want controlled by the ambient volume slider?

Link to comment
Share on other sites

So we have 4 volume controls;

 

Menu item - internal code variable name (Darkmod.cfg) - what it controls

 

"SFX Volume" - s_volume - controls volume of sfx sounds like footsteps, door sounds, etc.

"Ambient Volume" - tdm_music_volume - controls volume of ambient background music and any speakers with a "set_music" "1" spawnarg.

"Player Voice Volume" - tdm_voice_player_volume - controls volume of player voice on atdm:voice entity ("as_player" "1")

"Narrator Volume" - tdm_voice_from_off_volume - controls volume of narrator voice on atdm:voice entity ("as_player" "0")

Link to comment
Share on other sites

Set "s_music" on a speaker and its volume is controlled by the "ambient volume" menu slider.

 

 

That makes sense to me.

 

I just expected the player voice would work that way as well, by adding a spawnarg. But if it can't because it uses scripts, then it can't.

Link to comment
Share on other sites

I would vote to change this. Making things easier for mappers is a worthy goal and will encourage more contribution.

That said, not fixing means that the same mapper might ask on the newbie thread and would get a lesson in entities, targets, and scripting.

 

I would lean towards "the easier it is to map the more mappers we would attract". (see Minecraft)

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

@grayman: you are right, I just looked again at the entity/script object setup.

 

@nbohr1more: I'd say if it is easier to use, go for it. (OTOH, having two ways to accomplish the same might be confusing).

 

Looking at the setup to avoid entities, to make any trigger trigger the atdm:voice entity, one would need a global script function and just add a "call" "thisglobalfunction" on each trigger. This would accomplish the "100 triggers, 1 atdm:voice" entity goal vs. "100 trigger, 100 speakers". But it would be "yet another alternative setup" that mappers need to learn.

 

Alternatively, an "s_voice" spawnarg on a speaker could modify it so that the code seeks out the atdm:voice entity and calls speak() on it. Then you could do away with the intermidiate target entity and only have triggers and speakers. Perhaps the most intuitive design for mappers. It would need some C code support, I think. Maybe just adding a script object to the speaker might suffice, but I need to research if this is possible.

 

The current setup (one trigger, one target per line to be said) is unfortunately a design decision back from id software - this way it is easier to visually see the setup in the editor and follow it. It does mean an excess amount of entities, tho.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Alternatively, an "s_voice" spawnarg on a speaker could modify it so that the code seeks out the atdm:voice entity and calls speak() on it. Then you could do away with the intermidiate target entity and only have triggers and speakers. Perhaps the most intuitive design for mappers. It would need some C code support, I think. Maybe just adding a script object to the speaker might suffice, but I need to research if this is possible.

 

 

 

Why is this simpler than what we have today?

 

today: multiple triggers->multiple voice_triggers(define witty sayings)->one voice

 

proposed: multiple triggers->multiple speakers(define witty sayings)->one voice

Link to comment
Share on other sites

 

Why is this simpler than what we have today?

 

today: multiple triggers->multiple voice_triggers(define witty sayings)->one voice

 

proposed: multiple triggers->multiple speakers(define witty sayings)->one voice

 

No, I meant:

 

multiple triggers->multiple speakers(define witty sayings and script object)

 

You don't need the single atdm:voice object. Even better would be:

 

multiple triggers(define witty sayings and script object)

 

Technically, the trigger itself could just play the sound. The only feature I can see you would lose would be the "no overlapping sounds". If that is important:

 

multiple triggers(define witty sayings and script object) plus atdm:voice (which does the central playing).

 

I'm looking into how to achive this with scripting. Should be technically possible with a "call global function trigger".

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Here is a first draft of how it can work:

 

http://swift-mazes.com/pub/voice_test.zip

 

The script object tdm_voice is modified to be attached to either the atdm:voice entity (which is a speaker in disguise), or a trigger. If attached to "not speaker",it will target itself (making it work with triggers), and also read the spawnargs:

 

* wait_before

* wait_after

* snd_play

 

It would be easily possible to also add a volume override, so single sounds can be player louder/not as loud as the default volume. Springheel, would that be something you'd use or find useful?

 

There are also two entities that show the feature: atdm:trigger_speak and atdm:trigger_speak_once

 

(atdm:trigger_voice is unfortunately very ill-named - mea culpa. Not sure if we could remove it?)

 

There is a small testmap that shows the feature, emitting "hms".

 

The crate shows that the triggers are "touch triggers", e.g. you can also trigger them by throwing the crate into them. This is a side-effect, the voice will be suppressed in this case. Since the testmap links the triggers to entities (lights, door), these will still be activated. That's a feature, if you do not want this, simple do not link these triggers to something, instead create a second trigger for events to be triggered.

 

As now, this would be perfect for a "player walks here, says something witty once" type of situations and you need only one entity for each place.

 

There are two unsolved things:

 

* the multiple variant does not fire multiple times. I have stock 2.03 and I have no idea why. Maybe this is a bug in the trigger code? Grayman, I would be grateful if you could investigate why this happens (or not happens). The left, single show trigger is remoed from the game (g_showEntitites 1 shows it), while the right one remains, but is inactive. This is strange.

* instead of trigger touch I'd used trigger_multi - unfortunately, these do not have the proper parameters for function calls. They do have a "triggerWithSelf" spawnarg, but that only influences "activateTarget()" calls, but not the call to the "call" function. Which sounds like a bug to me. And "passActivator" is completely missing. So any triggering will always call the function as "functionName(activator)", so we can never get the required "functionName(trigger, activator)" which we need. A shame :(

 

The .def file contains an example as "atdm:trigger_speak_1", but I could never get it to work.

 

It would be cool if triggers (regardless which flavour) could have a new spawnarg "call_method", which would call the specified method on their attached script object as "methodName(activator)" (self = trigger in that case), so one could avoid all the hassle and the selftargeting and the global function. While these hacks work (for trigger_touch), they are ugly and do not work for trigger_multi etc.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I don't know if it would be any easier to use it, but it certainly isn't any easier to read through.

 

All I was suggesting is extending the same method ambients use:

 

Set "s_music" on a speaker and its volume is controlled by the "ambient volume" menu slider.

 

 

If we can do that without scripting, couldn't we also do:

 

Set "s_player" on a speaker and its volume is controlled by the "player volume" menu slider.

Link to comment
Share on other sites

Set "s_player" on a speaker and its volume is controlled by the "player volume" menu slider.

 

I assume you'd also want the code to automatically set what's needed to make the voice sound like it's an "internal voice" (and not coming from a particular direction). The voice entity handles that automatically.

 

Do you want something similar that uses the narrator slider? "s_narrator"?

Link to comment
Share on other sites

I don't know if it would be any easier to use it, but it certainly isn't any easier to read through.

 

 

I do think "s_player" and "s_narrator" could be added to speaker entities, but it would add some complexity to the code, f.i. if you add "s_player", other spawnargs need to be ignored. If you set both "s_player" and "snd" on a speaker, would it play both? etc. And you'd still need a trigger entity for each speaker.

 

So could you please look at the example map in DR and see if you understand how it's done?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

 

Spring means that "s_player" indicates the player sound volume from the menu should be applied. The shader itself is still defined by "s_shader".

 

Ah, I get it, s_player as boolean.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I assume you'd also want the code to automatically set what's needed to make the voice sound like it's an "internal voice" (and not coming from a particular direction).

 

I don't think it's necessary. Those settings should probably be put on the soundshader itself, the same way it is done (I assume) for ambients.

 

Do you want something similar that uses the narrator slider? "s_narrator"?

I'm still not sure why we need separate sliders for player and narrator, since the only thing the "player" slider effects is player narration (as opposed to player grunts or pain sounds). And the likelihood of needing separate control over two different narrators in the same map seems remote at best. But if we are going to keep two sliders, I suppose there should be two spawnargs, for the sake of consistency.

Link to comment
Share on other sites

I don't think it's necessary. Those settings should probably be put on the soundshader itself, the same way it is done (I assume) for ambients.

I don't think soundshaders make it possible to tell which voice they appear on, but I might be wrong. On the other hand, the already existing solution (atdm:voice) and the new one (atdm:trigger_speak) already work...

 

I'm still not sure why we need separate sliders for player and narrator, since the only thing the "player" slider effects is player narration (as opposed to player grunts or pain sounds). And the likelihood of needing separate control over two different narrators in the same map seems remote at best. But if we are going to keep two sliders, I suppose there should be two spawnargs, for the sake of consistency.

The difference is in importance for the map/story/gameplay. Player grunts or witty comments are entirely optional, narrator voices might contain important story bits they player does not want to miss.

 

Plus they play on different sound channels, which might make a difference in some sound settings (multiple speakers f.i.).

 

And if there are two sliders, not having to spawnargs to make use of them would be a bit silly. :)

Edited by Tels

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I have been sorta following this thread, and now more so because Melan and myself want ti implement it in the upcoming Crucible prologue mission.

 

What do we need to do to get it working with 2.03, is it just a case of using Tels script and then remove it once the code had been added in 2.04..?

Link to comment
Share on other sites

I have been sorta following this thread, and now more so because Melan and myself want ti implement it in the upcoming Crucible prologue mission.

 

What do we need to do to get it working with 2.03, is it just a case of using Tels script and then remove it once the code had been added in 2.04..?

 

Nothing's been decided yet.

 

In 2.03, you can simply use the existing atdm:voice and atdm:voice_trigger entities to hear the player's voice.

 

trigger (whether it's a trigger brush or a relay or a satisfied objective, etc.) -> atdm:voice_trigger (define the witty sound shader) -> atdm:voice.

 

You only need one atdm:voice entity in the map.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...