nPoseTeam / nPose-V3

nPose is an LSL script for use in Second Life® that allows one or more avatars to sit on (and otherwise control) objects and rez props, without poseballs. A versatile animation system/engine.
20 stars 2 forks source link

Expand UDP example scripts to include using UDP values in the script #34

Open BadJenny opened 5 years ago

BadJenny commented 5 years ago

The two UDP sample scripts show how to create and update a UDP (I guess if it doesn't exist the update link message to nPose creates it?) But what they do not show is how to access the UDP values for use in the script.

Maybe create an example where the UDP value is fetched, and then used to fire of a SET card depending on its value?

HowardBaxton commented 5 years ago

I've sent you a demo that is using UDP Bool for an example of how they are used.

Howard

LeonaMorro commented 5 years ago

@HowardBaxton For the sake of completeness, can you post the demo script here too?

HowardBaxton commented 5 years ago

Ahh, OK you busted me. The demo I have does not include a script to check the UDPBOOL's state other than nPose scripts themselves. I did however do a little research and if needing to intercept one (or more) UDPBOOL states as they are updated in a script (which is when the NC line is read, it can be done something like this functional script:

integer UDPBOOL = -804;

default {
    link_message(integer sender, integer num, string str, key id) {
        if (num == UDPBOOL) {
            list TempList = llParseString2List(str, ["="], []);
            if (llList2String(TempList, 0) == "FacialsState" && llList2Integer(TempList, 1)) {
                llOwnerSay("Facials are turned ON");
            }
            else if(llList2String(TempList, 0) == "FacialsState" && !(llList2Integer(TempList, 1))){
                llOwnerSay("Facials are turned OFF");
            }
        }
    }
}
BadJenny commented 5 years ago

I did not get the demo Howard. Maybe it was blocked by my email filter or something (wasn't in spam folder). Reading example above Intake it that snippet will listen in on the nPose messages and when a UDP gets updated, it will intercept it and then allow you to act on the updated value.

I was actually just looking for a way to access the UDP value itself regardless of it's getting updated or not. Is there a linkmsg I can send (with the UDP string as the argument) to retrieve the UDP's value? I didn't see such a command in the list of known link messages, so I am thinking no? So, either it's missing from the list or there is no reason to send that info between scripts?

HowardBaxton commented 5 years ago

I sent the demo to you in world. It should be in your inventory when you log in. You are correct about intercepting the message when a specific udp is updated.

There is no command to allow you to ask for the current value from any of the scripts so using something similar to the script above is the only way you could grab the most up-to-date value of the udp.

For others who may read through this I'll explain what happens and how the data flow works. When you have a chance to take a look at the demo I sent you in SL, edit the .init card and have a look. you'll see a couple lines of interest about the facials as follows:

OPTIONS|facialexp=on
UDPBOOL|FacialsState=1
MACRO|FacialsStateMacro=On

The first line is a global option we can set to turn ON the facial expressions in nPose so that if facials are used, they will be run for any pose. The second line is setting the state of the udpbool to match the option we just set or turned on. The third is setting up a macro to also match the option we just set up. ((Macros are handled similarly as the udpbools are except macros can be set to a text value and udpbool can only be set to 0 (zero), or 1 (one).

So, we see these lines in the .init card but how does nPose process and use them? The .init card is a special card which will be read and processed first if scripts are reset. Thus, the udp and macro are receiving their initial values as soon as the lines are processed. The core script is tasked with processing each of the lines inside that or any other notecard in the system. The core does not necessarily use the data it processes so when it has finished processing them the core will forget all about the udpbool ,the macro, and even the fact that it has just set a global option to "on". The core does broadcast the data out for all the scripts who need this information can grab it for whatever task they need to perform. This is the only time data about these specific things is available for use to grab and hold onto so our example script above is grabbing the current state of the udpbool as it is being set. The menu script does grab this data and use it for Button Permissions but it has nothing setup so that we might ask for the current state and have the menu tell us what is current.

These values for the macro, the udpbool, and the facials option will remain exactly this way until we select another notecard from menu which changes these settings. Such as a menu notecard to turn off facials and change the macro and udpbool as follows:

OPTIONS|facialexp=off
UDPBOOL|FacialsState=0
MACRO|FacialsStateMacro=Off

When the menu button is clicked, the core will get the notecard information and the process described above takes place again. This is not the initial setup but would be considered an update to the values. The example script above would get the information at the same time as the menu script would.