objects crossing sim borders

I don't have any experience on this, and what I've been able to find on the forums has been pretty vague. So, I have some questions:

What specifically are the problems that occur when objects cross sim borders?
Is it the same for all objects? If not, how does it vary (prim count, scripts, prim size, link distances?)?
What causes the problems?
I've heard that objects "explode", usually accompanied by something about prims unlinking. Is it just that the prims become unlinked, or does it really explode, IE: the prims fly far away? And how far do they go?
Does the whole object explode, or do only some parts fly away? If just some, which ones and why (IE: what's the difference between those and the ones that didn't get unlinked)?
When an object crosses a sim border, what events run as a result of the cross, if any? Are scripts reset?


I just found a vote requesting the problems get fixed:
http://secondlife.com/vote/vote.php?get_id=184



As a solution to the prim explosion thing, I think something could be made to gather back the pieces and reconstruct the object. The root prim would get the UUIDs of all the prims on_rez or maybe on script reset or something, I don't know. On a certain command, maybe a statement made by the owner on some channel, a sort of hunter prim is sent out which looks for and gathers up the other prims by linking them, then bringing them back to the root prim, delinking them, then having the root prim re-link the objects in order at their correct (local) positions. I'm not sure how this could be accomplished though...

Yesterday or the day before, I tried flying my non-physical "vehicle" across a sim-border corner (in the FurNation sims) to make it explode (after putting a script in every prim to make them llDie() if they suddenly found themselves separated into individual objects). I flew back and forth over the corner at least a dozen times and it simply refused to explode.

I've been building a physical ship which I'll try that with later, but thus far I've never seen a vehicle explode. That said, I did get forcibly ejected from my non-physical vehicle once when I ran into a no-script parcel. The vehicle stayed together and hung in midair, though. (I went back and retrieved it)

I did have a non-physics ship "explode" recently. (Haven't tried it in a week or so, though.)

All the prims did come unlinked. Some of them wound up in the new sim at the coordinates you would expect. Some of them wound up in the old sim with positions of (-15m, -20m, 64m) etc. I myself wound up in a third sim at (340m, -20m, 64m) and was unable to move because the poseball I was sitting on at the time didn't make the jump with me. I was able to select and delete some of the pieces, but not others. I got the rest after logging out and back in.

None of the prims moved, so there was no "explosion effect." They just all appeared in different places after crossing the border.

Objects exploding or unlinking on sim cross usually only happens when the object is close to the link limit and happens, AFAIK, due to math errors when crossing sims. Shouldn't happen if it's well within the link limit, but who knows with SL these days It's also more likely to happen if crossing at an angle as opposed to directly across.

As for what happens scriptwise, only thing is the changed() event triggers with a value of CHANGED_REGION. Scripts keep running as is otherwise.

Does the changed() event run with CHANGED_REGION on the pieces that don't make it?

I have a theory that goes something like this:

The "actual sim" ranges from (0,0) to (255,255), but there is a "buffer zone" in which that sim is allowed to calculate and maintain objects that ranges from something like (-10,-10) to (265,265). When the center of the object moves outside of the (0,0) to (255,255) range, then the object gets moved to the next sim. However, any individual prim can be in the "buffer zone" without causing disaster. My theory continues that it's when an individual prim is moved outside the "buffer zone" while the root prim is still in the "actual sim" range that the wayward prim becomes unlinked and gets moved to the next sim. Thus it would be the size of this hypothetical buffer zone that would affect explosions, rather than the link distance.

That means that at corners, there could be up to four sims that could hypothetically handle a given point in space, which might explain why they are historically problematic for vehicles.

I completely made this theory up based on no evidence other than my observations about what happened to me. The details are definitely wrong, and the whole idea could be pure malarky. In my case, pieces were left hanging with "buffer zone" coordinates (as was I, really) so there may be another factor involved, like active movement.

Likelihood of explosion might also be tied to whether the sim-crossing is between two (or more) sims on the same server or on two (or more) different servers. Seems like two sims on the same server would have a better shot at trading info fast enough to prevent the explosion.

I've never played with CHANGED_REGION, but I would guess that it would run for all the "bits" that wound up in different sims, but not for the ones that stayed in the old sim but got assigned "buffer zone" coordinates. It's worth playing with, perhaps by making a linkset, shoving it across the border of the sim with the build tools, and seeing at what point the individual prims decide they're in a new region.

What I DO know:

Sims look at objects 10M away from their borders in each direction. This is why we have the 10M link limit and why prims can only be 10M in size.

The handoff from sim to sim is buggy, and doesn't always happen as expected. I've personally been unseated, lost my vehicle completely (later, it turned up in my lost & found), and had other odd effects happen (such as pieces dissapearing and showing back up later).

The problems all seem to happen because the "receiving" sim didn't handle the handoff correctly.

Since you can't link an object while it's being sat on, you can't gather and re-link an object being ridden. The best thing might be to set up individual prims to llDie() if unlinked, and keep a copy of the entire object as an item in the master prim. The master could spawn the new object and then die.

This is yet another reason I wish we had the ability to edit meshes in SL. Many of the problems with prims would simply cease to exist.

There's a 32m link limit, not 10m. See here and here for more details.

According to Kelly Linden here, sims look 5m either side of each other (to -5 and 260) hence the 10m size limit

the issue i seem to have crossing sims isnt the vehicle unlinking or flying apart
maybe its more of a ground issue becuase it has occured while walking as well
the land appears to be leval but when u move across the border u "sink" into the ground momenterialy and then get pushed back up. some times you get stuck under the ground and have to teleport to somwhere to correct the issue
it doesnt seem to affect altitude when flying though
perhaps theres an alignment issue with the sims ?

That's just the time it takes for one sim to transfer avatar data to another. When you cross sims, the sim your leaving sends all data to the new sim, meanwhile your viewer isn't getting any more commands, so it continues with what it was doing (walking straight ahead) until the new sim takes over, which is when you snap back to where you should be. The getting stuck underground is just a failed transfer, nothing to do with the ground level itself.

Oh it definitely does, assuming you're flying a physical vehicle -- I see it all the time. It also affects you when sailing across sim boundries -- you sink underwater for a moment, then pop back to the surface after the transfer completes. So, land, sea, or air, you'll frequently see the cross-sim dip.

It also appears to me that the rate at which you drop until the new sim kicks in and corrects your position is 9.8 m/s^2. Its exposing a little secret of physics in SL -- it's both client and server side. Both ends perform the calculations, rather than the client being constantly fed position updates from the server, because the server can't provide that information at 45 FPS, but it wouldn't look smooth if the client didn't update what you see on the screen at that rate, so what happens is, the client computes the movement of objects it can see and continues to move them even in the absence of information from the server, extrapolating their motion from what it was last time it received into from the server. Normally this works fine, but if the server looses contact for an extended period of time, things can get out of sync. On the server side, your scripted vehicle is providing upward force or buoyancy or something to keep the boat afloat or the airship flying, but as you cross into a new sim, there's a bit of dead time when the old sim is no longer sending the client this information and the new sim hasn't taken over yet. The client dutifully continues to draw the physical motion of the vehicle on screen using the last information it received, but lacking the continued application of upward forces going on server-side, thus, in the client-side view, gravity is unchecked and your formerly straight-line flight suddenly turns into a downward parabolic trajectory. Then the new sim finally sends the client updated position information, and you pop back to where you should be.

The longer the sim transfer takes, the more obvious the effect is. It was during some of the longer transfers that I realized the dip was due to gravity. When the transfer takes long enough, not only is the dip obvious, but the fact that the rate of the dropping accelerates over time. And if you're emitting particles as you fly across the sim boundry, you can actually see the parabolic shape of your uncorrected trajectory, which remains in place even after the correction (since particles are entirely client-side, they don't correct in position even after the airship does).