Guild of Writers

Okay, we've had sounds for a little while now. Of course in some cases we have something that's new as it seemed to just come out with the new plug in, and with the new plugin came a different way to set the flags with sound:

Old Way (ver 1.2.1 or older):

Code: Select all

flags: loop | start | 3d

New way (ver 1.3.0 or higher):

Code: Select all

flags
  - looping
  - autostart
  - is3dsound

Now, here's a list of sound flags listed in the Wiki:

is3dsound
disablelod
looping
autostart
localonly
loadonlyoncall
fullydisabled
dontfade
incidental

Only 3 of these are even discussed in the Wiki: is3dsound, looping, and autostart.

How about the others guys? Anyone figured them out yet?
I'm really interested in loadonlyoncall, and incidental. I'm wondering if these are the flags to use for triggered sounds for actions, such as the avie clicking on a button or pulling on a lever. We've discussed that this should be possible. I'm going to mess around with them myself today, anything I find out I'll post here ASAP of course.

On a side note: kickable object sounds. I noticed upon importing the Teledahn Slave Prison, that the bones and rocks have sound emitters embedded in them, some up to 3 different ones, labled nicely like: Hitemitstone.003, Rollemitstone.003, Rollemitmetal.004.
Of course Cyan seems to have used 3DSMax and their exporter to make this work, as there is no python files for it. Is there a way for ALCscripting to do the same thing?

See, here's another thing:

Code: Select all

    <some object>:
        logic:
            actions:
              - type: responder
                name: SoundResp (name or tag for modifier ref)
                responder:
                   states:
                    - cmds:
                       - type: soundmsg
                         params:
                            receivers:
                             - 0011:<Name of emitter object>
                            cmds:
                             - play (start the sound)
                             - stop (stop the sound)
                             - setvolume (set the volume)
                            volume: 1 (volume only set if setvolume cmd is used)
                         waiton: -1
                      nextstate: 0
                      waittocmd: 0
                   curstate: 0
                   flags:
                    - detect_trigger

Okay, now I understand most of this believe it or not, except when it talks about "responders" okay, what the HELL is a responder?? How do you use it? Can you give me an example?

This is exactly what D'Lanor was talking about, we need a "ALC for Dummies", while we understand that the tool team is still working on knowing what all the flags mean themselves, obviously they KNOW what some of the flags are, and then they get presented to the rest of us as though WE know what they are too.

Newsflash: we don't.

And there's no where I can go to read about it either. I mean I can hazard a guess and try a few things. In the above example, I can assume maybe that the <some object> is a region around the button I'm pushing, and that the responder is the button. Or is it the other way around? Is it, the button is some object, and the responder a region? Or better yet, is some object the sound emitter? Or would the responder be the sound emitter? Of course we have 0011: name of sound emitter.......

So you see, us poor slobs can take a deep breath, type it all in (by the way, I REALLY wish Blender would let me paste scripting from a text file into the ALCscripting, it's annoying as all git out to have to type every damn thing every damn time!), and then export and try it.......except that if it doesn't work, do we really know what went wrong?
How can you tell what might be wrong, if you don't know what the stuff is in the first place?

This is like trying to get a car to start, but not knowing how starting works:

Do I replace the battery?
Is it the starter relay?
Is it the key switch?
Is it the starter motor?

So we just start replacing parts and hope we'll get it to start. Oh, but let me add a twist: we don't know if the parts we put in are working or if they are even for our car!!

Little help? Please?

Hmm, the key switch? The way I would start a responder (and have done so in the past) is by Python.
But I'm sure someone will come along and say we don't need Python for that.

Edit: I see you have nextstate in that script. That must be for multistage responders. Now that is where things will really get complicated.

The script you see is what Nadnerb put out. Ask him. I don't know.

I know I tried this, and nope, didn't work.

But, I don't know if it's wrong, or if I'm doing something wrong. That's the point.

Copy and paste works just fine in the Blender text editor - it just uses ALT as a qualifier, rather than Ctrl, that you are, no doubt, more used to (check in the text editor's "edit" menu)

Documenting things tend to be a weak point among developers and I must say that while what is published may not be quite sufficient for us mudcrawlers, "our" guys here are doing exceptionally well in this regard, given the circumstances and very much so in comparison to many others. I just wish they were free to disclose all they know... :9

Okay responders are this insanely cool (and insanely complicated) invention that makes Plasma work.

We know that we have all of these solid objects and textures and drawablespan things that actually make up the world around us. Then we have regions and clickables and seekpoints and animations and all the fun stuff that actually makes things interact with us.

All objects in Plasma are actually classes within the engine and can send and receive messages. Plasma's message system in one of the key features, and is a great way of causing things to happen. When you enter a region, you want to send a message to the main brain of the game telling you to change footstep sounds, or telling you that the door is now clickable. Those messages are stored in ResponderModifiers.

A respondermodifier has multiple "states". For footstep regions, you have one state for entering the region, and one state for exiting. Each state is made up of one or more commands. Each command sends a message to the game system.

Code: Select all

    <some object>: #This is the name of your object
        logic: #Tells the system that we are parsing data for logical objects
            actions: #These are the actions that the logic data sends
              - type: responder #We're dealing with a responder modifier and messages
                name: SoundResp #Name or tag for RespMod reference
                responder: #The actual responder data goes in this section
                   states: #List of the states
                    - cmds: #Commands in the first state
                       - type: soundmsg  #We're sending a plSoundMsg
                         params: #The parameters for the sound message
                            receivers: #List of objects that will receive the message
                             - 0011:<Name of emitter object> #Reference to a plAudioInterface
                            cmds: #Message Commands
                             - play #start the sound
                             - stop #stop the sound
                             - setvolume #set the volume
                            volume: 1 #volume only set if setvolume cmd is used
                         waiton: -1 #Don't touch this... it doesn't work as expected
                      nextstate: 0 #The number of the next state (we only have one state in this example)
                      waittocmd: 0 #Also don't touch this... doesn't work as expected
                   curstate: 0 #The default state for the RespMod (we only have 1 state, so state 0 is the default)
                   flags: #Flags for the logic code and modifier
                    - detect_trigger #Detects when the responder is triggered

The WaitToCmd and WaitOn values are supposed to allow for delaying messages until another message has been sent and parsed. (Ex. you click to open a door, you want the avatar to move to the door and click it before the door starts sliding down with a loud rumbling). I've been playing with different values for these for a while now, but I can't find anything that seems to work, it just prevents future messages from being handled at this point. So: avoid these.

First and formost:
Please know that I really appriciate the very hard work, determination, and awsome reverse engineering that all the people have done to further Age building. This includes both past and present people. This also includes, everyone who has helped with the plugin, ALCscripting, Python scripting, and external tools such as PlasmaShop, the ULM, and other things.
I will NEVER tear down your work, or the effort that all of you have put into it. It truly is amazing. Please remember that.

However, yes, I will rant, rave and otherwise gripe about things. I was a sailor in the US Navy for 10 years. That's our job. To gripe about things.

So, when I run across things that make me feel stupid, or ignorant, I tend to gripe, get moody, eat small children and dogs. Pay me no mind, except to understand that I need guidance sometimes. It is VERY MUCH appriciated when I do get help, or someone takes the time to explain something to me, in almost child like terms when necessary. If I ever can repay those people, I will, even if it's nothing more than buying them a beer. Thank you again.

Now, thanks' Paradox, your explination really clears some things up!

But I still have some questions:

What I'm trying to do, is make a sound happen, because I clicked on something with the mouse. IE, I clicked on the door button to open the door.
Now, using Trylon's scripting for Python, I now have a button I can click on, and a door that slides nicely to one side, any speed I want it to.
But I want to make a sound happen when I click on that button too. One would think this would be "childsplay" as I can get a whole door to move by clicking on that same button. Yes, it takes a large chunk of python scripting....but it works:

Code: Select all

doorbutton:
    quickscript:
        simpleclick:
            pythonfile: zcdoorclick
            region: doorregion

I realize that quite a bit is going on with quickscript command. I've taken a look at the python files for this in the plugin.

Now in your example, your talking about a footstep region. I don't want the sound to play automatcally because the avie stepped into it. I want the sound to play because of an action that they avie performed, or rather the player, which was click on something.

If to achieve this, I must use the ALCscripting your showing.......what exactly would the responder data be???

Not being a programmer, nor hacking through god knows how much file you guys do, it still seems like this would not be that hard. I guess I'm thinking outside the box here, but I would expect something like:

Code: Select all


dooremitter:
    type: soundemit
        flags:
          - (something that says don't play unless doorbutton was notified)
        file: dooropeningsound

doorbutton:
    quickscript:
         (something that says to activate a sound emitter)
              flags:
                - (something that says to play only once)
                - (something that says to loop instead)

I guess I'm thinking too simple, but again, you guys were able to make things like this simple in the first place.

Anyway:

Okay responders are this insanely cool (and insanely complicated) invention

After reading that, I've come to realize that you developer types are .......well just dangerously insane.

*crawls back into hole with gun and peeks out again*

andylegate wrote:*crawls back into hole with gun and peeks out again*

Ok, I'm now putting my bullet proof vest on, and I will get you out of that hole andy!

Bump! Sorry, I made a long edit while you posted Trylon.

I was just kidding with that post ofcourse
(I had already read the blue text when I posted)