Link_message and functions

In my current project I have a script with several states. It frequently needs to read a variable from another script using llMessageLinked (to enquire) and link_message (to get the result back).

Now, what I would like is to wrap this up in a function, so that I can just write

var = mygetval() ;

from anywhere in the script. However, it looks to me as though I can't put the link_message handler in the function, I have to include an instance of it in every state. Is that right?

yes, event handlers are state specific. But you can use a function within the event handler to minimise the code.


You may also find it more efficient for the other script to post the value using link_message when ever it changes. That way you will always have its last calculated value available.

That would be good, except unfortunately the other script is not mine, and is no_modify.

I dont suppose you know how or what causes the value to change?
If you did you could request an update when you know it will have been updated.

Ok, here is a possible trick to deal with it:

In your script (lets call it "First Script" Create the function to send the link message to the other script. (The one that is not yours and now I call "Second Script"
In the punction, put an llSleep after the link_message function with at least 2 seconds to be sure.

Create a Third Script to catch the response from the Second script.

The Third script receives the response and write it in the Description field of the prim.

Back to the First Script. After the two seconds sleep, the function reads the Description field and takes the value sent by the Second Script to the Third one.

I think this should work with the proper sleep. You can even pass more than one value using CSV format or something like that. You can also make the First Script to erase the Description fiels so nobody can read the values after they was used.

I never tested it but I think it may be possible. Let me know if it is.

The drawback to that idea would be that the prim would be getting constant changed events, which could trigger unwanted behaviour such as reloading of notecards etc.

Requesting data more often than required, or more often than it is being updated, is a waste of processing time.

The Change event is not triggered by Description changes (according to the lsl wiki). If thats what you are saying.

The only complication I see is if the First Script contains some timer event with a very short interval respect the llSleep time.



Totally agree with that 120%. Let's hope that in this case this is extreme necesary.

You are correct I confused myself! My Apologies.

Further work shows that the problem is worse than I realised. I didn't appreciate until now that the event handler is not triggered immediately. I had blithely assumed that once one called llMessageLinked then link_message would be invoked at once, and then control would return to the calling function at the line after llMessageLinked. Of course, this doesn't happen; all those lines execute before link_message is ever handled. That had me puzzled for a good hour.

Now I have to rethink entirely. Checho's idea looks like an option.

Such is the way of event driven systems.

The way to handle this is to execute the lines within the link_message event handler, i.e. process the responce when you receive it.

Yep, I discovered this. The situation was previously this:

The script has several states each of which periodically call a timer event. The timer event controls the main actiivity, and calls some functions, which need the current state of the variable in the 3rd party script. So the functions called MessageLinked, but of course, after link_message retrieved the variable, there was no way to get back into the loop at the right place.

So I rearranged things a lot.

I simplified the functions so they could be rolled into one which behaved according to the parameters it was called with. Then I moved MessageLinked so that it was the only thing in the timer event. All the program logic then went into the link_message handler, including the code to send control to the next state - which sets up the next timer event, and all works smoothly now.

I think though, that in some other event-driven languages the original logic would have worked, because calling a new event interrupts the existing one, and control then reverts to the point of interruption. I think. In contrast to LSL always finishing one event at a time, no matter what.

The thing is you dont call an event. You can only respond to them.
The llMessagelinked posts of a message to the other script and your routine will then process the rest of its code.

As you say in a true (interruptable) event driven systems it would then halt your code when the responce message was received. But LSL isnt interruptable. This makes it far simpler to implement and more deterministic in functionality.

Well, actually, llMessageLinked does call an event. Or raise one, call it what you will, it causes an event to happen.

No, it post of a message it doesnt raise an event in this script.
The event is being raised in this script by the reply from the other script.
Its subtly different.

True, it's raised indirectly.

How accurate do you need to be? In other words, will your script break if it has slightly old data? If not, then the "update the description" trick could work, assuming you're not getting back more data than can be fit in the description.

You'd use a 3rd script, and all it does is send out a link message on a timer, and when it gets the response, it updates the prim description. Now your main script can just read the data off the description, which is a synchronous function call. You'll get the most recently updated data, but you won't be guaranteed that you're getting the data from right that instant, because you don't know the last time that data was updated (since that's done in a separate script). I guess you could add the update time to the data as well, and do some sanity checks on that or something. But handling the "data is too old" case puts you back at step one

If you got it working where you moved the logic to the link message event handler, IMO that's cleaner. But sometimes you end up needing to save too many globals so you can get to them when the event comes back to you, and then something like this could help.