animats

Hm. If you can build and rez, you can grief. Not clear how preventing object entry where you can build helps. I'm thinking of the big sandboxes such as http://maps.secondlife.com/secondlife/Sandbox Colborne/3/136/27 (Adult, premium, griefing not a problem) http://maps.secondlife.com/secondlife/Sandbox Pristina/9/144/27 (General, all users) each of which is four sims in a square isolated from other land. I do vehicle testing there, and if I get out of the vehicle to edit it, the vehicle goes away.

Some Linden Labs sandboxes have Build enabled for everyone, but have Object Entry disabled. This is a strange combination. You can create prims and rez existing objects. You can rez a vehicle and drive it. But if you get out of the vehicle, it immediately disappears and is returned to the owner, because it's now considered an "entering object". Is there some good reason for this, or is it just a bad permission setting?

Right. If you permit object entry and avatar entry, permit scripts. Otherwise, anything with a script dies on your parcel, including overflying aircraft. This is griefing.

I get responses about the serious stuff, like someone putting up an invisible prim that blocks a road. Stuff like violations of advertising policy in the form of large, ugly, rotating, free-floating signs are not dealt with.

Suddenly my packet loss rate went up to 10-20%, according to Firestorm. Tried on two different machines; one Linux, one Windows 7. This seems bogus. My DSL stats show zero errors. Ping tests and speed tests show zero errors. I have 50mb/s down, 5 mb/s up, and speed tests right now show that.SL is using under 1% of the available bandwidth. This happens even in an empty sandbox. (132kb/s down, 4.7 kb/s up. That's kb, not mb.) Anybody else seeing this? (This has been a bad day for LL. First they let their TLS certificate expire, preventing web connections. Then there was about 15 minutes when logins to SL failed. Vallone sim is still lagging badly. Now this.)

"Unfortunately, until December 2013, the continent (Zindra) is still unfinished. This means that an important road in South is not connected with the rest of road system." - SL wiki. Proposed road connection in blue It's tough to drive from the south part of Zindra to the north part. The sims south of Keranio and Cotehill, where the roads would have connected, were never built. But there's a route available. It's just not paved. The Southern Bypass. It's a Linden-owned right of way from end to end, but plain grass, no pavement. Most of the adjacent properties are vacant LIFE Properties parcels. Is there any chance of getting LL to pave the road there? Should I ask someone at LIFE Properties to support this? If so, whom?

Me too. Grid status says OK. Tried Firestorm, SL viewer, Windows, Linux - "unable to connect to a simulator". Connections to OpenSim's Metropolis Metaversium are working fine, so browser and net are good here.

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: 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. 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. The old sim tells all the avatars sitting on the vehicle to teleport to the new location of the vehicle in the new sim. 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.) 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.

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.

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.

I'm trying for a subtle effect here. I've developed a fix for the Firestorm viewer that eliminates most bogus motion at region crossings. Instead of bogus motion, the vehicle or avatar stops dead for a second or two at each region crossing. Here's what that looks like. With the old viewer, the boat not only moves strangely at sim crossings, it goes underwater twice. I've written about this over in the "vehicles and sim crossings" topic. The old behavior was awful, leading to drivers crashing because they tried to make steering corrections when the viewer showed them bogus positions. But for slow sailboats, it looked OK. Up to about walking speed, region crossings on water look good. The boat seems to glide smoothly across the region crossing. Then it is suddenly jerked back when the sim handover completes. The jerk-back is so fast that users can ignore it, and enjoy the peaceful experience of sailing slowly. Some users like that behavior. So I'm trying to figure out how to give sailors the pleasant experience of a smooth region cross at slow speed without big bogus motion at higher speed. What I want to do is to animate the vehicle and avatars so that they appear to move smoothly across the region boundary during the stall. This means animating them moving forward at slow speed during the stall. This is illusory motion, viewer side only, like all animations, and can run during sim handoff. After the transfer to the new sim, the vehicle and avatar are being displayed ahead of where they really are. We have to take that extra motion back. But rather then moving them back in one big jerk, we do it slowly over 5-10 seconds, more slowly than the real motion is moving them forward. That way, there's always smooth forward motion, although the speed varies a bit. (There's no way of escaping that as long as region crossings take time. But we can mask it.) This would be a script and animation you put into slow boats to improve the visual experience, similar to a wake animation. So that's what this is all about. I just want suggestions on the right tools for the job. I may end up creating BVH files from a spreadsheet.

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. Detect half-unsit in vehicle script. Stop vehicle from within script. Get location of vehicle. Find clear space near vehicle where avatar can stand. (Not on top of the vehicle; the "sit" step may not work.) Teleport avatar there using RLV command: @tpto:Fenfarg High/242/254/66=force 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. Put avatar back in vehicle with RLV command: @sit:98128b10-54b7-c788-8fd9-d322571470af=force 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.)

The "keyframe" system, I think, is equivalent to calling llSetPos(). That won't work during a region crossing, because the script is stopped during handoff between sims. But animations, which are viewer-side, can continue to run.

Not animesh. May be mesh. It's about creating the illusion that a boat is seamlessly crossing a sim boundary, even though there's really a stall during sim handoff.

I want to animate a vehicle's position, moving it a few meters from its actual position. This is related to my region-crossing work. I need a position-only BVH file. It only needs one track. What's the recommended tool for this? There's lots of information on line, but most of it is a decade old. "qvimator" seems to only be good for skeletons. Also, what are qvimator's position units? They're not meters. They're not centimeters. "bvhacker"'s site says it's only for editing existing files, not creation. What's the unit used for position in BVH files? Also, if I animate the root prim of a vehicle, do the avatars follow along, or do they each need to be animated separately?

If you want land in the middle of nowhere with mountain views, it's not hard to find in SL. There are lots of abandoned parcels in isolated areas. If you have a premium membership, you can request that an abandoned parcel be auctioned by sending in a support ticket. http://maps.secondlife.com/secondlife/Blanda/165/101/139 Underdeveloped Heterocetra http://maps.secondlife.com/secondlife/Simcoe/106/44/97 Abandoned mainland. Looks like the surface of the moon. There's lots more.

OK. Is this documented by LL somewhere?

If you don't want to be in a shared world, build in Sansar. It's all about private spaces.

Give them one of these. I just sent the original poster one of these obelisks. They're free to copy. I found one on Heterocera.

Here's a list of bugs in the JIRA listed as closed and fixed, ordered by when the bug report was submitted. Bugs reported in 2017 now fixed: 1. Bugs reported in 2016 now fixed: 2. Bugs reported in 2015 now fixed: 1. Bugs reported in 2014 now fixed: 28. Bugs reported in 2013 now fixed: 75. Bugs fixed by year: 2018: 1. 2017: 3. 2016: 4. 2015: 24. 2014: 65. 2013: 87.

What operating system? What viewer? What time does your clock say? Do you have your time zone set correctly?

Whatever happened with the 64-bit Linux viewer? That's mentioned in various places as "real soon now", but the downloadable viewer is 32-bit only. The latest Linux desktop distros are 64-bit only. Nobody runs 32-bit on big machines any more. Apple just announced end of life for 32-bit applications. (I just need to run the SL viewer to report bugs.I run Firestorm for real use.)

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.

A Linden Labs promotion for Second Life. But the only reason I found this was because I was reading the forum for High Fidelity. Is this being run as an ad, or what?

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.