Monty Linden

People will miss it once we fix it.

I was a little wary of watching a video at hardlimit.com but that was interesting. I'd agree about the simulator<>simulator handoff and would love to capture that sometime - more is going wrong in there. Very familiar with sitting in the dust after a bad crossing.

I haven't looked into this specific problem but one universal throughout SL is that there's very little ordering guarantee between the various message streams. UDP messages aren't ordered with respect to TCP (UDP deprecated) messages. Non-llmessage events are not ordered relative to UDP messages. Independent Caps not ordered with llmessage or events, etc. Most of the time there will appear to be an order but it's accidental. This gets learned when something odd crops up and a defense is put in place that was always needed. The problem and its patch gets labeled a weird behavior of the network when it's actually a designed-in necessity and should have been described in the protocol. But so it goes. If you're building a fresh transport or viewer implementation, you're going to be going down the rediscovery path. That includes the SL mobile viewer, libremetaverse, and Sharpview, to name three. An aid to finding these conditions would be fuzzing the network timing a bit. Delay UDP with respect to TCP (12043, 12046) and vice versa. Randomly delaying selected responses within the TCP stream. (Difficult without man-in-the-middle techniques. Might need to do something within the client.) This should reveal assumptions earlier and at a time of your choosing. Thanks, I'm glad that's looking good in your testing although I'm not certain it's related to the message problem above. I get these in testing constantly (both pre- and post-work). They're like Keystone Cop shorts: avatars go flying off of vehicles, attachments fall uselessly to the ground. It's a madhouse. Vehicles just add an additional layer of order and timing assumptions that simply aren't right. Getting to robust is going to take a few releases....

Beta grid is up. File a support ticket to get a refresh if you're still having problems.

A support ticket is a fine way to get immediate attention on a local problem. But it doesn't feed engineering activity like you may think (I can't even view support tickets). Canny issues go directly into engineering and give devs the ability to ask specific technical questions as well as allowing the larger community to see the problem and add clarity (or confusion or just :popcorn:).

Yep, I've sent this along via internal comms but that's not the same as a tracked and visible bug report. A Canny issue would be appreciated (either server or viewer bug - suspect both may be interested). And everyone will have something they can monitor. A quick search in Canny didn't produce a matching problem description though it did find a few (*cough*) alpha problems. So a new issue is the way to get a bug fixed.

Before you spend money, always do the cheap/easy/likely things first. You can run 'Task Manager' and monitor memory usage while you're using SL. If memory use isn't near capacity when problems arise, then adding more may not help. Time to look elsewhere. Windows' 'Event Viewer' very likely has a record of internal problems leading to your viewer woes. But this is a tool that devs don't particularly like or use (though they should). Teaching it is beyond a response in a forum thread. But if you want to learn how to diagnose problems of any kind, this is where you might start. It's where a rent-a-nerd will start...

Nope. EAC problem is bad implementation (mostly). The teleport failure problem is bad design (mostly).

This may be contributing to your pain. If expanding memory is not an option, try fully exiting all non-essential applications (all browsers) before starting SL. You might also want to try a low-footprint viewer (something other than the Linden viewer). (Suspect you are failing due to a storm of paging activity. You can monitor this condition if you know how to use Task Manager and Event Viewer in Windows.)

We thought everyone would rise above the problem...

Should be up now. @Henri Beauchamp's bug didn't make the release notes but is known. Fix is in progress...

It's the same number. But now wrapped in a URL to tantalize and tease the reader. Do you dare click it? (Yes, it's safe to click.)

A 'ping' won't tell you much, particularly that one. 'lindenlab.com' is the corporate website and the fronting services likely block ICMP. Login occurs on 'login.agni.lindenlab.com' and that is responding to ICMP pings but that's not a promise. The 'Access Denied' bit *is* useful and you may be able to take that 'Reference #' to support for help. And it may clear on its own after some hours.

Caspertech support should be able to help. Start there if anything is amiss...

Drop a viewer enhancement request into feedback. We should be able to manage LMs like browsers manage BMs. (Probably)

I created an explicit Canny issue for the missing EAC messages so that it can be tracked and possibly fixed separately from the EventQueue problems. https://feedback.secondlife.com/server-bugs/p/simulator-http-setup-missing-establishagentcommunication-messages

The 'feedback' issues (Canny) represent new development including a new external service. That doesn't happen in days (when I said 'slow,' I really meant slow). That's why you need to follow through with a support ticket and maybe a bug report in feedback. These have faster return times (but not always with the response residents want).

With a mix of failing and succeeding accounts on the same machine, backend systems, usually inventory, are at work. A support ticket is the way to start.

I'd expect the viewer to composite the information sources to produce lists and visual feedback (caveat: never dug into this system before). New inventoried LMs certainly show up for me. But I can also imagine that stale inventory cache would leave things around to be found by the map code. The LM list in the world map also appears to index by name and so non-identical LMs with the same name might be considered identical to the map. This looks like a grand opportunity for filing some Canny bugs!

Notecard-based return receipts mapping object to location might be a nice touch...

There is an order to it. The idea being to slough off suitable victim objects when limits are encountered. But the specification is complicated and subject to change without notice. If you experience something that seems at odds with sensible victimhood, just file a bug because it needs attention from time to time (and I believe has received some recently). Such bug reports should have as much detail as possible (region, parcel, location, time, date in the Mayan calendar, etc.). This thing is a function of 47 or more variables.

Are you kidding? We have to share trouser pockets here...

Ditto. Follow Henri's advice on this one....

For transparency, I made some Canny issues for this: LSL llHTTPRequest Supported Search API These are bug/feature requests and so the response time on them is going to be slow. Fast responses come from support tickets and elsewhere. But people should be able to comment and upvote on the issues.

I do not recommend holding your breath just yet...