LSL History and llMessageLinked

[ItHadToComeToThis]

Many years ago when I joined in 2007, we used to play around with this combat system. Very basic, used random rolls each time you attack for levelling with a float number reducing each time to make levelling harder. A few years after this, I managed to obtain the source code and since then the system has just sat in my inventory all this time.

A few days ago, I was thinking back to the fun we had back then and decided that I wanted to actually study the code, see how the system worked and re create it with modern coding and techniques. Not for use anywhere, just one of those nerdy scripted projects we sometimes undertake for fun.

Upon read the code, there are some weird things going on that, in the last 16 years of coding in SL, are not practices I have seen used like this before. Or I have, and I have forgotten about it.

One of them is how damage is received and dealt within the system. It works like this..

Object collides with opponent and sends a message on a channel to the hud -> A script inside the hud picks up the message, checks the encryption -> Then, rather than use a linked message, the system says a new message onto a channel, to be picked up through the listen event, of another script, in the same link. And then, damage is applied to the players health value.

Was there a point when llMessageLinked wasn't a thing and the only way to transfer information between scripts was to say the information on a channel to be picked up by another script?

This method is used throughout the system for things such as the health bar, mana bar etc etc.

Interestingly, linked messages are used in the system, but I think they were added later. The feeling I get reading through this code is that this system is a modification of a much older system from pre 2007, that was scripted into at the time, to create the system we ended up using.

I know that certain link functions weren't around at certain points so figure at some point, link messaging must not have been a thing either.

So, that was either before I joined in 2007, as I started learning to script about six months after I joined. Or, was like that when I joined, but I have forgotten.

Can any history buffs help fill the details?

Edited August 13, 2023 by ItHadToComeToThis

[Rolig Loon]

If it helps, the earliest wiki post on the page for llMessageLinked was created by Strife Onizaka in March 2007. That was either marking the first appearance of the function or, equally possible, the birthdate of the wiki itself.  My own memory is fuzzy, since I began here at about the same time you did. Someone with a longer memory would be able to confirm exactly when the wiki appeared on LL servers, as opposed to the ancestral home, but I suspect that it was 2007.  I remember both wikis coexisting as I was learning to script LSL.  Anyway  ....  the point is that link messages were at least a thing by March 2007, when Strife created that page. I cannot tell how old they may have been at that time.

[Fenix Eldritch]

llMessageLinked has been around since pretty much the beginning. I can find posts from the SL forums archive dating back to 2003 that reference the function: https://forums-archive.secondlife.com/8/39/7055/1.html

 

[Qie Niangao]

3 hours ago, ItHadToComeToThis said:

Then, rather than use a linked message, the system says a new message onto a channel, to be picked up through the listen event, of another script, in the same link.

And that works? I'm not sure I've ever tried, link messages being a thing, but I've always taken the wiki at face value when it says:

Quote

• A prim cannot hear/listen to chat it generates. It can, however, hear a linked prim.

If it works, I guess that would mean "A script cannot…" instead of a prim. If I weren't so lazy, I could test, huh?

[Love Zhaoying]

1 hour ago, Qie Niangao said:

Quote

• A prim cannot hear/listen to chat it generates. It can, however, hear a linked prim.

If it works, I guess that would mean "A script cannot…" instead of a prim. If I weren't so lazy, I could test, huh?

Can't remember what it was, but a couple years ago I was peeved that scripts could hear themselves. Perhaps they can hear their own linked messages (so you have to filter them out / ignore them), which gives a tiny advantage to llSay() messages for certain use-cases?

[Qie Niangao]

Scripts definitely receive their own linked messages, and I'm pretty sure I've used that for program flow control in some circumstances (maybe if message_linked is already doing something in response to a message from another script, something I also want to do in another event in this same script… although I'm not sure why I wouldn't just define a subroutine to call in both places).

I gave it a very quick and dirty try and didn't seem to get listen() events for llSay()s generated by another script in the same link, but then I got pulled into RL stuff so my test definitely needs replication, or anyway some independent confirmation that this is how stuff works.

[ItHadToComeToThis]

1 hour ago, Qie Niangao said:

Scripts definitely receive their own linked messages, and I'm pretty sure I've used that for program flow control in some circumstances (maybe if message_linked is already doing something in response to a message from another script, something I also want to do in another event in this same script… although I'm not sure why I wouldn't just define a subroutine to call in both places).

I gave it a very quick and dirty try and didn't seem to get listen() events for llSay()s generated by another script in the same link, but then I got pulled into RL stuff so my test definitely needs replication, or anyway some independent confirmation that this is how stuff works.

Most cases are scripts in another link, but there's one or two cases where it isn't. I just don't see the advantage of using a say over a linked message to send data between scripts. Unless the original coder of this system didn't know linked messages existed. Its interesting to know linked messages have been here since at least 2003, really makes me wonder why the original coder chose to do this as it just seems unnecessary.

[elleevelyn]

from Linden Scripting Language Guide published 2003,  Authors: Aaron Brashears, Andrew Meadows, Cory Ondrejka, Doug Soo

A.137. llMessageLinked
llMessageLinked(integer linknum, integer num, string str, key id);
Sends num, str, and id to members of the link set. The linknum parameter is either the linked number available through llGetLinkNumber or a link constant.

 

edit add:

i think the initial scripter didn't realise at the time that llMessageLinked was the way to go. Something that was partially corrected by later edits

this kind of later discovery when a language is new (as it was at the time) is fairly typical and I don't think the initial scripter can be overly faulted for this

Edited August 14, 2023 by elleevelyn

[Love Zhaoying]

20 minutes ago, ItHadToComeToThis said:

Most cases are scripts in another link, but there's one or two cases where it isn't. I just don't see the advantage of using a say over a linked message to send data between scripts. Unless the original coder of this system didn't know linked messages existed. Its interesting to know linked messages have been here since at least 2003, really makes me wonder why the original coder chose to do this as it just seems unnecessary.

One reason to do it "both ways" is to use the separate / different linked message vs. listen events to isolate the functionality. I often do the opposite, and funnel any listen event responses from a plug-in listener script, through linked messages to the client script.

[ItHadToComeToThis]

1 hour ago, Love Zhaoying said:

One reason to do it "both ways" is to use the separate / different linked message vs. listen events to isolate the functionality. I often do the opposite, and funnel any listen event responses from a plug-in listener script, through linked messages to the client script.

Surely you could achieve the same effect though by doing one of the following. Either..

Using the key parameter to differentiate message headers.

Or, send the message as a CSV, split with a list and have the first entry as your message header.

Both would allow you to isolate functionality for different messages.

In terms of the plug in listener script, that I get as that's how I generally write systems. I have one script that listens and then delegates to other scripts.

But sending onto a channel to be picked up by another script in the hud, when you can just link message, seems weird when there's a plethora of other ways that will let you isolate functionality.

Unless you have a specific functionality you are wanting to isolate that the above methods won't work for? If so, could you share? I am genuinely curious, purely as if there is a legitimate use case over linked messages, im curious to hear it as its not something I would usually do.

[Love Zhaoying]

2 hours ago, ItHadToComeToThis said:

Using the key parameter to differentiate message headers.

Not if both scripts are in the same prim (or maybe even object)? I think..that's how I'm using it.

2 hours ago, ItHadToComeToThis said:

Or, send the message as a CSV, split with a list and have the first entry as your message header.

These days I send messages as JSON.

2 hours ago, ItHadToComeToThis said:

Both would allow you to isolate functionality for different messages.

Yep!  I think the only reason to use listen instead of linked messages, is if the scripts could / would be in separate objects. Perhaps that's the reason, or it was coded by multiple users who didn't know better.

 

[Qie Niangao]

8 hours ago, ItHadToComeToThis said:

Most cases are scripts in another link, but there's one or two cases where it isn't.

Thing is, I don't think a script can receive listen() messages from a script in the same link. There always could be untested edge cases, but what I did was create two very simple scripts in a prim, one a listener and the other doing llSay() on touch, then copied that prim and linked it with the copy, and labelled the linked prims "root" and "child". Here's the listener script:

default
{
    state_entry()
    {
        llListen(200, "", NULL_KEY, "");
    }
    listen(integer channel, string name, key id, string text)
    {
        llOwnerSay(llGetObjectName()+" got \""+text+"\" from "+name);
    }
}

and here's the sender:

default
{
    touch_start(integer total_number)
    {
        llSay(200, "Touched.");
    }
}

Whichever prim I touched, only the other prim's listener got the text. So it's not just that a script can't hear it's own llSay()s, but another script in the same prim cannot either.

Isn't that what these scripts were supposed to be doing? I feel like I'm missing something.

[Gabriele Graves]

If this combat system used several HUD attachments to work then this might explain the behaviour.  Often combat systems have HUDs in different parts of the screen to show different sets of stats, status, etc.  HUD objects can only listen to chat messages from other HUD objects as they aren't considered linked just because they are all attached to the avatar.  Only prims that truly form part of the linked set of each HUD object would be able to use linked messages.

Edited August 14, 2023 by Gabriele Graves

[Wulfie Reanimator]

The wiki is correct - scripts in a prim can't hear chat messages (llSay, llWhisper, llRegionSayTo, etc.) from any scripts (another script or itself) in the same prim.

Link messages can be heard by all scripts in the same prim, even the script that sent it. This can cause an infinite loop if the link_message event sends more link messages.

I'm pretty sure this has always been the case, at least I've never heard anyone even imply that scripts could hear chat messages from the same prim.

 

Moral of the story is "don't trust code written by someone else -- including your past self." People write all kinds of goofy code because they think it does something, especially if it appears to be working.

Edited August 14, 2023 by Wulfie Reanimator

[Love Zhaoying]

8 minutes ago, Wulfie Reanimator said:

Moral of the story is "don't trust code written by someone else -- including your past self." 

..or written by ChatGPT!