Jump to content

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


You are about to reply to a thread that has been inactive for 715 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Just now, Klytyna said:

calculating the display of avatar height seems to involve the phases of the moon as seen from Pluto run through some bizarre form of differential calculus working to base 13, multiplied by the value of the users breast size slider...

hehe. The way that avatar height works is one of the "quaint"* things about SL.

I think the person who wrote that particular bit of code was likely stoned at the time.

 

* By "quaint" I mean annoying as hell.

  • Haha 2
Link to post
Share on other sites
  • 2 weeks later...
  • Replies 228
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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 p

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

The Smooth Rider All the technology I've been talking about here has now been put into a bike you can buy. It's for sale at Cute but Fast at the 2RAW EXTREME racetrack sim. It's priced low to get

Posted Images

New update to BUG-214653.

Not a fix yet, but an approach to one. If you've been inside the viewer or really understand the message system, take a look.

I've been putting logging code into Firestorm for object updates and watching region crossings go by. The built-in logging doesn't show object updates in detail. I have lots of message logs, some annotated. Here's a detailed log of a successful region crossing, with an explanation. If you ever wondered what was happening down at the message level, here it is. Region crossings which have this sequence of events work fine. If the message sequence deviates much from this pattern, things go bad.

At the viewer object level, there's a hierarchy. The root of the object sat on (in a region crossing, usually a vehicle) is the root parent. The sat-on object's prims are its children. The avatar is a child of the object sat on. The attachments are children of the avatar. (Yes, the hierarchy here has three levels.)  If the object updates arrive in the viewer in vehicle-avatar-everything else order, all is good. If something arrives before its parent, the viewer tries to cope. But it's difficult, and things can go wrong when the pieces are spread across two regions and several coordinate systems, some of which are not fully defined yet. This is the source of giant jumps and snap-backs at region crossings. It's the source of the visual mess where you cross a region boundary and some attachments and vehicle parts disappear for a while. And it's part of how attachments get lost.

If the messages are delivered in the normal order, everything works. So the update to the JIRA is about how to do that. It won't fix everything. But it will fix some of the problems and make the remaining ones far less mysterious and unfixable.

"This is not the end. This is not even the beginning of the end. But it is, perhaps, the end of the beginning." Churchill.

Edited by animats
Fix link to message log
  • Like 1
Link to post
Share on other sites

@animats thankyou for the dogged tenacity in this. I've added my comment to the Jira too. We really do need a little steer from the server side, I don't think this can be solved on the viewer alone, but the experimentation you have done thus far is valuable in framing discussions around the problems even if the none of the ideas we throw at it end up sticking.

  • Like 1
Link to post
Share on other sites

Agreed. We can only see dimly here, because there are server side problems and we can't see into the servers. We can look at OpenSim, but it's internals are completely different. (OpenSim is written in C# and uses TCP for sim to sim communication. SL is written in C++ and uses UDP for sim to sim communication). We can look at message logs, see things happening out of sequence and causing trouble, but can't tell whether the sim sent them out of sequence or they became out of order during transmission. The idea here is to nail down some of the variability so that some problems are solved and others become more clear. This should turn what is now a really hard problem into a succession of not so hard problems.

This is like peeling an onion. When I started, there were a whole range of unsolved problems at sim crossings. Some I've been able to work around in LSL. One required a fix in Firestorm. I've produced bikes that drive well over region crossings. Each fix peels away another layer of problems obscuring the deep problems that cause sim crossings to fail outright. We're getting closer.

  • Like 1
  • Thanks 1
Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 715 days.

Please take a moment to consider if this thread is worth bumping.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...