Vehicles vs. sim crossings, why it's so awful

[animats]

1 hour ago, animats said:

I agree. This is to demonstrate that it's possible to fix the problem. It would be much better if LL fixed it sim-side.

I've discovered that sometimes it takes more than one teleport to get the avatar unstuck.

The useful insight here is that a region crossing is just a forced teleport followed by a forced sit, minus the swirling animation and the "whoosh" sound. The things that go wrong with region crossings are the same things that could go wrong with a forced teleport and a forced sit.

What really seems to happen in a region crossing is this:

1. Vehicle root prim goes outside the boundaries of a region. (Objects can temporarily be a little bit outside of their region.) This starts the region crossing process.
2. The vehicle is teleported to the new sim, at the same global grid coordinates. That means if it was, say, at SIM A/-5/128, it moves to SIM B/251/128, which is the same location in global grid coordinates. 
3. The old sim tells all the avatars sitting on the vehicle to teleport to the new location of the vehicle in the new sim.
4. The vehicle starts moving in the new sim, before all the avatars get there. (You can often see this happen on a fast region cross.)
5. As each avatar arrives in the new sim, it is ordered to force sit on its old seat. But that seat is a moving target, because the vehicle is already moving. (Sometimes it takes a while to catch the target. You can sometimes see the avatar chasing after the vehicle and being re-seated.)

Trouble occurs when the avatar can't catch up to the vehicle. This is why double region crossings often fail. Vehicle is teleported from sim A to sim B, avatar starts teleport from sim A to sim B, vehicle moves out of region B into region C, vehicle starts teleport to region C, avatar arrives in region B, avatar is ordered to sit on a vehicle no longer in that sim, avatar gets stuck in sim B.

The bug is that the current sim side code just gives up when the sit fails, leaving the user with a stuck avatar. That's no good. It's necessary to  detect that the avatar forced sit failed, find the vehicle, teleport the avatar there, and try to sit it again. I'm doing that with scripts and RLV, which is clunky, but indicates that the sim has all the information it needs to fix the problem. It's interesting that a script in the vehicle can do a llTeleportAgent on an avatar attached to the vehicle even though the avatar is in a different region. The vehicle script still has control over all the disconnected parts.

 

Edited January 31, 2018 by animats

[animats]

Test motorcycle with automatic region crossing recovery

This is an experimental bike and may have problems.

After all the discussions of region crossing problems, here's the solution, now in test. This bike has all the fixes.

We usually leave a free motorcycle with these fixes parked at Vallone/209/23/36. Look for a bike with yellow and black angled stripes.
This identifies our current test bike. Feel free to take a copy.This bike deals with both half-unsits and the animation and camera problems mentioned previously.It's been driven all over Heterocera and Kama City, usually around 20m/s, or 45mph. Don't bother slowing down for region crossings.

Use of this bike requires wearing an RLV relay which will allow a forced sit to get fully automatic recovery from a half-unsit.
We use "DM2-Meter V3.027", which is intended for combat games. (There's usually a crate next to the parked bike which can be copied to get one. Once worn, it brings up a HUD display at top center, allowing the RLV features to be turned on and off. When that display is red, the RLV features are available. Note that this allows others to exercise RLV control over your avatar, but you can turn this relay off easily.) If you don't bother with the RLV relay, you can still ride the bike, and a half-unsit will teleport you back to the bike. But you don't get re-seated.

When you get on the bike, it will ask for teleport permission. It uses that to teleport you back to the bike if you come off at a region crossing. Pressing PAGE DOWN will trigger a test of the teleport/resit sequence. It will be triggered automatically should a half-unsit occur. Re-sitting is not yet reliable, but if it doesn't work, get off the bike and get back on to reset. Report problems to "animats" in Second Life. Video of problems would be appreciated.

This a test vehicle. That's why the yellow and black stripes. It tends to go airborne at high speeds, and isn't useful for racing. But it will get you around Second Life.  Try it and go drive around.

This is a workaround. It would be better if LL fixed this on their side. We have a paper on what's needed. While we're waiting for Linden Labs, have some fun driving.

Edited February 3, 2018 by animats
Fix spacing

[animats]

Still working on region crossings. If you took a copy of the test bike, please take another one; there have been improvements. You can get one at the Animats bike shop in Vallone. Just do a "take copy" on the bike with yellow and black stripes, and take a copy of the crate nearby for a compatible RLV relay. There are instructions on a note card in the crate. This is still experimental; no guarantees, and it's all free. I  and some friends go riding around on these bikes regularly and we don't slow down for region crossings. IM me if something funny happens. Video and a copy of the messages in the chat window helps. If the recovery can't get the avatar back on the bike, I need to know where the bike was (this is printed in chat) and where the avatar ended up (from the top bar in the viewer).

I've been testing more around that troublesome SLRR sim crossing near Aglia/143/151/84.

My recovery system won't work there, because that Linden Labs owned parcel has a teleport landing point set on the SLRR right of way. When the bike uses RLV to teleport the avatar back to the bike, the avatar goes to the landing point, Agila (62,211, 83), instead of the bike's location at Aglia (1,253,85). The avatar is then too far from the bike and can't be re-seated. No idea why somebody set the parcel's landing point there. It's not a station or point of interest, just a spot on the tracks. The track sections on both sides have no landing point.

These bikes show that recovery from bad sim crossings is possible. A permanent fix for this has to be sim-side. What you can do with scripting is limited; there are many permissions problems. If you have trouble at a sim crossing on a parcel that doesn't allow object entry, your bike can be ejected by the parcel while you're being re-seated. You end up standing where the bike was, but without a bike. And there's the hassle of having to wear an RLV relay. It still beats being stuck in the air at a region crossing.

[animats]

If you're really into this, I suggest reading the Linden Labs patent on regions. Especially section [0144] and Fig. 20. That's oversimplified, but useful.

[animats]

An amusing special case in region crossing recovery. The bike script detected that a region crossing had failed. So it used RLV to teleport the avatar back to the bike, then did a RLV force sit on the bike. But the bike is straddling a region boundary. The sit target is in the wrong region. So the avatar ends up sitting on the front wheel. Oops. 

Getting close, but not there yet.

[Kia Kiyori]

I might not (read 'definitely don't') understand the tech details, animats, but I sure do appreciate what you're doing for the benefit of vehicle users

[animats]

10 hours ago, AnyaJurelle said:

I might not (read 'definitely don't') understand the tech details, animats, but I sure do appreciate what you're doing for the benefit of vehicle users

Thanks.

[animats]

More technical stuff. I'm posting this mostly for the benefit of other developers.

I've finally found a way to generate region crossing failures for test purposes. I have a bike script which, when told to do so, endlessly circles the intersection of four regions without requiring any user action. This causes a region crossing every second or two.  I run this in an empty adult/premium four sim sandbox. At last, test automation.

Region crossing failures tend not to happen in empty sandboxes. I've run this for 1000 region crossings without a failure. CPU load on my end does not matter. Running four copies of memtester (this is Linux, Ubuntu 16.04 LTS) does not cause problems.

If I load up the network (connection is 50mb/s down, 5mb/s up, on Sonic, which has no middle boxes or traffic shaping), by running an endless loop of speed tests, I'll consistently get a region crossing failure within five minutes. At last, the ability to do repeatable experiments.

And a useful insight. It's network loading that triggers the problem. Avatar complexity, vehicle complexity, script complexity, and scene complexity, which have been thought to cause region crossing problems, all run up network usage, and may make a failure more likely. But the underlying problem seems to be related to network capacity.

Work is proceeding on automatic recovery from half-unsits. There are a lot of cases:

• Sometimes unsit recovery works successfully.
• Sometimes the avatar is so far from the bike, beyond llShout range (100 meters) that the bike script can't reach the RLV relay to tell it to teleport the avatar back. This is going to need a back-up communications system (llEmail, maybe) for when that happens.
• Sometimes the bike disappears from the sandbox while the rider is being re-seated. This is a problem with the sandbox not allowing object entry. When the rider gets off, the bike is considered to have "entered" the sim, even though it was already there. Linden roads usually aren't set up that way, so this is more of a sandbox problem.
• There's the "bike straddling region crossing" problem mentioned in a previous post. The bike will probably have to move itself into a single region before triggering the recovery process.
• There are occasional script error messages about inability to start an animation because the script can't find the agent. This is harmless but annoying. It's not about losing permissions; that's already covered. There are some strange situations that exist momentarily during every region crossing. It may help to delay animation restart until 1-2 secs after region crossing completion.

This testing uses a modified RLV relay. Unsit recovery is going to require its own attachment, much like a RLV relay, but more limited. The only thing it will do is re-sit the avatar where it was previously sitting. This will run on a different communications channel so as not to interfere with RLV. I'm thinking of call it "Seat Belt". When you get in/on a vehicle equipped with this, you'll be offered a Seat Belt attachment if you don't already have one. If you put it on, you'll get recovery capability. None of the hassles of wearing an open RLV relay.

All this is a workaround. The real problem seems to be in the message exchanges between the sims involved and the viewer. Delaying or losing some message(s) can break a sim crossing. The viewer actually plays a role in managing region crossings, one of the Lindens mentioned in the Server User Group meeting. This is unexpected; "never trust the client" is a rule in client/server games.  SL apparently does trust the client. Has anyone looked at that code in the viewer?

[Klytyna]

11 hours ago, animats said:

This testing uses a modified RLV relay. Unsit recovery is going to require its own attachment, much like a RLV relay, but more limited. The only thing it will do is re-sit the avatar where it was previously sitting.

Using RLV/RLVa for this is essentially stupid... many of SL's inhabitants do not use either, and many do not use a viewer that supports either.

SMART thing would be to use EXPERIENCE code, which can sit an avatar without RLV, even in the Official SL Inferiority Viewer.

However...

11 hours ago, animats said:

Sometimes the avatar is so far from the bike, beyond llShout range (100 meters) that the bike script can't reach the RLV relay

Why the hell are you using llShout? You should be using llRegionSayTo, which isn't range limited, and runs fractionally faster too ( no range checks to execute).

11 hours ago, animats said:

This is a problem with the sandbox not allowing object entry. When the rider gets off, the bike is considered to have "entered" the sim, even though it was already there. Linden roads usually aren't set up that way

Actually, a prim vehicle entering a parcel is considered to be "object entry" regardless of it having an avatar sat on it, it's a common cause of vehicle failure, you are flying along, you cross a parcel boundry, but your vehicle can't get in and you go through the windscreen or over the handlebars... Hehehe...

11 hours ago, animats said:

This testing uses a modified RLV relay. Unsit recovery is going to require its own attachment, much like a RLV relay, but more limited.

Another reason NOT to use RLV, the need for an extra attachment. And let's not even start on the fact that some people will ALREADY be wearing a relay and there will be conflicts.

11 hours ago, animats said:

None of the hassles of wearing an open RLV relay.

Like HAVING to use an RLVa enabled viewer? Many people don't, and even amongst those that do, many won't enable it.

So, Experience Keys, and llRegionSayTo...

 

[animats]

Using RLV/RLVa for this is essentially stupid... many of SL's inhabitants do not use either, and many do not use a viewer that supports either. SMART thing would be to use EXPERIENCE code, which can sit an avatar without RLV, even in the Official SL Inferiority Viewer.

Only on land enabled for that experience. There are some LL-sponsored grid-wide experiences, but LL had to enable that. In the early stages of this, RLV seems to be the way to go. Or having the avatar wear an attachment which uses llTeleportAgent.

 

Why the hell are you using llShout? You should be using llRegionSayTo, which isn't range limited, and runs fractionally faster too ( no range checks to execute).

llRegionSayTo is limited to the current region. llShout can cross a region boundary. This problem always involves at least two regions, obviously.

 

Actually, a prim vehicle entering a parcel is considered to be "object entry" regardless of it having an avatar sat on it, it's a common cause of vehicle failure, you are flying along, you cross a parcel boundary,  but your vehicle can't get in and you go through the windscreen or over the handlebars... Hehehe...

A few places are set up to have this problem. Go to sandbox Bricker.   This is a four-sim Linden sandbox. (Adult, paid, usually empty) Rez a vehicle. Drive it across a region boundary. Get out of the vehicle. The vehicle will disappear and be auto-returned. If you get out in the original region, the vehicle stays around.

Sandbox Bricker.  Object entry for Everyone is OFF. But Build for everyone is ON. Vehicle disappears after crossing a region boundary and driver gets off. This is an unusual permission combination.

Sandbox Astutula (General, non-paid. 4 regions). Object entry for everyone is ON. Vehicle stays around after crossing a region boundary and driver gets off. That's reasonable for a sandbox.

Roads are usually Build OFF, Object entry ON, which doesn't create this problem. It's mostly a limitation of that particular sandbox. It may be for griefing protection.

 

Another reason NOT to use RLV, the need for an extra attachment. And let's not even start on the fact that some people will ALREADY be wearing a relay and there will be conflicts.

That's what channels are for.

(Does this person even program?)

[Qie Niangao]

On 2/17/2018 at 4:31 PM, animats said:

• Sometimes the bike disappears from the sandbox while the rider is being re-seated. This is a problem with the sandbox not allowing object entry. When the rider gets off, the bike is considered to have "entered" the sim, even though it was already there. Linden roads usually aren't set up that way, so this is more of a sandbox problem.

This no-object-entry condition is a little more common than may be apparent. Most of the Linden routes do indeed allow object entry, but Zindra is conspicuously different. Some of the Kama City sims were changed to permit it (specifically to allow unmanned Yavapods to circle some of those regions) but for example the road bordering Vallone on the north is no-object-entry on the Selano Beach East side, as is the case for the majority of Zindra.

I believe object entry to roads and water of the Horizons regions (attached to Zindra) are similarly restricted.

This probably doesn't substantially matter to your project, but just FYI in case it comes up.

[animats]

3 hours ago, Qie Niangao said:

Most of the Linden routes do indeed allow object entry, but Zindra is conspicuously different. Some of the Kama City sims were changed to permit it (specifically to allow unmanned Yavapods to circle some of those regions) but for example the road bordering Vallone on the north is no-object-entry on the Selano Beach East side, as is the case for the majority of Zindra.

I believe object entry to roads and water of the Horizons regions (attached to Zindra) are similarly restricted.

This probably doesn't substantially matter to your project, but just FYI in case it comes up.

Yes, I just looked. Half that road allows object entry, and the other half doesn't.

Kama City's road construction is strange. A region crossing in the center of every street, of course. Even stranger is how intersections are put together. Try de-rendering one layer by layer. There are three circular translucent objects below pavement level which cross region boundaries but don't seem to do anything. It's not clear whether someone was trying to fix the "sinking into the ground" problem incorrectly, or had something else in mind.

[Qie Niangao]

7 hours ago, animats said:

There are three circular translucent objects below pavement level which cross region boundaries but don't seem to do anything. It's not clear whether someone was trying to fix the "sinking into the ground" problem incorrectly, or had something else in mind.

I never noticed those before, but I suspect that was the intent because they're named "intersection crossover" -- but if so they can't have been very effective, buried a half meter or so below the road surface. On 4-way intersections there seem to be four of them, one in each sim. 

They're physics hogs, at a weight of 444 each, and based on how they look in wireframe I'd guess them to be twisted Tubes. Back when prim dimensions were capped at 10 meters, there were tricks to get larger coverage from basic prims using various twists and shears; these may have used a version of that. (Ironically, we were told that the 10m limit was to control load on the physics engine.)

[animats]

More technical stuff.

I commented previously that network lag can cause region crossing failures. I now have more precise tests for that.

Network lag of 1000ms (1 second, lag meter turns red) will produce a quick fail at a double region crossing. It may take a few tries,
but a few minutes of driving in a circle around a 4-way region crossing seems to trigger it consistently. Even in an empty sandbox.

I'm on Linux (Ubuntu 16.04LTS), and Linux has a command for introducing network lag for test purposes. The shell command

sudo tc qdisc add dev eth0 root netem delay 1000ms

adds 1000ms of delay to every packet, and the next double region crossing on a vehicle fails quickly. Even in a quiet sandbox. Failure means the
avatar ends up in the air, can't unsit, and the next teleport produces locations such as "Vallone (-156721, -71944, 100)"

You turn this mode off with

sudo tc qdisc del dev eth0 root

 which stops the lag, and region crossings start working again.

It takes a lot of lag to trigger this. 500ms (viewer network lag meter goes yellow) won't do it, but 1000ms (network lag meter goes red) will. Most SL functions can tolerate a 1000ms lag; they just become sluggish. But not region crossings.

This is pure packet delay. No packet loss, no reordering. I've tried forcing packet re-ordering; that doesn't seem to cause trouble.  Basic SL operations still work with 1000ms delay; you can walk around, but it will take a second or two for any response to controls. Avatar-alone region crossings still work. But not double region crossings with vehicles.

In regular usage, a 1000ms delay is unusual but possible during moments of high network load. If you watch the viewer's network load meter, you may see it flash red occasionally, especially on slow connections. If one of those slow network moments happens to coincide with a double vehicle region crossing, you're toast.

I'm trying to diagnose the problem well enough that LL can fix it. Their resources are limited, they admit. This bug has been outstanding for years because it was hard to reproduce. Now it's easy to reproduce in a controlled test situation. This makes it a repeatable, testable bug. Such bugs are fixable.

Edited February 21, 2018 by animats
Did more testing.

[Klytyna]

On 18 February 2018 at 8:23 PM, animats said:

Only on land enabled for that experience. There are some LL-sponsored grid-wide experiences, but LL had to enable that. In the early stages of this, RLV seems to be the way to go. Or having the avatar wear an attachment which uses llTeleportAgent.

You are currently alpha testing a klunky kludge fix using a customised rlv relay (that you seem to know very little about rlv isn't encouraging, thiose comments about 'open relays').

LL will NEVER endorse or support an rlv/rlva based fix for vehicle crossings, nor will most vehicle makers be willing to rewrite all their scripts to use rlv on a custom channel, and such a channel will leak out and social undesirables will attempt to use it as a backdoor relay channel for nefarious purposes. 

However, an experience based system could be something they would agree to implement on their "no perms asked for or needed" grid wide experiences, like the ones they use in their portals for example.

...

If you MUST use rlv/rlva, I'd suggest binningthe relay entirely. Worn attachments do NOT need relays to control the wearers rlv enabled viewer at all. so instead of trying to get rlv in all the vehicles, then using some lame ass custom relay to pick up on channel spam, just write an rlv hud that allows you to indicate the vehicle you are on and which will then attempt to resit you on that if you come off.

On 18 February 2018 at 8:23 PM, animats said:

llRegionSayTo is limited to the current region. llShout can cross a region boundary. This problem always involves at least two regions, obviously.

You should only be trying to force sit an avatar on a vehicle when they are BOTH in the same region anyway, so that's not an issue or shouldn't be if you were doing this right.

In addition, regionsayto is PRIVATE, goes directly to the target alone... Shout goes to every scripted listener in 100 m range, which must then trigger listen events, and do the whole laborious process of checking source channel number, source authorisation and syntax parsing to see if what your channel spam is shouting is something they need to deal with.

regionsayto for pros, shout for junior apprentice lag-makers.

On 18 February 2018 at 8:23 PM, animats said:

That's what channels are for.

(Does this person even program?)

Oh, and I am confident I've written a damn sight more rlv code than you have... If you plan on using rlv/rlva, try asking people who use it and code it regularly, people like Innula for example, or me.

6 hours ago, animats said:

I'm trying to diagnose the problem well enough that LL can fix it. Their resources are limited, they admit. This bug has been outstanding for years because it was hard to reproduce. Now it's easy to reproduce in a controlled test situation. This makes it a repeatable, testable bug. Such bugs are fixable.

I TOLD you what the lag problem in crossings was back on page 1 of the thread, when I outlined the process by which an avatar is moved from region to region. Part of it is basically the whole sorry business of rezzing your bald naked ruthed carcas, then sucking down your inventory list, and figuring which items are going to be attached, then starting up all the scripts in them using stored script memory states.

I've seen over scripted avatars (400 plus scripts running 1200 ms cpu time, push their cpu time to OVER 9999 ms on entering a sim, how much over is hard to say, my meter only ran to 4 digits, but typically, you can expect an avatar entering a new region to have its script cpu times run up to 800-900% over 'normal' while everything loads from the asset servers. 

That's where your lag is coming from, the new region sucking down data from the asset server system so it knows what you have and what of that is actually attached and what state its in, EVERYTIME you cross a boundry, so driving in circles where 4 regions meet...

You are leaving one region before it's finished receiving you from the previous region... BOOM

It's time to STOP doing things the "31 flavours of Whinux" way and think SMART not HARD.
 

[animats]

I'm now trying a much simpler solution.

The big problem, as is well known, is starting a new region crossing before the previous one is finished. We can now do that without slowing down before the region crossing. I have a vehicle which, when it gets the "changed" event that indicates a vehicle region crossing, stops the vehicle hard by turning off physics. That holds the vehicle locked in place until the avatar has made the crossing and is re-seated. Then it turns physics back on and restores the previous velocity. Typical wait times at single region crossings are 40-150 milliseconds. The user sees this as a slightly longer region crossing pause than usual.

This avoids a too-fast region crossing without adding unnecessary delay. If the sim is slow or there's network lag, it will wait longer, as needed, until all the avatars catch up. If you're making an region crossing nowhere near another region boundary, we can probably skip the hold completely. Racers will want that.

It's possible to fail a double region crossing, but I have to add 1000ms of packet delay on the network, using network test tools, and slam into the center of the X where four regions intersect at above 50mph to break it. That creates a race condition where there are two region crossings before the "changed" event reaches the script and stops the vehicle. Then I get the "half-unsit" bug. An automatic slowdown when headed for a circle about 4-5m in radius around a region crossing should prevent this.

More testing is needed. Multi-passenger vehicles and aircraft need to be tested. But so far, so good. Works in the sandbox, works on the road.

[animats]

More progress. Did about 15 sim crossings with two avatars on a bike. Sometimes there's a stall of about 1.5 secs while both avatars catch up, but then we go. The script for this pauses the vehicle until all avatars are properly seated after the region cross, so this should work for many-passenger vehicles.  I need to load up a bus with avis and take video.

There is a difference between "two sim crossings too fast", and "two sim crossings that overlap". The first seems to be fixed by this, which waits for sim crossings to finish. For the second, you have to be within about 2-3 meters of the junction of four sims. More on that later. I may just force speed way down when very close to a junction. I'll know after more testing.

I have a retrofit script that I can stick in existing vehicles. You don't have to modify the existing scripts, just add this one. Possible aftermarket product.

[Prokofy Neva]

Re: You are currently alpha testing a klunky kludge fix using a customised rlv relay (that you seem to know very little about rlv isn't encouraging, thiose comments about 'open relays').

LL will NEVER endorse or support an rlv/rlva based fix for vehicle crossings, nor will most vehicle makers be willing to rewrite all their scripts to use rlv on a custom channel, and such a channel will leak out and social undesirables will attempt to use it as a backdoor relay channel for nefarious purposes. 

Yes, this is one of those extremely rare cases when I'd agree with Klytyna

Why is BDMS coming out of the bedroom into the public roads? That's really the question to ask here.

Many people in SL, including myself, who repudiate BDSM as an ideology will still, in the name of individual freedom and choice, tolerate BDSM as an individual social choice by people for their private lives, including in a virtual world.

But they will not tolerate it being imposed on them in any way in the public sphere.

And that's what is happening here.

Often I see in RL as in SL a certain ideological gambit to normalize BDSM and impose it on the public sphere, where it begins to encroach on the individual rights of others -- by finding some means, such as with "50 Shades of Grey" of making it seem "okay". There's the issue, for example, of doms who parade around women in chains grovelling to them at various merchants' events or public events. That makes people uncomfortable for sure. But there's always that pushing of the envelope by some. And when they push their envelope, it's perfectly fine to push back and say the public sphere has to be free of coercion.

There's the other issue of people who view Second Life as a platform sandbox for them to implement their fantasies of platform influence and control, even as other people have a different immersive take on SL and seek to have a private live on a sim without platformistas harassing them -- this is an old debate that one can find on the old forums in 2004-2007.

There's also this: the Lindens have been working on sim seams since the dawn of time.

I recall Philip once explained to me in copious detail, using napkins at at lunch during the SL meet-up in Chicago, what the problems were in the sim seam challenge. You know child thingie looking into the next sim, a hand off thing, a this, a that, or -- as the Russian fairy tale characters say: go-there-I-know-not-where, fetch-that-I-know-not-what.

Remember, Philip had a degree in physics, he wasn't just a computer engineer.

In a thread last year, Klytyna describes what hampers these crossings.

And here a man named Chaser Zaks gives a very good explanation of what the issue is in the sim crossings -- perfectly comprehendable by the layman.

Of course, Klytyna, as I know from repeated personal experience can shoot down somebody's idea or attempt to understand a thing or get action on it and newbies can suffer from this sort of hazing on the forums. But there's hazing in the other direction, too, when somebody thinks they can build a better mouse-trap AND impose it on the public. As animats has made clear, it's not just that he is experimenting with his own personal cars and scripts to explore -- that would be one thing. His aim is to add a fleet of driverless cars to roam around the sims, joining the other spam on the roads, and find problems and then alert residents or Lindens to fix them. And I for one find that as onerous, and I think others would, too. I think these concerns should be addressed in the form of a ticket to the Lindens, on a case-by-case basis, by those directly affected.

 

Edited March 1, 2018 by Prokofy Neva

[Callum Meriman]

On 2/28/2018 at 5:51 PM, animats said:

I'm now trying a much simpler solution.

The big problem, as is well known, is starting a new region crossing before the previous one is finished. We can now do that without slowing down before the region crossing. I have a vehicle which, when it gets the "changed" event that indicates a vehicle region crossing, stops the vehicle hard by turning off physics. That holds the vehicle locked in place until the avatar has made the crossing and is re-seated. Then it turns physics back on and restores the previous velocity. Typical wait times at single region crossings are 40-150 milliseconds. The user sees this as a slightly longer region crossing pause than usual.

That sounds like a better idea.  

[Qie Niangao]

4 hours ago, Prokofy Neva said:

There's also this: the Lindens have been working on sim seams since the dawn of time.

That's the thing: There's over a decade of bug reports related to sim crossings, with no discernible progress made in addressing the problem.

We've all assumed, reasonably, that Linden developers would be best equipped to fix this if anybody could, and nothing has happened.

What we have to show for it is a decade of napkin diagrams and hysterical hand-wringing about what a complex problem this is, enough that Rosedale so convinced himself that it was intractable that he nerfed from High Fidelity the whole idea of Domain crossings, a self-crippling decision that propagated to Sansar Experiences. (He's joined the blockchain-babbling set now, so High Fidelity's future faces much graver threats than Domain crossings.)

Honestly, this work by animats is the first encouraging thing I've seen on this problem in all this time. I could wax philosophical about why his approach is getting results when others have gotten nowhere, but that's the main advantage of his approach: f*ck the philosophy and get on with it.

[animats]

The number of different things that go wrong is surprising. It's not one big problem; it's a lot of little ones.

All these problems appear to the user as totally bogus motion. That confused the problem and prevented work on it. Fixing the Firestorm viewer to not mis-extrapolate at region crossings was my first real fix. After that, the different bugs started to look different. That makes working on them possible.

The remaining tough problems involve double region crossings. So far, I've been able to minimize those, but not eliminate them. I still get errors with a high-speed cross within about 3-4m of the junction of four sims.  Further out than that, the new "pause on change event until avatars catch up" script code prevents the second region crossing from starting before the first one finishes. The pause is usually under 100ms. Close to the junction, the change event and pause don't happen soon enough. I'm probably just going to force a brief slowdown when you're headed very close to a region corner. That's a rare event, unless you're making a left turn in Kama City.

Blasting out of trouble with multiple teleports in sequence does work, but it looks ugly, takes a while, and requires a vehicle and avatar attachments operating in coordination. I filed a JIRA asking LL to make "unsit" work reliably. If they can't fix region crossings in general, maybe they can fix "unsit" so you can at least get unstuck when things go bad.

SL region crossings are supposed to be a "consistent eventually" distributed system. Momentarily,  things will get out of sync, but then should get back in sync. This  involves passing messages back and forth until everybody is in agreement again. When SL was designed, "consistent eventually" systems were unusual. Now there's more theory around that, because that's how some distributed databases work. SL's designers, back in the 1990s, didn't have the benefit of that knowledge.

Meanwhile, I've been making road trips in SL, usually around 50MPH, without problems. The big virtual world is fun to explore. In no other virtual world can you drive for an hour, seeing new things, without going in circles.

(Finding a place to park when you find an interesting place to visit can be a hassle. Please, if you build a parking lot, make it usable. Parking spaces with fast auto-return are pointless, especially in front of retail stores.)

SL has parking meters. They work just like parcel rental boxes, but shorter term.

 

[Grumpity Linden]

4 hours ago, animats said:

(Finding a place to park when you find an interesting place to visit can be a hassle. Please, if you build a parking lot, make it usable. Parking spaces with fast auto-return are pointless, especially in front of retail stores.)

SL has parking meters. They work just like parcel rental boxes, but shorter term.

 

Alright then, there's my TIL for the day. 

[sirhc DeSantis]

'SL has parking meters...' what a neat little earner. Wish I'd thought of that. In all my trundling around the mainland I always relied on making a note (initially by eye now sometimes with a little attachment that read parcel perms and grabs its details for retrieval later) and heading back there if I decided to have a wander on foot or the vehicle orbitted etc.

[Prokofy Neva]

On 3/1/2018 at 4:24 AM, Qie Niangao said:

That's the thing: There's over a decade of bug reports related to sim crossings, with no discernible progress made in addressing the problem.

We've all assumed, reasonably, that Linden developers would be best equipped to fix this if anybody could, and nothing has happened.

What we have to show for it is a decade of napkin diagrams and hysterical hand-wringing about what a complex problem this is, enough that Rosedale so convinced himself that it was intractable that he nerfed from High Fidelity the whole idea of Domain crossings, a self-crippling decision that propagated to Sansar Experiences. (He's joined the blockchain-babbling set now, so High Fidelity's future faces much graver threats than Domain crossings.)

Honestly, this work by animats is the first encouraging thing I've seen on this problem in all this time. I could wax philosophical about why his approach is getting results when others have gotten nowhere, but that's the main advantage of his approach: f*ck the philosophy and get on with it.

No. Klytyna is right about this. Any solution that means subjecting the whole population of SL to a BDSM viewer and its works is by definition wrong and I do hope the Lindens would grasp wh

The sim seams aren't the horror imagined or portrayed by animats in his bid to be the saviour who fixes it.

Lots of people drive or ride around, including myself, and this doesn't bother them. There are all kinds of vehicles to try with varying degrees of skill and capacity and that's part of the fun of it.

The obsession of Philip or the inability of Lindens to "solve it" is kind of a myth, but in fact, they've improved it steadily and it really isn't the most important thing for the Mainland.

Blight of land, failure to move abandoned land, curbing of spam cars -- those are all more important problems and enabling this BDSM kludge only distracts from these other issues.

[Prokofy Neva]

13 hours ago, animats said:

The number of different things that go wrong is surprising. It's not one big problem; it's a lot of little ones.

All these problems appear to the user as totally bogus motion. That confused the problem and prevented work on it. Fixing the Firestorm viewer to not mis-extrapolate at region crossings was my first real fix. After that, the different bugs started to look different. That makes working on them possible.

The remaining tough problems involve double region crossings. So far, I've been able to minimize those, but not eliminate them. I still get errors with a high-speed cross within about 3-4m of the junction of four sims.  Further out than that, the new "pause on change event until avatars catch up" script code prevents the second region crossing from starting before the first one finishes. The pause is usually under 100ms. Close to the junction, the change event and pause don't happen soon enough. I'm probably just going to force a brief slowdown when you're headed very close to a region corner. That's a rare event, unless you're making a left turn in Kama City.

Blasting out of trouble with multiple teleports in sequence does work, but it looks ugly, takes a while, and requires a vehicle and avatar attachments operating in coordination. I filed a JIRA asking LL to make "unsit" work reliably. If they can't fix region crossings in general, maybe they can fix "unsit" so you can at least get unstuck when things go bad.

SL region crossings are supposed to be a "consistent eventually" distributed system. Momentarily,  things will get out of sync, but then should get back in sync. This  involves passing messages back and forth until everybody is in agreement again. When SL was designed, "consistent eventually" systems were unusual. Now there's more theory around that, because that's how some distributed databases work. SL's designers, back in the 1990s, didn't have the benefit of that knowledge.

Meanwhile, I've been making road trips in SL, usually around 50MPH, without problems. The big virtual world is fun to explore. In no other virtual world can you drive for an hour, seeing new things, without going in circles.

(Finding a place to park when you find an interesting place to visit can be a hassle. Please, if you build a parking lot, make it usable. Parking spaces with fast auto-return are pointless, especially in front of retail stores.)

SL has parking meters. They work just like parcel rental boxes, but shorter term.

 

Lots of people already drive all over the place on all kinds of vehicles and animals. Real people. Not spam cars. And they aren't bothered by sim seams nearly as much as implied by all these posts. It's not a big deal. No one needs to save us from them.

I've built parking lots. All over. And since my groups are open, it doesn't matter what the autoreturn is, and I wouldn't extend that merely to enable griefers and litterers to succeed. There are good reasons why some don't want to take instruction from those who think they have a better idea: they have experience inworld.

 

Edited March 2, 2018 by Prokofy Neva