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

[Whirly Fizzle]

More test vehicles - Caith reduced all her planes to L$10 - https://marketplace.secondlife.com/stores/160269

[Callum Meriman]

17 hours ago, animats said:

 The velocity extrapolator was generating badly bogus results. You'd see motorcycles go sideways, into the air, into the road, through solid objects, and then snap back. The driver would reflexively make a steering correction based on the bogus motion they were seeing, and really screw things up.

I know that only too well, driving around the continents as much as I do. It's quite a bit of training to teach yourself not to react to messed up visuals of the sim change, but to keep powering on in the roads direction. To ignore the mess on the screen for those few seconds. Sadly, even tthat can put you off the side of the road into a ban line, especially on twitchy vehicles.

This patch really is a benefit for road use, I doubt I can go back to the normal behaviour there. The patch is destined to become part of my standard viewer roll-up.

17 hours ago, animats said:

I'm reading up on how sailboats work in SL. I suspect what broke the Shadow-X was seeing zero velocity in a script. The script thinks the boat is dead in the water, which messes up the sail calculations. I'm testing a version which doesn't do that.

The flying shadow x (from Dutch Harbor by the way) problem turned out to be the sim where I moor some of my boats not working for it only, rebooting that sim fixed the problem. Sorry for the false lead.

I was able to sail on it from SNO down around Nautilus, and back last night, a simple, mostly straight route, and your patch worked flawlessly. The stop isn't as disconcerting as it is on the Pride of Baltimore, or the N+K Frigate (which is available for demo in Wicktro - but it's very advanced to sail, four sets of left right steering to cope with) on a small sail boat I can live with the pause.

With all my testing, no unsitting yesterday, and only one camera loss which self recovered. That's something, if this new behavior helps.

I notice there is a variable number of bounces in the llObject part of this (infos message) but as it's not world, I think that's not a problem. Walking into a void sim border and watching the logs is a funny thing.

 

All in all, this is in the right direction, especially for motor bikes!

Edited January 2, 2018 by Callum Meriman

[animats]

1 hour ago, Callum Meriman said:

I know that only too well, driving around the continents as much as I do. It's quite a bit of training to teach yourself not to react to messed up visuals of the sim change, but to keep powering on in the roads direction. To ignore the mess on the screen for those few seconds. Sadly, even that can put you off the side of the road into a ban line, especially on twitchy vehicles.

Oh, yes. One of SL's major bike builders told me that some people just can't handle that at all and give up entirely on vehicles. I can understand why. You just can't relax and let your reflexes drive. It's worst for people who have good identification with the vehicle. I was just out riding my real-world horse, which gave me a chance to think about the mindset here. My current horse is a big, sensible warmblood I can relax with. I've owned some hot Thorougbreds, and I could never relax on those. At any moment, they might suddenly spook at something. Driving a vehicle in SL is like riding a flaky horse. The horse, though, has good self-preservation instincts, which SL vehicles do not.

I've been trying vehicles from Murasaki Creations in Burns. I just spent about half an hour riding one of their demo bikes. No unrecoverable problems. They have an amusing fix for the "unsit" bug. Unsits at a region crossing still happen; I had four in half an hour of fast riding. But the bike stops, and after about two seconds, the avatar is moved to the bike. First the avatar is seated badly. At that point you can drive again. Then the avatar is seated properly. Then the riding animation cuts in, and you're back to normal. Very nice. I made it back to the bike shop with the demo bike intact.

With my Firestorm fix, their bike consistently goes where you point it. I just hold down up arrow, and make a steering correction every second or two. No need to worry about sim crossings.

Quote

This patch really is a benefit for road use, I doubt I can go back to the normal behaviour there. The patch is destined to become part of my standard viewer roll-up.

Great!

Quote

The flying shadow x (from Dutch Harbor by the way) problem turned out to be the sim where I moor some of my boats not working for it only, rebooting that sim fixed the problem. Sorry for the false lead.

Also great! That had me puzzled and worried.

Quote

 

I was able to sail on it from SNO down around Nautilus, and back last night, a simple, mostly straight route, and your patch worked flawlessly. The stop isn't as disconcerting as it is on the Pride of Baltimore, or the N+K Frigate (which is available for demo in Wicktro - but it's very advanced to sail, four sets of left right steering to cope with) on a small sail boat I can live with the pause.

With all my testing, no unsitting yesterday, and only one camera loss which self recovered. That's something, if this new behavior helps.

After this fix, it may be time to look at camera control.  A big part of the annoyance with the stop at sim crossings is that the camera doesn't stop immediately when the object it's following does. It closes up on the object being tracked, then falls back after the object restarts. The idea is to have smooth camera motion, but the effect is terrible when you're driving. This is worse with aircraft, because they're faster, and the camera often overruns the aircraft and turns around, totally disorienting the pilot. If the camera stayed in position relative to a boat, in open water you'd barely notice the stall. Same for aircraft.

I pushed a new version of the Firestorm changes out to Github. With these, the sim doesn't stop animations and sounds, so movement sounds continue and flags and sails continue to flap even though the vehicle is stuck waiting for new instructions from the sim. This will help smooth out the sailing experience. I've tried it with the Destino cabin cruiser demo at Dutch Harbor, which is complex enough to take four seconds for a sim crossing. (That boat has a working instrument panel, shower and TV.) The most visible effect at slow sim crossings is that the wake changes. Please try that fix to Firestorm and let me know what you think. Thanks.

 

Quote

I notice there is a variable number of bounces in the llObject part of this (infos message) but as it's not world, I think that's not a problem. Walking into a void sim border and watching the logs is a funny thing.

Good that you're testing that. As you've probably noticed, the sim crossing clipping and edge of world detection now use common code.

Quote

All in all, this is in the right direction, especially for motor bikes!

It sure beats being blown off the road every two minutes.

[Callum Meriman]

4 hours ago, animats said:

After this fix, it may be time to look at camera control.  A big part of the annoyance with the stop at sim crossings is that the camera doesn't stop immediately when the object it's following does. It closes up on the object being tracked, then falls back after the object restarts.

Yes, I noticed this sailing. The camera lifts and falls just a tiny bit each time, it's clearly a fraction of a second lagged behind the object and catches up, then returns to normal.

 

Edit: it's not a huge jarring problem, I should say.

Edited January 2, 2018 by Callum Meriman

[animats]

I'm chasing down an obscure bug in this.

Murasaki Creations has a range of vehicles which recover from almost all serious sim crossing failures. You can get demo versions of them at their store. (Visit; it's a lot of fun,) They can handle the "unseated at sim crossing" problem. It's amusing to watch. Sometimes, at a sim crossing, the driver ends up on the ground. When that happens, there's a delay of a few seconds. Then the driver gets moved to the vehicle, but isn't seated properly. About two seconds after that, the driver gets seated in the right place, but isn't animated. About two seconds after that, the animations turn on, and you can drive off. This works very well.

But near a sim corner, where four sims meet, with my browser fixes, sometimes the recovery fails. The avatar ends up on the ground, unable to move. The vehicle is still in place on the ground, or driving off by itself. After a few seconds, the vehicle disappears.  It's not returned. A teleport will free the avatar. But until the next logout, the avatar takes 10 seconds at every region crossing instead of the usual half-second. No idea why. Most likely, the sim is looking for some essential but nonexistent asset, like the vehicle or a part of it, then times out.

Fortunately, I can reproduce this bug with a little rail car from Murasaki. Since it's running on tracks, it hits the sim crossing the same way every time. Here's the test spot where I hit two sim crossings very close together: http://maps.secondlife.com/secondlife/Telea/250/0/83. If you want to try this, get one of the free Railstar work cars from the vendor at Murasaki Creations. Go to the SLRR res area nearby at http://maps.secondlife.com/secondlife/Pini/139/59/94 rez the work car and head east. The trouble spot is next to a small platform with a hole and rope.

I'm curious about how they do the re-sit in the vehicle script. I didn't think an ordinary script could do that. An "Experience" can do a llSitOnLink, but regular scripts can't do that.

[Callum Meriman]

It's likely that the script is performing an llDie() to clean up should it detect something it can't recover from or the vehicle loses sight of the avatar on a sensor.

As to recovery, is there a place in the code you can infos sit/unsit? From many years of being unsat I wonder if one is still attached to the vehicle, still part of it's linkset. I say this as on a few vehicles I have, when one is detached and sliding over the ground parallel to the vehicle you also turn with the vehicle. That is, your new "unsat" location is still fixed in relation to the vehicle, just displaced (randomly) into the adjoining sim.

Eventually the vehicle moves on and you stop moving, while the vehicle continues on it's course over the world (furtherst I had was well over 100 sims of self-travel.)

But, sometimes when we unsit and then teleport into the sim where then vehicle is, one does end up sitting wrong. A reseat fixes that and you continue on.

If the unsat avatar is still part of the linkset then it would seem a position move and back would seemingly reseat them. Maybe the vehicle checks the avatars position, if it's outside of tolerance pauses the vehicle to allow the region to hand over better (maybe 5-10 seconds?) then moves the avatar to 0,0,0 after 2 seconds, then back to position after 2 seconds, then plays the animation again after 2 seconds.

And if it can't do that repositioning llDie() so the world isn't full of trash.

I think another way to check this could be a script dropped in the vehicle to report substantial changes between the root prim and avatar "prim"

Edited January 3, 2018 by Callum Meriman
clarified unsat avatar still part of the linkset

[animats]

2 hours ago, Callum Meriman said:

I think another way to check this could be a script dropped in the vehicle to report substantial changes between the root prim and avatar "prim"

I have a vehicle scripted to report that. On some unwanted unsits, the distance between root prim and avatar increases drastically, and on some it doesn't. Puzzling.

How do you do a reseat from a script? It's not supposed to be possible to force llSitOnLink() unless you're an "experience", according to the wiki.  But maybe it's allowed in more situations. If a script has PERMISSION_TRIGGER_ANIMATION it's reasonable to allow llSitOnLInk. Then a vehicle script could do an unsit followed by a sit to clean things up. it's also possible to force a sit via RLV, but that requires more permissions.

As for the rail car, I've now had that failure occur once with the current release Firestorm, without my mods. So I didn't break it entirely.  I'm trying to establish communications with the author of the script, but they may be long gone. They also say in their profile that they speak Japanese only. Nobody else seems to have this capability in vehicle scripts.

[Callum Meriman]

2 hours ago, animats said:

How do you do a reseat from a script? It's not supposed to be possible to force llSitOnLink() unless you're an "experience", according to the wiki. 

I am surmising, (and this is 100% speculation based on trying to think how this vehicle could possibly do what you describe... and what I've noticed over the years), that you are not actually 100% unseated in all cases, just that your link position is wildly messed up  (think along the lines of how, with lag, when you sit on any chair in world you sometimes go to <0,0,0> for a short time, then you reappear at the correct spot in the sim)

The vehicle detects this weird link distance/<0,0,0> position and pauses the vehicle, waits and waits and waits for the simulator to correct the situation then (as you are still linked) just repositions you a few times to fix it. 

As you say a script can't sit you without experience or rlv. One to ask the creator, I think.

Edited January 3, 2018 by Callum Meriman

[Callum Meriman]

9 hours ago, animats said:

If you want to try this, get one of the free Railstar work cars from the vendor at Murasaki Creations.

L$0 at http://maps.secondlife.com/secondlife/Neumoegen/30/38/75

I think your position is wrong. But on a corner in Telea... a better rez point is http://maps.secondlife.com/secondlife/Aglia/161/142/85 then head to the northwest where there are 4 sims joining you mention and you do two very fast crosses one after the other. A second handover starts before the first can finish.

The positions are: Agirus 248, 3 / telea 254,254 / Aglia 1, 252

This is a real edge case, a + crossing is a super bad place to cross, it's really pushing the servers a bit much. Not sure it's a valid repro.

 

Edited January 3, 2018 by Callum Meriman
added photo

[animats]

I'll have to try that location.

Murasaki Creations has figured out how to recover from most half-unsits. How remains a mystery. I've sent them IMs in both English and Japanese, and am waiting for an answer.

I'd looked into doing recovery like this, but I was thinking of using llUnsit to get a clean unsit, then move the avatar to the vehicle, then use RLV to do a force sit. Their approach is better.

The half-unsit situation seems to be when the avatar is in one sim and the vehicle is in another, but they are still linked. This isn't a valid situation. But apparently the vehicle still has enough of a link to the avatar to do some things to it.

Moving something across a region boundary from a script is possible. I have a script which does this on all the furniture in my little cafe in Vallone. If you knock over the furniture and bottles, they roll around, and when there's nobody around, they all return to their place. This works even if the objects are outside the region. You can't use llSetPos to cross a region boundary, but you can use llSetVelocity to move objects across regions. So that script recovers objects by turning Physics off and Phantom on, then applying a velocity towards their home position. This gets about 10m of move per call, and the object can move through other objects. Soon the object is in the correct sim and near home. A final llSetPos puts it back in place, and Phantom is turned off, returning the objects to normal solidity.

Murasaki is probably doing something like that. The big questions are 1) how do you detect the problem, and 2) which LSL calls work on an avatar with the permissions you get from sitting. I didn't think the vehicle had enough permissions to do all this, but maybe it does.

[animats]

(To recap, what we're working on here is a very hard case, hitting a double sim crossing at high speed. The regular case of just blasting across sim crossings is already working. Yesterday I spent about an hour riding a Murasaki motorcycle while running in the modified Firestorm viewer , and never had a serious problem.)

I'm now able to get the same failure in both the modified and release Firestorm viewers. What makes a difference is how recently the region was crossed, not which viewer. When I wait a few minutes, launch a viewer, start at http://maps.secondlife.com/secondlife/Aglia/161/142/85, and head northwest in a Murasaki railcar at speed 4, a partial unsit happens almost every time. if it doesn't happen, driving back and forth through the sim crossing does not fail. This probably means it works better when some info is in cache.

Before, I thought it was something I'd broken, because I'd test with my viewer, find a problem, and immediately rerun with the release Firestorm and not see the bug. But apparently not. It's more related to how recently those regions crossings were made. 10 minutes between tests seems to be enough for whatever is being cached sim-side to time out.

After the failure, the avatar is in a sit position above the tracks, and the railcar continues down the tracks by itself. Not too far; after a while it disappears but is not returned. There's no "Stand" button. Movement cursor keys do nothing. But there's a nearby scripted sittable object, a rope, and clicking "Sit" on that.causes a rope climb. After that, the avatar has been returned to normal.

If the avatar is just left to sit there, after a few minutes, the top left menus in Firestorm stop working. Bottom menus still work. It's like event processing is stuck and the queue is full.

I have Firestorm logs of all this with Debug level logging turned on. Anyone good at reading those?

[animats]

I've been communicating with a builder of military vehicles in SL, and he points out that the vehicle may be able to move the avatar across a sim boundary with llSetRegionPos(). That may be how Murasaki does re-seating. But that LSL call has a distance limitation. It won't move an object more than 10m outside the sim boundary.

The rail car, unlike most vehicles, keeps going until you tell it to stop. You don' t have to hold down a key to keep it moving. So, when an avatar is unseated from the rail car, the rail car may be too far away in the next sim for the avatar to catch up and be re-seated. This is also a problem with heavier boats, which take a long distance to stop, and I've seen this happen once there. If that's the problem, there are ways to overcome it.

For the military guys, this is a big issue. There you are, in the middle of a battle, and suddenly you fall out of your tank or off your torpedo boat. You're dead.

[Callum Meriman]

8 hours ago, animats said:

There's no "Stand" button. Movement cursor keys do nothing.

Yes, this is the standard crash that we all experience, quite common. Recovery can be one of a number of actions, more often than not though a relog is needed. A relog under this situation returns the login error "Agent not in region" and a 2 minute delay.

It's due to a handover delay and it's what I've been talking about the whole time. I doubt it can really be fixed viewer side, although I suspect it can be detected quite reliably in LSL.

I am not convinced those vehicles can recover from it, they are exhibiting other issues due to lousy design that could be confused as the same fault, I don't think it is.

The sim crossing unseat/lockup happens a variable time after you detach from the vehicle's seat, but are still linked. You detach from the seat if the sim handover doesn't work smoothly. This is why + corners are quite problematic and a bad reproduction, you end up in sim 3 before you really load in sim 2.

You see the same detaching in a busy sim when you sit on any chair/sexbed/whatever and end up at <0,0,0> until the lag stops and you snap back. The chair/sexbed isn't moving though, so you don't end up at <0,0,0> on the ground without a stand.

 

Edited January 4, 2018 by Callum Meriman

[animats]

4 hours ago, Callum Meriman said:

I am not convinced those vehicles can recover from it, they are exhibiting other issues due to lousy design that could be confused as the same fault, I don't think it is.

Can you be more specific? Have you tried a Murasaki vehicle? I suggest the motorcycle or the dune buggy. I've seen both of them go through a clear multi-step recovery sequence, as I've described. I've never seen that fail except at a four-sim intersection, and I've spent about an hour and a half driving those things around.

Here's what driving looks like with these fixes: https://vimeo.com/249634075

This is going too fast for safe driving, but shows what it looks like to drive around 80KPH in SL.

Edited January 4, 2018 by animats
Add more explaination

[animats]

Here's a quick 5 minute run on a motorcycle:

 

[animats]

Summing up:

• The viewer-side fix to get rid of grossly bogus movement at region crossings is working in Firestorm, in use by a few users, and on track to go into a future beta and then a release.
• The road problem at sim crossings is well-understood - roads need a prim on each side attached to the other side, to provide support for the first few meters after a sim crossing. Some roads have this, some don't. I'm working on a "pothole detector van" to detect and log places that need a fix. An automated repair van should be possible, but a Linden with road-building privileges would have to drive it.
• If you have a good road and the viewer-side fix, sim crossings are pretty good. I've posted videos of zipping around on a motorcycle without slowing down for sim crossings. Fun.
• There are still the "partial unsit" bugs. Some of those situations can be recovered by clever scripting. But not all. Those are real bugs in the code. The worst case is a 4-way sim crossing, but those bugs can show up at any sim crossing.

Thanks, everyone.

[animats]

Further progress.

The viewer fix is going into the Firestorm beta, so everyone will have a chance to try it. I've been using it for weeks, and it's a clear improvement. No more strange looping and twisting at region crossings. There's still a stall; that's inherent in the SL architecture. It's usually about 1 second for small vehicles. I've tried some larger boats; they take several seconds, but in open water you don't notice.

I've been able to improve a few things at region crossings via more checks in the vehicle script. It's common for the camera to get out of position at a region crossing. Also, sometimes the avatar's driving/riding animation stops. Both of those are fixable.

After every region crossing, the vehicle script checks the distance between vehicle and avatar (this sometimes gets large for a moment), that the avatar links back to the vehicle (that link is broken momentarily at sim crossings), that all the proper permissions are still set, and that the avatar is sitting. This is checked every 100ms after a region crossing until all tests pass. This indicates a successful region crossing. Then all the camera parameters are reset and the driving animation is restarted. The visible result is that the camera doesn't jerk and the avatar animation doesn't stop.

I give out full-perm demo bikes with these fixes to vehicle builders so they can see how this works. If you're a vehicle builder or vehicle script writer, contact me and you'll get one of my test bikes with bright yellow stripes.

The big remaining problem is the "half-unsit" described previously. That seems to happen when the vehicle makes it across the sim crossing but, for some reason, the avatar does not. In that situation you can't unsit. This is clearly a bug.  Only LL can fix that one. I'm trying to develop an un-deniable test case. It's much easier to see this bug with all the other stuff fixed.

[Theresa Tennyson]

I would like to suggest an additional optional mode where instead of stopping at the region border, the vehicle is drawn continuing on a straight line at the constant speed and direction that it hit the border. One of the reasons for the "Mr. Toad's Wild Ride" region crossing condition is that the extrapolation assumes that it not only will continue moving, but will continue turning, rising, falling, accelerating, etc. If you hit a region border moving straight (which is the standard condition in a boat or airplane, especially when the pilot is familiar with how the process works) border crossings aren't usually very noticeable. It's ground vehicles that have more issues because roads often turn or rise right before a crossing. Personally it sounds like I'd find your current change just as annoying in its own way than the current conditions in many situations.

 

[animats]

7 hours ago, Theresa Tennyson said:

I would like to suggest an additional optional mode where instead of stopping at the region border, the vehicle is drawn continuing on a straight line at the constant speed and direction that it hit the border.

During the sim crossing, the vehicle really doesn't move, because simulation was stopped in the sim being left and hasn't started yet in the sim being entered.  If the viewer fakes forward motion, there has to be a "yank back" to get viewer and sim back in sync. For boats, the "yank-back" isn't  too bad visually, because all water looks pretty much the same. By the same token,  a stall on water isn't too bad visually, if the flags and sails can be kept flapping and the audio keeps going. That may need a little work on the script side. Vehicle scripts do need sim crossing awareness to deal with some of the problems.

If you show the user a phony position for a land vehicle, they'll make bogus steering corrections and crash. That's unacceptable. One major SL bike builder tells me that turns off some real bikers from trying SL bikes. They have the reflexes for driving, and SL's artifacts make them do the wrong thing.

Find me a cheap SL boat with full perms, and I'll try to improve its sim crossing experience. Thanks.

[animats]

Well, I finally found a way to recover from the "half-unsit" failure at a region crossing. But the driver/passenger has to wear an RLV relay.

1. Detect half-unsit in vehicle script.
2. Stop vehicle from within script.
3. Get location of vehicle.
4. Find clear space near vehicle where avatar can stand. (Not on top of the vehicle; the "sit" step may not work.)
5. Teleport avatar there using RLV command: @tpto:Fenfarg High/242/254/66=force
6. Check location of avatar. If it's not at the desired destination, teleport it somewhere safe, then try again. Sometimes the first teleport/unsit won't work right.
7. Put avatar back in vehicle with RLV command: @sit:98128b10-54b7-c788-8fd9-d322571470af=force
8. Reset vehicle and avatar animations, take controls, and return control to the user to drive again.

This workaround is clunky. But it works. It demonstrates that "half unsits" are recoverable.  I'll make up a demo bike that does this and let people try it.

I now have fixes or workarounds for almost all the things that can go wrong at region crossings.

(This really should be fixed by Linden Labs on the sim side, of course.)

 

[Theresa Tennyson]

3 hours ago, animats said:

Well, I finally found a way to recover from the "half-unsit" failure at a region crossing. But the driver/passenger has to wear an RLV relay.

1. Detect half-unsit in vehicle script.
2. Stop vehicle from within script.
3. Get location of vehicle.
4. Find clear space near vehicle where avatar can stand. (Not on top of the vehicle; the "sit" step may not work.)
5. Teleport avatar there using RLV command: @tpto:Fenfarg High/242/254/66=force
6. Check location of avatar. If it's not at the desired destination, teleport it somewhere safe, then try again. Sometimes the first teleport/unsit won't work right.
7. Put avatar back in vehicle with RLV command: @sit:98128b10-54b7-c788-8fd9-d322571470af=force
8. Reset vehicle and avatar animations, take controls, and return control to the user to drive again.

This workaround is clunky. But it works. It demonstrates that "half unsits" are recoverable.  I'll make up a demo bike that does this and let people try it.

I now have fixes or workarounds for almost all the things that can go wrong at region crossings.

(This really should be fixed by Linden Labs on the sim side, of course.)

 

Charles Lindbergh, who knew something about crossing regions, had a very sensible explanation as to why he flew across the Atlantic solo in a single engine plane without a radio, which the contemporary press called "reckless."

He pointed out that his safety depended on different things at different points in the flight.

In the beginning of the flight, at takeoff, safety depended on his plane being as light as possible. Some of his competitors crashed on takeoff because their planes were heavy.

At the end of the flight his safety depended on having as much of a fuel margin as possible.

In the middle of the flight additional safety equipment, multiple engines, a radio, etc. might have given him more safety for that phase but they would have taken away safety during at takeoff or landing by adding weight that could have been used for fuel. Having multiple engines increased the chance of a single engine failure and for much of the flight with the engines of the day the plane wouldn't have been able to fly with one engine out; meanwhile the additional engines would have added their own weight and the weight of fuel necessary to carry them. Radios of the time were unreliable and for practical purposes would have required an additional member of the crew - more weight dedicated to something that might not have worked at all to keep him safe.

One of the biggest factors in successful region crossing in Second Life is the amount of script complexity - the less scripting in your vehicle, the faster and more reliable region crossings are. Your script additions for recovery of uncommon problems (in my experience, and I have plenty of experience using a wide variety of vehicles) will need to be dragged across the region border at every crossing, possibly making the overall experience worse the vast majority of the time.

Edited January 31, 2018 by Theresa Tennyson

[animats]

And three weeks later, someone with a bigger, better plane carried the first passenger across the Atlantic.

Script state size is never more than 64K bytes.  Number of prims seems to be a much bigger factor than script count. Each object apparently requires a database lookup. (It definitely works that way in OpenSim; for LL's implementation, the source code is proprietary.) The 10-second crossings reported for large ships are for ones with very complex geometry.

Try a free bike with most of this implemented. Take a copy of the yellow and black test bike here. This one, if you come off at a region crossing, will try to teleport you to the bike's location, but won't sit you back on it. You have to do that yourself.  No RLV required, but it asks for teleport permission. It doesn't seem to have a region crossing delay problem. It carries a lot of debug and logging code the production version won't need, so this is a worst case.

[Love Zhaoying]

11 hours ago, animats said:

Well, I finally found a way to recover from the "half-unsit" failure at a region crossing. But the driver/passenger has to wear an RLV relay.

1. Detect half-unsit in vehicle script.
2. Stop vehicle from within script.
3. Get location of vehicle.
4. Find clear space near vehicle where avatar can stand. (Not on top of the vehicle; the "sit" step may not work.)
5. Teleport avatar there using RLV command: @tpto:Fenfarg High/242/254/66=force
6. Check location of avatar. If it's not at the desired destination, teleport it somewhere safe, then try again. Sometimes the first teleport/unsit won't work right.
7. Put avatar back in vehicle with RLV command: @sit:98128b10-54b7-c788-8fd9-d322571470af=force
8. Reset vehicle and avatar animations, take controls, and return control to the user to drive again.

This workaround is clunky. But it works. It demonstrates that "half unsits" are recoverable.  I'll make up a demo bike that does this and let people try it.

I now have fixes or workarounds for almost all the things that can go wrong at region crossings.

(This really should be fixed by Linden Labs on the sim side, of course.)

 

Sounds bad, not everyone uses RLV. I realize you are targeting FireStorm.

Edited January 31, 2018 by Love Zhaoying

[animats]

2 minutes ago, Love Zhaoying said:

Sounds bad, not everyone uses RLV. I realize you are targeting FireStorm.

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. A region cross and an avatar teleport are much the same thing underneath, Oz Linden pointed out to me. The teleport just comes with an animation and sound effects. You know how sometimes teleports fail, and you have to try again?  I now suspect that failed region crossings are the same failure. Maybe the answer is simply that sims need to retry region crossings a few times before giving up. That's what I'm doing here, with scripts and RLV, and it works.

This makes sense. A region crossing is a network operation between different computers. You have to assume those will fail some of the time, and be able to deal with that.

[Theresa Tennyson]

1 hour ago, animats said:

And three weeks later, someone with a bigger, better plane carried the first passenger across the Atlantic.

 

Funny thing about that - Clarence Chamberlin had his Bellanca and was putting together his crossing plans long before they happened. In fact, Charles Lindbergh originally wanted to buy his plane - the Spirit of St. Louis was designed and built in the time Chamberlin was planning. However, Chamberlin got caught up with a variety of issues involving navigators and radios (neither of which Lindbergh had to deal with) and was sitting on the field waiting out a court injunction when Lindbergh took off. In other words, his region crossing was delayed by unnecessary overhead. 

https://en.wikipedia.org/wiki/Clarence_Chamberlin

(Tip: trying to school me on aviation history doesn't usually end well.)