Inter-region script communication

[animats]

As part of my work on workarounds for region crossing problems, I need for a vehicle script to be able to talk to seated avatars during the semi-broken condition of a half-unsit, where a region crossing has failed. I want to tell the avatar to teleport itself back to the vehicle. This works when vehicle and avatar extension can communicate. The communication is a problem:

• llShout will work up to 100m across region boundaries, but sometimes the avatar is more than 100m from the vehicle. Seldom if ever more than a few hundred meters, though.
• llEmail has a lot of open bugs dated back to 2005. Discussions consider it broken.
• llTeleportAgent will work if the avatar is the owner of the vehicle. Otherwise not.
• llInstantMessage can't talk to an object.
• llRegionSayTo is only useful within a region.
• llMessageLinked can't talk to an attachment (and might not work when avatar and vehicle are in different regions, which is what this is all about)
• Setting up an external server for HTTP communication is a bit much. This isn't some big coordinated system under one owner.

Have I missed anything?

[Rolig Loon]

Maybe.  If you had access to an Experience that was active in both regions, you could use it to facilitate communication or simply to use llTeleportAgent.  I suspect that's unlikely to help much if you are driving around the grid at random, though.

You might try wearing a HUD that always sends your vehicle a quick ping message by llRegionSay (or llRegionSayTo) whenever you cross a region boundary.  If the vehicle responds, then it has clearly made it across the boundary with you.  If not, have the HUD issue its error message.

Edited February 17, 2018 by Rolig Loon

[Fluffy Sharkfin]

24 minutes ago, animats said:

Setting up an external server for HTTP communication is a bit much. This isn't some big coordinated system under one owner.

Rather than using an external server you could look into Object to object HTTP Communication although, as it mentions on that page 

Quote

since URLs are temporary, it is very hard (nearly impossible) to communicate to an object that crosses sim borders.

but since you asked if you'd missed anything I figured I'd mention it! 

 

[animats]

5 hours ago, Rolig Loon said:

You might try wearing a HUD that always sends your vehicle a quick ping message by llRegionSay (or llRegionSayTo) whenever you cross a region boundary.  If the vehicle responds, then it has clearly made it across the boundary with you.  If not, have the HUD issue its error message.

Yes. I've been thinking about doing more in an attachment and less in the vehicle. Ideally, the attachment would notice that the avatar was no longer seated properly, but hadn't explicitly done an unsit. Then it would teleport the avatar to the vehicle's current location and re-seat it, without any help from the vehicle. The problem is finding the vehicle from the attachment. In the half-unsit situation at a failed region crossing, the avatar is still a child prim of the vehicle, but the vehicle is no longer the root prim of the avatar. This inconsistent state occurs briefly at every region crossing. When a crossing goes bad, it persists. In that state, the avatar can't find the vehicle.

[animats]

5 hours ago, Fluffy Sharkfin said:

Rather than using an external server you could look into Object to object HTTP Communication although, as it mentions on that page

That's a good idea. But at the moment the scripts really need to communicate, one party just did a region crossing, and the other didn't. Or worse, at a double region crossing, both parties did region crossings, but not in sync. So communications have broken and are hard to reestablish.

How the SLRR does communications is insane. They have messenger prims, green spheres at 1000m, zooming around passing messages. That they went that far indicates how hard this is.

[Rolig Loon]

Systems like SLRR and various trolleys that follow preset paths have a relatively easy time because they travel between known waypoints. Your situation is only slightly more complicated, though.  After all, you know exactly where the vehicle crosses a region border.  At the instant of crossing, you can shout a message to the HUD attachment on your avatar, which can send its own location back as a ping. If the two locations are not identical, you can teleport the av to the vehicle.

[Nova Convair]

I don't see a solution.

If we assume that hud and vehicle get and exchange an url each - whenever they enter a new sim - then from the viewpoint of the hud:

- can communicate to vehicle by http if it is still in the old sim
- can communicate by llRegionSayTo if it's in the same sim
- need external server if it's in an unknown 3rd sim

Experiences are not useable since you need it enabled in all the sims you travel. That's only possible in very special cases like a multi-sim-racetrack.

For a reliable communication in all cases you need an external server.

[Xiija]

Dunno if this will help , but..

I've set up repeaters to carry messages between sims and as long as

all sims are contiguous it should work . The repeaters are placed about 5m

from the sim boarder, and about 10 meters from each other,

then they shout the msg over the border  to the next sim's repeater,

and it gets region-said thru the sim to repeaters on the next boarder, which shout it on... etc.

 

I've also used a channel number or inworld URL stored on a google doc, and fetched it with something like...

URL = "https://docs.google.com/document/d/(google doc ID here)/export?exportFormat=txt";

you would have to manually update the channel / url when it changes unless you have your main inworld server

post any new info it receives to a google form linked to a google spreadsheet etc.. ?

 

 

Edited February 19, 2018 by Xiija

[Qie Niangao]

On 2/18/2018 at 12:47 AM, animats said:

How the SLRR does communications is insane. They have messenger prims, green spheres at 1000m, zooming around passing messages. That they went that far indicates how hard this is.

Hmm. I wonder what you're describing here because I don't know of any "SLRR" communications. Just based on the green color, maybe SLGI? I don't know anything about how those work, but I can tell you how VRC does communications for the rail traffic maps (for SLRR, Bay City transit, ONSR, etc.).

Before Experiences, those used a hybrid of email and http; now it's http and Experience key-value store (programmed a bit like POSIX shm). The one-time-use traffic probes (which do traverse the track route at high altitude in order to do llCastRay in each region) use http with the servers that rez them, getting passed the stationary server's ephemeral URL when rezzed. Then the servers store the debounced traffic telemetry in the Experience key-value pairs for use by maps.

Because you won't have an Experience enabled for everywhere vehicles may wander, that's not going to be relevant to your case.

There will be some attrition of vehicles due to straying into no-script land; attachments may continue running scripts on no-script land, but not vehicles... but those vehicles are dead anyway, so nothing lost by not being able to find them for re-seating.

What you might do is more like what that system used before Experiences: When an attachment needs to communicate with a vehicle, it could send an llEmail to a fixed (preferably redundant) in-world registry of ephemeral vehicle URLs, identifying its own ephemeral URL on which to receive the response. The vehicles would update their URLs to that registry with every region crossing -- a lot of volume, so probably those updates would be llHTTPRequest()s to the registry's URL, learned by a preliminary llEmail.

The trick is to keep it scalable, which means never sending llEmail from a central node (20-second delay per message per script), and also directing HTTP so that requests come from distributed nodes (because llHTTPRequest is throttled per object, and per owner per sim).

Also, once in a blue moon, a sim will simply stop delivering emails to an address, which means the server at that address must be worn, carried to another sim and back, and dropped (not detached) back where it was to get the sim to resume delivering the backlog of email messages. After that has happened a few times, an external server may seem cost effective.

[animats]

4 hours ago, Xiija said:

I've set up repeaters to carry messages between sims and as long as all sims are contiguous it should work . The repeaters are placed about 5mfrom the sim boarder, and about 10 meters from each other, then they shout the msg over the border  to the next sim's repeater, and it gets region-said thru the sim to repeaters on the next boarder, which shout it on... etc.

I could see that for the SLRR, with microwave relay towers at each sim boundary along the right of way. Railroads once did that.

It would be amusing if someone set up a system of cell towers in SL, allowing grid-wide in-world communications for a small monthly service charge. No service to islands, though.

Edited February 19, 2018 by animats
Bad image/text position.

[Rolig Loon]

Well, as I suggested above, you may be able to fake something like that yourself.  When your vehicle is within, say, 2m of a region boundary, have it shout its location to your HUD.  As long as you are within 50m, even in the next region, the HUD will be able to hear it.  Verify that you are still on the vehicle.  If not, TP back to it.

[Qie Niangao]

Now I'm not sure why it's necessary to communicate at all. The HUD itself can keep track of where it's been lately, detect when it has CHANGED_REGION, check if the avatar is still seated (if llGetObjectDetails(llGetOwner(),[OBJECT_ROOT]) is a vehicle or the avatar), and TP if necessary.

Probably there's some part I'm missing.

[Rolig Loon]

True.  Even easier.

[Love Zhaoying]

All that’s left, is for you guys to write Animat’s code for them!

[Love Zhaoying]

1 hour ago, animats said:

would be amusing if someone set up a system of cell towers in SL, allowing grid-wide in-world communications

Those cell towers will go nicely with all the ad spam, abandoned parcels, and giant privacy walls.  The neighbors will absolutely love them!

[Anaimfinity]

On 2/19/2018 at 2:22 PM, Qie Niangao said:

Hmm. I wonder what you're describing here because I don't know of any "SLRR" communications. Just based on the green color, maybe SLGI? I don't know anything about how those work, but I can tell you how VRC does communications for the rail traffic maps (for SLRR, Bay City transit, ONSR, etc.).

Before Experiences, those used a hybrid of email and http; now it's http and Experience key-value store (programmed a bit like POSIX shm). The one-time-use traffic probes (which do traverse the track route at high altitude in order to do llCastRay in each region) use http with the servers that rez them, getting passed the stationary server's ephemeral URL when rezzed. Then the servers store the debounced traffic telemetry in the Experience key-value pairs for use by maps.

Because you won't have an Experience enabled for everywhere vehicles may wander, that's not going to be relevant to your case.

There will be some attrition of vehicles due to straying into no-script land; attachments may continue running scripts on no-script land, but not vehicles... but those vehicles are dead anyway, so nothing lost by not being able to find them for re-seating.

What you might do is more like what that system used before Experiences: When an attachment needs to communicate with a vehicle, it could send an llEmail to a fixed (preferably redundant) in-world registry of ephemeral vehicle URLs, identifying its own ephemeral URL on which to receive the response. The vehicles would update their URLs to that registry with every region crossing -- a lot of volume, so probably those updates would be llHTTPRequest()s to the registry's URL, learned by a preliminary llEmail.

The trick is to keep it scalable, which means never sending llEmail from a central node (20-second delay per message per script), and also directing HTTP so that requests come from distributed nodes (because llHTTPRequest is throttled per object, and per owner per sim).

Also, once in a blue moon, a sim will simply stop delivering emails to an address, which means the server at that address must be worn, carried to another sim and back, and dropped (not detached) back where it was to get the sim to resume delivering the backlog of email messages. After that has happened a few times, an external server may seem cost effective.

Sorry everyone to re-open this topic, but I wanted to give some info about the SLGI green spheres (SLGI trackers) which people mentioned here, especially for those interested in how they operate. 

HTTP related functions are the most high-lag of all lsl functions I've used. So, they must be used carefully. I conducted many experiments to ensure SLGI vehicles are among the most low-lag on the grid. Using an object-to-object communication system (and not with an external server) can reduce lag from HTTP scripts up to 10 times. However, the URL is lost at any sim crossing, which makes communication with a vehicle possible only in one way, from the vehicle to a fixed object. 

SLGI vehicles usually use an object-to-object HTTP communication system, which reports their positions to the map located at a base every 100 seconds. However, during sim restart processes or griefer attacks, communication fails between vehicles and the base. If that happens, trackers are automatically deployed. There are multiple types of trackers released. These trackers look like green spheres and travel at 1000 m altitude and are the fastest moving vehicles on the grid. One tracker can travel from Achemon (Heterocera) to Bay City and back in two minutes.

1. VEHICLE REPORTING TRACKERS. The base stores each vehicle's key at launch and holds it for a while. After multiple failures in HTTP object-to-object communication, trackers are released every 100 seconds for each vehicle that, according to schedule, should be running. They scan each sim for the target vehicle using llGetObjectDetails(vehicle_key,[OBJECT_POS]) and also record the name of the sim. If they find the target vehicle, they return to base and communicate their finding in chat. 

2. BLOCKED VEHICLE FINDING TRACKERS. They are released a few hours after a sim restart process and search for blocked vehicles (which get disoriented during a sim restart process and might end-up in nearby parcels with scripts disabled). These trackers also use the llGetObjectDetails function to detect lost vehicles and report me in chat their findings using llInstantMessage. In addition, running vehicles also perform a scan once every 5 days using a llSensor for the same purpose. If they detect a blocked vehicle with the same name as they have, they report to me. 

3. RESEARCH TRACKERS. They are released on demand or automatically released if vehicles don't return in time. They run along routes to check if sim crossings are safe, detect changes in land permissions (object entry, scripts, spare prims available) and also detect mass lag and griefer attacks. They use various functions for this. Those trackers released automatically report their findings in chat to the bases when they return. If they get stuck in a sim for more than 10 seconds, they also use the HTTP object-to-object communication protocol. Trackers released manually communicate to me using llInstantMessage. 

4. DELETER TRACKERS. I can manually release them. They look for running SLGI vehicles using llGetObjectDetails, each tracker being released for a target vehicle. They upload a script that contains llDie() function, removing vehicles from the grid. The way they upload scripts is the same way SLRR switchstands operate, with llRemoteLoadScriptPin. In fact, all SLGI vehicles, when released, have only an initializing script, after which the base relay uploads all scripts and navpoint notecards to them using this function. 

For 90% of time, trackers are not running, as vehicles report their position using an object-to-object HTTP protocol. 

Now, regarding the main topic, how to communicate between a vehicle and a lost passenger, the best approach I see is this: 

1. When an avatar sits on a vehicle, this can trigger a 'changed' event. If it is a CHANGED_LINK, a llSensor can be used to find the keys of any seated passengers (there are other more complex ways too, but this is easier). Store the passenger's key in memory. Then, if a passenger gets unseated, use another sensor and see which passenger is missing. The object can send a llInstantMessage to the lost passenger with its current position. 

2. Keep a llSensorRepeat for AGENT every 10 seconds. Record seated avatars with a 'changed' event and CHANGED_LINK. Keep the llSensorRepeat for finding if the passenger is still there. If two sensors fail (no_sensor is triggered twice or llSensorRepeat does not find passenger's key twice) send a llInstantMessage to the missing passenger with current vehicle's position. 

Both methods might fail as the unseated avatar might still be considered 'seated' by the simulator. However, after a number of seconds, you will get the correct results. 

Again, sorry everyone for re-opening this topic, but I thought that this information might be useful to someone. 

[Qie Niangao]

6 minutes ago, Anaimfinity said:

Again, sorry everyone for re-opening this topic, […]

I'm glad you did because it give me an opportunity to do some truth maintenance on something I said which is no longer correct:

On 2/19/2018 at 9:22 AM, Qie Niangao said:

Because you won't have an Experience enabled for everywhere vehicles may wander, that's not going to be relevant to your case.

In fact, Experience KVP (the persistent data store) is no longer locked to the land scope of the Experience itself, so grid-wide communications are possible using it as long as you can compile to an experience with some spare capacity in that relatively capacious store. It's roll-your-own message queueing protocol, and it's polled instead of async, but it's otherwise low overhead, broadcast, and very fast so it's perfect for single-sender / multi-recipient messaging but can easily be extended to multiple senders.

That's not exactly on-point to the original 2018 topic, but I wanted to mention it anyway because grid-wide object-to-object communication comes up often.

[BlueXBeta]

just curious about this: Why using object to object http and not simply using RegionSayTo? 

[Rolig Loon]

1 hour ago, BlueXBeta said:

just curious about this: Why using object to object http and not simply using RegionSayTo? 

llRegionSayTo only works within the current region

[PheebyKatz]

This is an awesome thread, I'm glad it came back up.