Communication between two objects

[ronXt]

Is there a way I can communicate from one object to another object from anywhere in-world

Given-

>I have key of other object with which I want to establish communication.

>I am not in same region.

 

llInstantMessage, have limitation as we can send message but can't make other object listen to that message, no.

I don't have external server to communicate through http, no.

llEmail, takes 20 seconds to complete communication, no.

 

 So apart from these three can we make it possible?

 

 

Edited June 9, 2020 by ronXt
NULL_KEY

[KT Kingsley]

You don't need an external server to communicate using HTTP within SL. However, using HTTP, the problem is that the target URL is not fixed and needs to be made known to any object anywhere on the grid, hence the frequent use of a fixed external server to supply this information.

The function llEmail sleeps the script after sending the email, so unless there's a requirement for a rapid back and forth of messages, you can use a second script just to send the email when it's asked to do so via a link message from the first script. The first script can then get on with whatever it's doing, which can include receiving emails from remote clients.

I've never done it myself, but the above suggests it'd be possible for a remote client to send an email requesting the server's URL, to which the server could respond by using HTTP or email, using a URL supplied by the client in it's email message, or by using the email address supplied in the email event. When both objects have each other's URLs they can establish a fairly fast communications channel using HTTP.

 

[Oz Linden]

Using llEmail to start the conversation does require that you know the object id of the object you want to communicate with, however (the email address of any object is its object-id@lsl.secondlife.com).

Another alternative is to assign the scripts to an Experience, and then both will have access to the key-value store, which can be written and read by any script in the Experience. You can either poll it to see changes written by other objects, or use it to discover the current HTTP URLs for other objects and then communicate between them that way.

[Qie Niangao]

6 minutes ago, Oz Linden said:

Another alternative is to assign the scripts to an Experience

This is a wonderful solution (and particularly effective for broadcast messaging where the HTTP limits can get restrictive very fast) however both the sender(s) and recipient(s) must be on land that permits the Experience to which the messaging scripts are compiled.

llEmail is the only other strictly in-world way of exchanging ephemeral URLs, and will work well enough for a while, but the notorious SVC-23 remains an extremely intermittent but completely debilitating defect, which the Lab has apparently given up trying to fix. Maybe it'll be cured by ☁️Uplift☁️ magic.

[Wulfie Reanimator]

If you have a way to know the UUID of both objects, you have a way to know the URL (from llRequestURL) of both objects.

In that case, you can use llHTTPRequest to talk directly between the objects, since you can make the request with the other object's URL.

But, URLs are even more fragile than object UUIDs, so without a way to automatically republish the URLs of at least one of the objects to some fixed, external-to-SL location (or Experience), your communication will inevitably break if both objects lose their URLs at the same time. (Such as when the grid goes down, or a rolling restart gets both of them.)

Edit: And yes, grid-wide access to the Experience database would be more than enough for me. It would solve so many problems and remove the hassle of setting up external services.

Edited June 9, 2020 by Wulfie Reanimator

[KT Kingsley]

2 hours ago, Qie Niangao said:

however both the sender(s) and recipient(s) must be on land that permits the Experience to which the messaging scripts are compiled.

@Oz Linden: long, long ago it was mooted that all experiences might become grid-wide (or something like that). Nothing has come of this, and I suspect even if it were to happen it would require the experiences to be specifically enabled by individual land owners.

Given how extremely useful the key-value store feature could be, may I suggest that it be detached from the experience scope, and enabled across the grid, except, perhaps, where specifically disabled by individual land owners.

Edit: is this worth a JIRA feature request?

Edited June 9, 2020 by KT Kingsley

[Mollymews]

35 minutes ago, KT Kingsley said:

Given how extremely useful the key-value store feature could be, may I suggest that it be detached from the experience scope, and enabled across the grid, except, perhaps, where specifically disabled by individual land owners.

Edit: is this worth a JIRA feature request?

i vote for something like this

i would be quite happy if we only got KVP grid-wide from a scripted attachment, as a first step extension toward grid scope experiences

[Qie Niangao]

3 hours ago, Wulfie Reanimator said:

If you have a way to know the UUID of both objects, you have a way to know the URL (from llRequestURL) of both objects.

I'm not sure if I just don't understand what this says, or if I've been missing a trick all these years. As far as I know, it's not enough to know the UUID of both objects, but also necessary to learn the URLs those objects obtain for themselves. The hard part, as I've always understood it, is the exchange of those URLs (and, of course, the fact they're ephemeral, which means the exchange has to happen over and over, each time the old URL is invalidated).

If there were some way to directly use the other object's UUID to learn (one of) its URLs - a directory service, if you will - it would be a big win.

[Wulfie Reanimator]

22 minutes ago, Qie Niangao said:

I'm not sure if I just don't understand what this says, or if I've been missing a trick all these years. As far as I know, it's not enough to know the UUID of both objects, but also necessary to learn the URLs those objects obtain for themselves. The hard part, as I've always understood it, is the exchange of those URLs (and, of course, the fact they're ephemeral, which means the exchange has to happen over and over, each time the old URL is invalidated).

If there were some way to directly use the other object's UUID to learn (one of) its URLs - a directory service, if you will - it would be a big win.

I mean it's pretty logical, right? If you have a way to get the other object's UUID, you can use that same method to get further data from that object (such as URL in description/hovertext, or even llEmail for first contact.) In practice though, there isn't a way for one object to discover the UUID of another, unless it's in a connected sim. The only way you could discover UUIDs from disconnected sims is by hand or an external server.

[Lucia Nightfire]

13 hours ago, KT Kingsley said:

@Oz Linden: long, long ago it was mooted that all experiences might become grid-wide (or something like that). Nothing has come of this, and I suspect even if it were to happen it would require the experiences to be specifically enabled by individual land owners.

Given how extremely useful the key-value store feature could be, may I suggest that it be detached from the experience scope, and enabled across the grid, except, perhaps, where specifically disabled by individual land owners.

Edit: is this worth a JIRA feature request?

I don't recall Tommy, Dolphin or Alexa mentioning that during the closed beta.

Albeit useful, I'm weary giving unrestricted access to KVP usage.

There are already far too many users using inefficient methods when it comes to modeling, texturing and scripting.

I'm weary it will put a strain on the dataservers and increase our r/w times and/or cause random failures/timeouts.

I still believe access to grid-wide experiences & KVP usage should be put behind another paywall such as Premium Plus.

Feel free to hate. 🙂