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.

(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?

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.

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.

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.

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. Great! Also great! That had me puzzled and worried. 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. Good that you're testing that. As you've probably noticed, the sim crossing clipping and edge of world detection now use common code. It sure beats being blown off the road every two minutes.

Thanks very much. I agree. I went to Dutch Harbor and tried a Laser One, the small but advanced sailboat. I need more sailing experience to evaluate that properly. But sim crossings were not much of an issue with the modified Firestorm I'm using right now (which is one rev ahead of the Github sources.). The Sumi dune buggies at Burns are great! Somebody worked through all the hard cases in scripting, like detecting an unsit and re-seating the driver. And they have vehicles with suspensions. Most land vehicles in SL are all unsprung weight and behave accordingly. Those vehicles work much better in the modified Firestorm than in the stock Firestorm. In the stock Firestorm, they go under the road, off the road, and then snap back. In the modified one, they slow down to a stop briefly and continue. Their little scooter, the Sumi Motochamp, gets pushed off the road at a sim crossing at http://maps.secondlife.com/secondlife/Imperial/1/1/87 in versions of Firestorm with and without the fix. Haven't figured that one out yet. Their demo Jeep is great. I want to buy one, but can't find the vendor for that item. The Shelby Cobra from the place down the road is quite drivable, too. Again, it works better in the modified Firestorm. First gear is too fast for parking, though. This fix is consistently an improvement for ground vehicles. More later.

Good points. There's an inherent conflict here. Time does stop for an object sim-side during region transfer, while for the human user and the viewer, time continues to run. Something has to give. I chose to make the viewer track the sim as closely as possible. This is honest, and gets rid of many annoying problems. 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. This is mostly a ground contact problem - water and air vehicles don't suffer badly from it. A solution that does what you want involves some degree of faking it on the viewer side. Let me try a few things. More later. This is all viewer-side, so it shouldn't affect races. 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.

Try the new version; the one you have mis-clips when you cross a region boundary at an angle. The immersion-breaking problem is a classic one. I tried a 60-knot boat in the release Firestorm browser. When you hit a sim boundary, you overshoot and are yanked back. The velocity extrapolation keeps you going while the sim is stopped during the transfer. Now your position in the viewer is ahead of where the sim thinks you are. So it gets yanked back on the next update from the sim. Try it where you have some nearby objects for a reference to see this. But in open water, you don't notice the yank-back as much. Water mostly looks the same. This creates the illusion that you didn't stop. On land, you see the yank-back and it looks terrible. This was named the "surreal time" problem by Randy Farmer and Chip Morningstar, who did Lucasfilm's Habitat decades ago and were the first to hit this problem. The rate of time flow is inconsistent between the sim and viewer in some situations. This comes up in most MMORPG systems. It affects shooting of moving targets, which is a much bigger deal in gaming than in SL. In some systems, inconsistencies like that are drifted back into sync. Let me see what I can do. I tried a fix which keeps the velocity as seen by scripts nonzero while the vehicle is stuck at the sim crossing. This keeps the engine noise, etc. going while the vehicle is waiting for the sim crossing. That will need heavy testing to make sure it doesn't break something else. That might fix the Shadow-X. Its scripts are probably bothered by the velocity suddenly going to zero for no good reason. The Flying Shadow-X is l$2500. Is there anything cheaper that breaks?

You don't have to build with --clean after the first successful build. It only takes a few minutes to make a minor change.

Sorry, didn't update Github version properly. Try fetching llworld.cpp again. Thanks.

I've tried simple boats in the Blake Sea. Launched from Hollywood Airport. Worked fine, the same way it does in the waters west of Zindra. No problems blasting around at 66 knots. Someone with larger and more complex boats should build Firestorm and see how it works for them. I'm not really into boats. Callum Meriman, please let me know how this works out. Those 4-corner crossings in Kama City are awful. Too thin, no overlap, and a gap underneath. But each intersection has only two different parts (one quadrant with manholes, one without) and all the intersections use the same parts. Get those two parts right, replace them, and that job is done. Tour de Corse is mostly good roads. Haven't tried the mainland roads with this viewer yet. Any suggestions for a good ride? The fix is in the Firestorm JIRA, one of the maintainers seems to like it, and it should show up in a Firestorm beta in due course. With this fix in, much of the minor bad behavior at sim crossings goes away. The remaining problems become much clearer, because they're less frequent and not hidden behind bad guessing by the viewer. The big one is where the avatar(s) become unseated from the vehicle. Or worse, half-unseated; neither properly seated nor in a clean Stand state. I'm trying to find a way to replicate that bug on demand.

“People who say it cannot be done should not interrupt those who are doing it.” If you are capable of doing so, build the Firestorm viewer from source and try my fixes. Start here with the Firestorm building instructions. Build the Firestorm viewer from source code and run it. Add my fixes from the link in the Firestorm JIRA above. Three files on Github replace the files with the corresponding names in the "newview" directory. Rebuild Firestorm. See my "README.md" file for instructions. Try some vehicles in Second Life. There's an in-world support group for people who build the Firestorm viewer from source, "TPV Self Compilers". You can get help if you're stuck.

It's a Linden road hitting a sim corner at a 45 degree angle. One of the worst cases. It's not the corner itself that causes the problem. it's two sim crossings very close in time. Somewhere there's a race condition in the software. I've tried this about thirty times now, with two failures. This may be associated with "Unable to create pending connection" errors.

There are still sim-side problems. Like this one. This is on Circuit le Corse, at http://maps.secondlife.com/secondlife/Pearl/-1/245/28. I've had this happen here twice. The vehicle script reports animation permission errors. The rider is unseated, but stuck. Cursor keys do nothing. It's hard to get out of this. Even after the bike times out and derezzes, the avatar doesn't get the cursor keys back. "Reset skeleton and animations" will restore the ability to rotate the avatar, but not to move it. I've seen this failure many times. Sometimes some of the cursor keys are returned to the avatar; sometimes none of them are. This time it's so bad that nothing short of logging out will fix it. More later.

Vehicles tried so far: Sport motorcycle: https://marketplace.secondlife.com/p/SPORT-BIKE-M1-Motorcycle-boxed/1340735 Speedboat: https://marketplace.secondlife.com/p/Anna-Erotica-Speed-Boat/7723235 Boat: https://marketplace.secondlife.com/p/Belleza-Sport-Powerboat-v10-Boxed-boat-speedboat/1165949 Bus: https://marketplace.secondlife.com/p/BUSCOACH-by-Arcadia-Revisited/12873964 These are all L$10 and under, so feel free to buy your own to get further information.

More development and testing today. Found the cause of the "sideways jerk" problem and fixed that. The clipping code in the viewer must allow locations outside a region when the sim gives it such a location. This happens routinely just after a sim crossing, before the gaining sim takes over. The viewer just can't make guesses that go outside the region; the guesses will be awful. With this fix, hitting a sim crossing at an angle now works better. There's no "sideways jerk". I built a test road in an big sandbox to check that out. With the new code working in Firestorm, I went off to enjoy it. For a pleasant evening, I started with a ride around the Circuit de Corse on a motorcycle. This has lots of off-angle sim crossings. No problems with those. The roads on the Circuit de Corse seem to have duplicated prims in the under-road layer that cross the sim boundary from both sides. They have to, or the off-angle road crossings wouldn't work at all. At each sim crossing, there's a freeze for about one second. The motorcycle sound stops for a moment, then picks up. No jerk, no drama, no steering corrections needed at sim crossings. Just drove around in Gear 3 of 6. Faster than that, and I can't keep it on the road. I made it around the circuit in about 20 minutes. It's not bug-free yet. The "loss of animation permissions" problem came up several times. That's a known problem and can be worked around in vehicle scripts, but the bike I'm using doesn't have it. It'a stock bike, and does not have my "automatically slow down for sim crossing" code. I wanted to test without that. At http://maps.secondlife.com/secondlife/Venostrate/11/3/28 I was thrown off the bike. I want to go back there and look closely at the road, but today I was just doing this for enjoyment. I've been asked about other vehicles. So I started at my little cafe in Vallone, where i have a parking area for rezzing vehicles. I rezzed a VTOL aircraft and flew it over Kama City, trying to stay over streets to avoid hostile security orbs. (Security orbs need to be more tightly regulated. I've had aircraft shot down by zero-delay security orbs. That's griefing.) Flying worked fine. At each region crossing, there's the usual one second pause. This is made more annoying by bad camera control - the camera gains on the aircraft, then falls back once the aircraft gets moving again. Camera control with the motorcycle needs work, too. There's slow drift. The camera starts out behind the motorcycle, but after a few minutes, it's off-axis. Easy to fix, but annoying. I went out to the edge of the world past Kama City, and banged against it as a test. (The same code that does region clipping does world edge clipping, so that needed to be tested.) Banging into the edge of the world works the same way it used to. Then I flew along the coastline of the west edge of Zindra, looking for a rez area. I found one next to a dock, and landed the VTOL plane. There I rezzed a power boat, got it into the water, and started cruising around the bays to the west of Zindra. This worked fine. As usual, there's a one-second stall at every sim crossing. The engine noise stops, the flag stops flapping, and the water spray stops, which means the sim is telling the vehicle script that velocity is zero. Tried zooming around at 50 knots. Hit sim crossings. No problems. Tried zigzagging across sim crossings. No problems. Slowed down and went up the river in Zindra all the way to the dam. Nice sightseeing. Came out of the river, went north under the lift bridge, and around toward Horizons. Found a Linden dock on the Zindra side and docked. Stood up, and the Linden water area immediately de-rezzed the boat, dropping me in the water. (Come on, give people a minute on Linden land before you de-rez a vehicle.) Climbed out, and walked to a monorail station. Rode the monorail back towards Vallone. The monorail dumped me on the ground at a sim crossing. (That system needs work, not that anybody uses it.) Walked back to Vallone. Very slow sim crossings at some streets, as long as 8 seconds. Must be an overloaded server. Usual sink-into-the-ground Kama City intersections, as discussed previously. Back home at my cafe after about two hours. No teleports at any time. Vehicles are about to become much more usable in Second Life.

The viewer fix definitely helps in cluttered environments. I've been testing in Kama City and on the Circuit de Corse route. The Circuit de Corse roads are good for testing - they have frequent, well-marked rez zones, road signs, and go through interesting country. There are hills and curves. I just rode a motorcycle around the circuit that starts at the above link, while using my modified Firestorm viewer and a stock bike. Took about 15 minutes. I didn't bother to slow down for sim crossings. There's a stall of 0.5 to 2 seconds at every sim crossing. Longer stalls usually mean a busier sim. Crossings hit off-angle produce a moderate sideways jerk. (I'll look into that. Might be fixable.) But there's no flying off into space. I can relax, ride, and enjoy the scenery. It's much better than with a standard viewer. The worst that happened was when I was trying to pass one of the Linden bubble cars (yes, I know they're phantoms and you can go through them) at a sim crossing. The avatar came loose and was re-seated, but not in the right place. That's a known problem in vehicle scripts. The fixes I've described to viewers and roads make driving in SL fun, and usable as a way to get around. SL is great for sightseeing with this. I want to see this fixed for everyone.

I've been talking to a Firestorm dev. and have submitted a patch to the Firestorm JIRA. So the process of getting this fix deployed has started. The viewer side fix doesn't fix all the problems, but it prevents little twitches from turning into huge bogus movements that drive users nuts and make drivers crash. With that fix, you can see the real problems underneath, many of which can be fixed by simple changes to roads at sim crossings. Water is still a problem. That would require code changes in the simulator to fix. Roads can be fixed in-world, but not water.

Air vehicles don't have the problems of road vehicles. See my linked topic on Vehicles vs. sim crossings for more info.

Thanks. I checked out the road crossings at http://maps.secondlife.com/secondlife/Windermere/0/98/39 and http://maps.secondlife.com/secondlife/Buttermere/1/160/37 but neither is a good location for high speed vehicle testing. Both are narrow roads with turns. This needs some straight-line open space and a road modified near the sim crossing. The idea is to build a road with some overlap, and drive over it fast with various vehicles in a heavily loaded sim. This test works fine in empty, near-idle sandboxes, so the next step is to try it in a loaded one. Skyboxes are an option, but I'd rather do this at ground level. It's simpler.

I'm looking for some land I can use to test region crossing issues for vehicles. What I need is: Two adjacent parcels in different regions with building permission on both sides. Enough space for a 64m x 8m road on each side. A busy sim with some lag and many avatars. (This test works fine in an empty sandbox.) Just a few days of use. See for the goal here.

“Modified Firestorm Viewer?” Yes. I built the Firestorm viewer from source code and made some changes. See https://jira.phoenixviewer.com/browse/FIRE-21915 The velocity interpolation algorithm in the viewer amplifies problems at sim boundaries. That's easily fixable. Not enough information to be helpful. Are there viewable objects on all four sims, or are they empty besides your track? it's a nearly empty sandbox. That sandbox is both adult and premium, so it's not used much. Very little lag. This experiment needs to be repeated in a busier environment. Know any place that's busy and has a sim crossing where building is allowed on both sides? Are you wearing a lot of scripted objects? No Are you wearing a lot of attachments? No How is your avatar complexity? About 50K. Totally irrelevant to this problem.

Tried that. Here's a worst-case test. Circular track across four region boundaries. Currently in Sandbox Teagano (20, 0, 32) . So here's a motorcycle, going round and round on a circular track across four region boundaries without problems. The track is 2m thick (1m is probably enough). Each quarter of the track is in its own sim, and has a 4m extension into the next sim. That's in translucent red here for visibility; the extensions would be set to totally transparent for real use. Each extension overlaps 4m into the other sim. Sim crossings appear stable. There's still about a half-second stall at each sim crossing, as the sim transfer takes place. If you're reading this before 3PM Linden time Friday, the track should still be there, so please try it. I'm using a modified Firestorm viewer on top of this, one that doesn't extrapolate motion across sim boundaries. Without that, the rotation from turning the bike incorrectly continues during the sim crossing stall, which confuses the rider. With the viewer mods, motion just stops dead for a moment. With both of these fixes combined, sim crossings are routine and boring. I've been going round and round for about twenty minutes with different bikes with no drama.

Night in Second Life. A darker night than usual. Riding a bike with a working headlight. Kama City Cafe parking lot, Kama City Convenience store, Dark Alley The environment is Nacon's Natural Sunrise A, just before first light, with advanced lighting enabled.