An odd pair …

[Bem Beyaz]

I have a very old routine of linked messages passing between scripts where a listen or sensor event will pick up a message and concatenate the relevant key of an object or avatar before passing it to other scripts in the same prim. The message is processed in the other scripts using a series of conditions testing variations of something like this …

llDeleteSubString(message, 0, 5);

… where the first part in this case is expected to be a six-letter string and the second part will be a key in any case.

The system works fine — so long as I'm paying attention and change the length of the expected message where necessary — but there are quite a few conditions in each of several scripts and I was wondering if, aside from the question of human error, it might be more efficient to pass the linked messages as a temporary list from the first script …

list whatever = [message];
whatever += "," + uuid;
llMessageLinked(-4, 1, (string)whatever, "");
whatever = [];

… break it down in other scripts with something like …

list whatever = llParseString2List(message,[,],[]);
object = llList2String(whatever, 0);
uuid = llList2String(whatever, 1);

… and work away with a simpler set of conditions.

Doubtless experienced developers will find the answer to my question trivial but I'll ask it any way because I'm thick as two short planks when it comes to the overheads on script routines. The benchmark for me is purely an instinct that if I see the same line or even a similar syntax too often, the routine might be written more succinctly.

Any other suggestions would be welcome — would a strided list be better, for instance — I'd like to be clear about what I'm doing before I change so many lines.

NB: For what it's worth, the code is old and has never been in production — I have a hang-up about distributing scripts in-world unless I'm confident they have the washboard stomach and trim overheads of Greek statuary.

[Mollymews]

adding a list into the mix will cost a little more stack memory

unless you are passing more than one object + uuid pair in a message then I would suggest sticking with the string concatenate method

[Rachel1206]

OK, if it is just is a simple split of message, have you looked at the extension of  the string functions: left and right, this allows you to operate with a single simple string message for the linked communication.

The UUID of the user for example, you can just pass as the key value in llMessageLinked().

Simple example:

llMessageLinked(LINK_THIS, 1000, "throw|scream", llDetectedKey(0));

link_message(integer sender, integer num, string message, key id)
{
    llOwnerSay("ACTION:   " + left(message, "|"));
    llOwnerSay("REACTION: " + right(message, "|"));
    llOwnerSay("BY USER:  " + llGetUsername(id));
}

Now for very complex things the use of list makes sense, here you pass the list with llList2CSV() and reads the list with llCSV2List(). Notice though the memory usage will be high and good house cleaning is required.

 

Edited December 15, 2020 by Rachel1206

[Bem Beyaz]

Quote

adding a list into the mix will cost a little more stack memory

That's what I suspected, Molly. Thanks for the confirmation.

Quote

have you looked at the extension of  the string functions: left and right, this allows you to operate with a single simple string message for the linked communication.

Thanks, Rachel — those functions are exactly what I need. I was not aware of them but I have used something similar in PHP.

Like many, I suppose, I tend to drop in and out of SL depending on my interest levels but I really should get back into the habit of looking at the Functions page on the Wiki.

[Wulfie Reanimator]

37 minutes ago, Bem Beyaz said:

Thanks, Rachel — those functions are exactly what I need. I was not aware of them but I have used something similar in PHP.

Like many, I suppose, I tend to drop in and out of SL depending on my interest levels but I really should get back into the habit of looking at the Functions page on the Wiki.

The functions Left and Right won't be found on that Functions page, since they're just user-defined functions.

You have to copypaste the function definition from the wiki page into your script before you can use it.

[Bem Beyaz]

I see now why that solution suggested by Rachel was such a revelation to me — in fact it isn't detailed under "LSL Portal > Functions" at all but "LSL Portal > LSL Types > LSL String" and further down the page under User-created utility functions. The Wiki can be a bit of a maze for anyone who does not regularly visit it.

I'm posting this for the general benefit of those who may be a little hard-of-thinking like myself .

[Bem Beyaz]

Quote

The functions Left and Right won't be found on that Functions page, since they're just user-defined functions.

Thanks, Wulfie — I just finished the post immediately above upon noting the problem.

[Mollymews]

On 12/15/2020 at 10:26 PM, Rachel1206 said:

llMessageLinked(LINK_THIS, 1000, "throw|scream", llDetectedKey(0));

 

link_message(integer sender, integer num, string message, key id)

i like this way. Is no concatenation or parsing code needed

when we do it this way we can also change the parameter names to help show what is happening

integer level = 3;
string code = "6Digit";
key player = some agent uuid;

llMessageLinked(LINK_THIS, level, code, player);


link_message(integer sender, integer level, string code, key player)
{
      .. do code("6Digit") with level(3) player() ...
}

 

 

 

 

[Bem Beyaz]

Quote

i like this way. Is no concatenation or parsing code needed

That is a good idea, Molly. Although the second part of the message converts to a key, it does not convert to the sender's key in every case — there are a number of security conditions involving a third party key but I could re-jig the routine to test only for those. I guess a combination of this and Rachel's suggestion of the "Left" and "Right" functions would be a good strategy.

 

Edited December 17, 2020 by Bem Beyaz

[Mollymews]

38 minutes ago, Bem Beyaz said:

the second part of the message converts to a key, it does not convert to the sender's key in every case — there are a number of security conditions involving a third party key

 

the link message parameter: key id can be any uuid, agent, object, asset, or third party key that you have made/use

[Wulfie Reanimator]

10 hours ago, Mollymews said:

the link message parameter: key id can be any uuid, agent, object, asset, or third party key that you have made/use

It doesn't have to be a key at all, in fact. You can simply use it as a second string.

default
{
    touch_start(integer total_number)
    {
        llMessageLinked(LINK_THIS, 1, "hi", "bye");
        llMessageLinked(LINK_THIS, 1, "hi", "This string will be longer than a regular key can be.");
    }

    link_message(integer sender_num, integer num, string str, key id)
    {
        llOwnerSay(llList2CSV([num, str, id]));
    }
}

 

[Bem Beyaz]

Quote

It doesn't have to be a key at all, in fact. You can simply use it as a second string.

Aren't there scripting gnomes living in the ditches between software and simulator that don't like us doing things like this? My granny called it "deprecation" and she said they'll sneak up and steal your hair if they catch you doing it,.

[Phate Shepherd]

2 hours ago, Bem Beyaz said:

Aren't there scripting gnomes living in the ditches between software and simulator that don't like us doing things like this? My granny called it "deprecation" and she said they'll sneak up and steal your hair if they catch you doing it,.

If that were the case, the gnomes would all be sporting Rapunzel length hairstyles.

Using the id key field as a second string is so commonplace that a significant number of beds and chairs in SL would break if it were changed. Several very popular scripts rely on it, such as AVSitter and FURWARE text.  llMessageLinked Wiki: "You can use id as a second string field^[2]. The sizes of str and id are only limited by available script memory."

[Bem Beyaz]

Quote

Using the id key field as a second string is so commonplace that a significant number of beds and chairs in SL would break if it were changed.

Thanks for the heads-up on that, Wulfie and Phate. It looks like Granny should have stuck to knitting. Or maybe not, come to think of it — this kind of explains the orangutan arms and teddy bear bodies on all those Christmas jumpers she gave me over the years.

Boy-oh-boy, am I glad I asked about this problem — even if it looks like I need to write the whole batch of scripts from scratch.

[Wulfie Reanimator]

8 minutes ago, Bem Beyaz said:

Boy-oh-boy, am I glad I asked about this problem — even if it looks like I need to write the whole batch of scripts from scratch.

The absolute joy of programming.

3 hours ago, Bem Beyaz said:

Aren't there scripting gnomes living in the ditches between software and simulator that don't like us doing things like this? My granny called it "deprecation" and she said they'll sneak up and steal your hair if they catch you doing it,.

Those gnomes exist and they're called "undefined behavior" -- but this is thankfully not one of them. In fact I can't think of any undefined behavior in LSL, it's a surprisingly safe language, especially when compared to something like C.

Edited December 18, 2020 by Wulfie Reanimator