20 years, still full crash on teleport

[Henri Beauchamp]

11 hours ago, Monty Linden said:

I'll share a recent finding to illustrate what this looks like.  If you've looked into the code you may be familiar with the TeleportFinish message.  This is sent to the viewer which triggers it to move into the destination region.  The discovery is that this message is often queued but never delivered to the viewer leading the viewer to disconnect

That's a very interesting find out !...

It should be rather easy to fix this issue on your side: checking on a non-empty queue should hopefully not prove too difficult... 🤣

12 hours ago, Monty Linden said:

(yes, it's the viewer that disconnects)

Well, sadly, the viewer cannot guess the arrival sim IP and port which are sent via the TeleportFinish message... We could increase the timeout before disconnection up to the limit that would make the departure sim disconnect in its turn (3 minutes, I guess ?), but it would not improve the least the user experience and only frustrate them more for having waited 2 more minutes for nothing.

[Ardy Lay]

4 hours ago, Henri Beauchamp said:

That's a very interesting find out !...

It should be rather easy to fix this issue on your side: checking on a non-empty queue should hopefully not prove too difficult... 🤣

Well, sadly, the viewer cannot guess the arrival sim IP and port which are sent via the TeleportFinish message... We could increase the timeout before disconnection up to the limit that would make the departure sim disconnect in its turn (3 minutes, I guess ?), but it would not improve the least the user experience and only frustrate them more for having waited 2 more minutes for nothing.

Henry, I suspect you are going to implement this and try it out yourself.  I suggest displaying an intermission message with a countdown timer and your favorite cartoons in the corner.  I find that the region I am attempting to teleport away from can hang on to me for up to FIVE MINUTES.

[AmeliaJ08]

TP bugged 3 times within 30 minutes tonight. Is it at all related to region load? I am doing the weekend shopping trip and moving in/out of quite populated regions.

 

[johndoe32]

I have many TP disconnects per day using a fiber connection, when I switch to my own ISP (WiFi) got none but is very slow that's why I prefer to use the fiber connection and reconnect on every disconnect. Some days are annoying, 1 TP => 1 disconnect, Reconnect, 1 TP, 1 TP, 1 TP => Disconnect, and so on .....

[Anna Nova]

I get  "view IMs or quit" a lot, usually soon after log-in as I traipse round my usual spots, and always thought it was because I was in Rural UK.  It, 'subjectively', seems better if I log-in via VPN with a California exit node (I use ProtonVPN), but I emphasise the 'subjectively'.

I did try @Henri Beauchamp's viewer, but there are terrible things it does to my inventory, and have abandoned it, I'm afraid.  It was faster at many things, but it's not clear to me if it was better at this.

[animats]

Some of us on the third party viewer side are trying to figure this out. See this long, very technical discussion of what's going on down at the message level. Monty Linden has been looking into this. So have Henri Beauchamp, Beq Janus, and myself. Henri has added more logging to his viewer. Beq and I have been looking at logs and drawing event diagrams.

There is general agreement that some necessary messages do get lost.  "Why" is still elusive. The code involved dates from the early days of SL. All this attention is starting to make some old, mysterious problems look less mysterious. Progress is made by getting from "my teleport failed" to "viewer sent message X to simulator, which we think should have been replied to with message Y, but message Y did not arrive at the viewer." That's not a fix, that's just trying to understand the problem.

None of this is fun. But it is necessary. There's now a reasonably good chance that some long standing problems will get fixed. At last, people are putting a microscope on the part of the machinery that is giving trouble. I'm encouraged.

[Profaitchikenz Haiku]

Whatever is happening seems specific to SL: I am getting these "Darn---" messages several times a day in SL, but I have never seen them in any of the other grids. But they're also nothing new so can't be used as a stick to clobber AWS.

I have an two occasions seen this TP fail when trying to go from one location to another point in the same region, and in both instances the region was empty so it doesn't seem to be due to avatar-loading, and due to the nature of the regions it wasn't due to breedables, AMT's vehicles, or any of the usual suspects.

 

[Paul Hexem]

3 hours ago, animats said:

None of this is fun. But it is necessary. There's now a reasonably good chance that some long standing problems will get fixed. At last, people are putting a microscope on the part of the machinery that is giving trouble. I'm encouraged.

I may have to take back some of the things I said about LL, then. 

Nice to know we've got capable people looking at it and you're actually finding things. I'm still blown away that it's taken 20 years and volunteer third party devs though.

Without having read all of the other thread, how likely are we to see a reconnect option?

[Henri Beauchamp]

11 hours ago, Anna Nova said:

I did try @Henri Beauchamp's viewer, but there are terrible things it does to my inventory

What things exactly ? O.O

My viewer is in fact MUCH safer than any other viewer, since it never touches your inventory structure unless you manually trigger an action it offers (such as consolidating base folders, or recreating missing calling cards), unlike what even LL's viewer is doing in your back (consolidation and calling cards recreation are systematic at each login with LL's v2+ viewers and all the TPVs forked from it).

It also got safe guards against essential folders deletion or move to another folder (such as the COF: deleting or moving it could get you into BIG troubles), while allowing you to delete (if and only if you so wish and do) some unnecessary folders that got introduced with v2+ viewers and are just clutter for v1 viewer old timers like me.

As for its consolidation algorithm (only triggered on demand), it is more elaborate than LL's and also able to, sometimes, repair ”broken” inventories (inventories with duplicate base folders, for example).

This is not because the inventory is presented differently (like a v1 viewer does), that it got ”terrible things” done to it !

Edited September 21, 2023 by Henri Beauchamp

[animats]

6 hours ago, Paul Hexem said:

Without having read all of the other thread, how likely are we to see a reconnect option?

I think it would have to be initiated by the server. The server tells the viewer to do a teleport by sending a TeleportFinish message. That tells the viewer the info needed to connect to the destination region's simulator. But that info has a specific UDP port and seed ID, and I think those are "used up" if the teleport fails.

7 hours ago, Profaitchikenz Haiku said:

Whatever is happening seems specific to SL:

Yes. The Other Simulator does not behave quite the same way. I've been logging that, and it's mentioned in the other discussion.

What got me into this problem is that I first tested my Sharpview viewer's connection to neighbor regions against the Other Simulator. Sharpview is all new code, with completely different bugs. I got that connection working, then tried SL, and the protocol got stuck waiting for a message. The devs for the Other Simulator try to emulate what SL is doing, so this resulted in discussions at their dev meeting over what was supposed to happen. Nobody was quite sure on the Other Simulator side. I started the other discussion here, and it came out that no one was entirely sure what was supposed to happen on the SL side. Then we all realized we had a problem.

This is how you find protocol bugs in the real world. When there's only one implementation, you can have bugs where things seem to work, but you're not sure why, and maybe they fail intermittently. When you have multiple inter-operating implementations, there's a period of much frustration during which all the players compare notes and eventually converge on success. For the parties involved to sometimes be annoyed with each other is normal. For SL, it's the third party viewer developers who see this problem most clearly, because they talk to both SL and the Other Simulator. So TPV developers do a lot of logging and looking at logs.

Now that SL has a mobile viewer in development, they have two implementations of their own, which means they have to face these kinds of problems internally. This provides motivation for LL.

When you look at SL immersion-breaking failures, most of them appear to be problems where one end is waiting for a message the other end isn't sending. Actual crashes, where the viewer suddenly exits or a region goes down, are rare. The common intermittent problems - teleport fail, region crossing fail, stuck in login connecting to region, objects not appearing, clothing not appearing, avatars stuck in cloud mode - are all cases where some essential message didn't arrive. That doesn't mean there's a single underlying bug, but there's likely some commonality to those problems.

[Liv Simondsen]

I used to crash on tp with Firestorm. A lot. 

Now I am using Alchemy and it happened one time in 1 month. Not bad I’d say. 

[Anna Nova]

12 hours ago, Henri Beauchamp said:

What things exactly ? O.O

...

Whenever I  'attach to' I get an extra .(wherever) folder added.  Not saying you are wrong to do that, but I don't like it.  So instead of one folder with 5 things in it, I get one folder with 5 subfolders each with one thing in it.

[Kathrine Jansma]

55 minutes ago, Anna Nova said:

Whenever I  'attach to' I get an extra .(wherever) folder added.

That sounds like the RLV support for non-modify items.

[Henri Beauchamp]

1 hour ago, Anna Nova said:

Whenever I  'attach to' I get an extra .(wherever) folder added.  Not saying you are wrong to do that, but I don't like it.  So instead of one folder with 5 things in it, I get one folder with 5 subfolders each with one thing in it.

This is only the case in the #RLV folder, and you may disable this behaviour...

This is strictly how RLV is supposed to work for no-mod attachments and how Marine Kelley specified it (see the text after ”HOW TO SHARE NO-MODIFY ITEMS”); the Cool VL Viewer uses my own fork of Marine's implementation, which abides strictly to her specifications. Attachments get renamed when they are in #RLV, to add the joint name to their name (this allows to avoid detaching attachments on locked joints by accident when you change outfits, and prevents the detach/auto-reattach sequence that would ensue and could break some scripts or trigger anti-detach alarms in some objects); for no-mod attachments (which cannot be renamed), RLV instead moves them into a newly created sub-folder bearing the joint name.

However, and since some people are used to RLVa viewers' way of doing things (RLVa is a rewrite of RLV and differs in many subtle and less subtle ways from RLV) , I implemented a setting to disable the auto-renaming of attachments in #RLV (which also stops the viewer from creating sub-folders for no-mod attachments): the toggle is ”Advanced -> ”RestrainedLove” -> ”Add joint name to attachments in #RLV/”.

A simple question on the Cool VL Viewer support forum would have given you the answer...

Edited September 22, 2023 by Henri Beauchamp

[Anna Nova]

21 hours ago, Henri Beauchamp said:

...

A simple question on the Cool VL Viewer support forum would have given you the answer...

My bad, apologies.  I'll try again.

[AmeliaJ08]

Grrr, happened again! seemed like things might have been improving the past week or two but it's happening now

[Monty Linden]

Haven't changed anything yet.  You're still in Vegas...

[Love Zhaoying]

4 minutes ago, Monty Linden said:

Haven't changed anything yet.  You're still in Vegas...

So many possible meanings!

Is crapshoot (literally, the gambling term)

Is stuck in penthouse with Mike Tyson's pet tiger

Is in an oasis in the dessert

[Extrude Ragu]

On the issue of people going to play something else due to teleport failure, a similar issue occurs for sim restarts.

Tuesdays we can have multiple visitors in our sim but the sim restarts, and the user simply doesn't log in again, or teleports to their home and never returns, which can hurt the momentum of smaller community sims.

[Profaitchikenz Haiku]

Something interesting and unexpected today:

I was wandering around with my Alt account, when he got the "Darn, you have been logged out" attempting a TP.

I logged in as myself, and saw he was shown as online, so I sent him an IM. No response, obviously.

Two minutes later I sent a followup IM. This time, I got the "user not online" as I expected.

So in addition to losing track of where the avatar was, what windows they had open, etc, SL is also not even able to change the status of one of these in-limbo souls? It seems to me slightly odd that a user should be logged out of SL and yet their status isn't then set as being offline?

[Paul Hexem]

4 hours ago, Extrude Ragu said:

On the issue of people going to play something else due to teleport failure, a similar issue occurs for sim restarts.

Tuesdays we can have multiple visitors in our sim but the sim restarts, and the user simply doesn't log in again, or teleports to their home and never returns, which can hurt the momentum of smaller community sims.

At least with the restarts you can theoretically stay ahead of it, moving region to region, as they don't all go down at once. You have another option besides "stare at a gray screen or quit".

[AmeliaJ08]

15 hours ago, Profaitchikenz Haiku said:

Something interesting and unexpected today:

I was wandering around with my Alt account, when he got the "Darn, you have been logged out" attempting a TP.

I logged in as myself, and saw he was shown as online, so I sent him an IM. No response, obviously.

Two minutes later I sent a followup IM. This time, I got the "user not online" as I expected.

So in addition to losing track of where the avatar was, what windows they had open, etc, SL is also not even able to change the status of one of these in-limbo souls? It seems to me slightly odd that a user should be logged out of SL and yet their status isn't then set as being offline?

That reminds me somewhat of the type of logout that can happen on a bad region crossing. I have lost my passenger (they told me about it on Discord) while I could still see them logged in at the bottom of the sea. Their avatar would stay there, visible on radar, could send IM's to them etc and to all intents and purposes appeared logged in until they actually logged back in and the avatar would disappear.

So yeah it does seem like the region loses track or isn't informed somehow that the user has disconnected.

Edited October 4, 2023 by AmeliaJ08

[AmeliaJ08]

A slight deviation from the topic but I've always wanted to know: why does the client need a full restart to reconnect? It's not a huge thing (but still, quite annoying) to have to close the client and reopen it but I've always wondered why that had to happen... why not have a reconnect button or simply go back to the login screen on disconnect?

 

[Paul Hexem]

On 10/4/2023 at 6:46 AM, AmeliaJ08 said:

A slight deviation from the topic but I've always wanted to know: why does the client need a full restart to reconnect? It's not a huge thing (but still, quite annoying) to have to close the client and reopen it but I've always wondered why that had to happen... why not have a reconnect button or simply go back to the login screen on disconnect?

That's not a deviation at all. It's a big part of the problem.

As was previously mentioned, other software gives you various refresh options or throws you back to the login screen. SL is unique in that the entire client craps out when the connection does.