Jump to content
The Dark Mod Forums

Tels

Member
  • Posts

    14984
  • Joined

  • Last visited

  • Days Won

    23

Posts posted by Tels

  1. If you are refering to "def_attach5", the 5 in this is just an arbitrary number, and not related to the attach position. The wiki also says to not use 1..5, but start with 6, so it contradicts itself there.

     

    The position where to attach is defined with "pos_attachX" where X is the same number as used in "def_attachX", f.i. "6".

  2. No, this is a bit of missing on DR. The spawnargs are actually only the ones the entity inherits, but wether the code really supports this spawnarg (and wether it reads it once when loading the map, or everytime the spawnarg is used) is not encoded and thus DR cannot show it to you.

     

    The list, however, weeds out a few spawnargs that definitely are not supported on that entity so it's a first step.

  3. @Bikerdude: can do

     

    @Tels: Using the location system can cause the above mentioned effect. As well, it would in that case make much more sense to use a custom script anyway instead of triggering each particle "manually", which is tiresome to setup and not very error-prone.

     

    It may be possible to use lod, though. I'm not sure whether the func_emitters are supporting this system, as I've never tested it, but it could be the easiest way.

     

     

     

    The "effect" you mention is toggling (which can be solved with two scripts) or "see emitter even when not in zone"? That would need a more complicated setup, which is indeed cumbersome.

     

    And yes, the manual listing of entities in the script is very error prone.

     

    Anyway, I think it would still make sense to add support for "max_view_distance" spawnarg on emitters - then they could toggle themselves off with little resources.

     

    There is still the problem that a lot of emitters could be near the player, but not visible (think "one floor above the player"), or they could be far away, but need still to be visible (otherwise there is popping when the emitter comes into the distance). So its probably not safe to set default values, but instead use "-1" as "inifite view distance".

     

    In any event, are we sure that turning off emitters actually improve performance in a visible way? Edit: Oh, yeah it was for emitters that should not be visibe from outside - in that case a distance base check would not work, anyway (outside/inside of house is the same distance, but in one case the emitter is behind the wall and should be off).

     

    So, yeah, I guess location zones + scripts to toggle the emitters is the one method which must be used here.

     

    Still, I could provide a script that toggles all emitters in a certain zone - that way you would not have to list all the emitters in the script manually.

  4.  

    You should have an easier time in v2.04. Until then, try the patch in this thread:

     

    http://forums.thedarkmod.com/topic/17142-picking-up-stuff-without-clunking-it/page-3

     

    Interestingly enough, I always liked to have to pick up candles to snub them out - that makes it more a challange and adds a bit of suspension. My fear is the game will get way to easy if you can do anything with a simple click of a button and no longer need to have a "skill" in manipulation objects in 3D space.

  5. Springheel, the solutions posted above use only one function, that calls "trigger" on the entities. Which means, they are toggled. You could also use two different functions, and one calls

     

     

    $entity.On();
    

     

    while the other one calls:

     

     

    $entity.Off();
    

     

    It would be even safer if you have a function that runs through all emitters, and only disabled the ones in the old_zone, and enables all in the current zone. Then you would not need to adjust the scripts everytime you add/delete or rename an entity. (The last one is a potential source of errors!)

  6.  

    There are two ways that come into my mind to do this, either by using the stim/response system and/or by using a custom script.

     

    With the first one, the player stim would activate all nearby func_emitters and keep them in that state. If the func_emitters are not receiving the stim anymore, they are disabling themselves. For this effect to work they need a custom script, though.

     

    If you are only using a script you would have to let every func_emitter rund an update loop which checks the location or (which may works out better) checks whether they player is close enough and can see the func_emitter (or vice versa whether the func_emitter see's the player). Using the locations could cause particles to be turned off although the player is seeing them, just because he stands behind a vp seperating his location from the particles one.

     

    The script could look like this (not tested):

    No need to make it this compliated, running a script function when the player leaves/exits a zone is much safer - it even works with noclip :)

     

    Edit: Although I like your idea of distance-based emitters, this should really be built into emitters and turned into a C++-supported spawnarg. Running a script function on each emittier will use a lot of resources if you have lots of emitters, plus it adds quite some memory overhead for the script objects that need to be bound to each emitter.

  7. Looking to this thread, wow, that sounds er looks all nice. Seems 2.04 will get a boost in quality, love especially the idea of higher resolutions - some of our original textures have become quite outdated in that department over the years due to progressing of technology. Can't wait to play some old missions with these new shiny textures!

    • Like 1
  8. I'd be worried about using trigger_multiples for this, since the player could, for example, walk into the doorway trigger, turn the particles inside the house on, then back out of the house and then enter again, turning them off.

     

    Using an info_location entity would be much better, but is that possible?

     

    Yes, definitely. The location system supports running a script when the player enters one location, and one when he leaves the location -no matter how the player actually enters or leaves the location.

     

    Use one or two of these on the info_location separator entity:

     

     

            "editor_var call_on_exit"                               "Name of global script function to be called when the player exits this zone."
            "editor_var call_on_entry"                              "Name of global script function to be called when the player enters this zone."
            "editor_var call_once_on_exit"                  "Name of global script function to be called exactly once when the player exits this zone."
            "editor_var call_once_on_entry"                 "Name of global script function to be called exactly once when the player enters this zone."

    Inside the script you can do whatever you want, activate triggers, dim lights or teleport entities etc.

     

    If you need help with that, I'm happy to provide script snippets.

    • Like 1
  9.  

    Not nearly as violent as a Lithium Ion battery, but I still wouldn't want this to happen in my pocket. Note to self, never carry batteries in a pocket.

     

    Today 9V cells are actually a rectangular housing containing 6 x 1.5 volt round cells - so not only does it waste a lot of space, it often basically amounts to a stack Li-On cell, anyway :) Capitalism gets you the cheapest product that passes as the one you'd actually wanted instead...

  10. I've tried to detangle the thread and what I gather is the entities (already existing) will be used and the new script object (with the "use less entities") will not be added. So there is nothing for me to do, right?

     

    The only thing that would need to be looked at is the "why does the multiple trigger in my testmap fire only once". Is this a mistake in my testmap? Or a bug? Grayman, could you have a look please?

  11.  

    I think he meant if the player's reaction to something is a pondering sort of sound, like "hmmm" or "huh?", and that's bundled up with witty sayings, then they're all controlled by the player voice slider.

     

    I don't think he meant the grunts you hear when the player lands hard or gets whacked by a sword or something along those lines.

     

    Exactly.

     

    The different sliders are different for "It was a dark and stormy night in copperlane district" (important info by narratori: we are in copperlane district) and "I'm afraid of heights" (unimportant info spoken by the player to himself).

  12. 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. :)

  13. 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?

  14. 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.

  15.  

    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".

  16. @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.

  17. 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*

  18. 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.

  19. 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).

×
×
  • Create New...