Ardy Lay

Do AFK avatars drive new residents away? Absolutely, yes. But not absolutely every one. What I see is, people come in, say nothing, or something, doesn't seem to make much difference, then, if nobody greets them in a few seconds to several minutes they silently leave or utter something, sometimes something rude, then leave. Ideally, people will always get some non-automated greeting soon after they arrive. We don't pay people to be greeters, so, it's hit and miss whether someone notices the arrival and says something to them. It's our home. We should be allowed to lounge around, be distracted, take naps, wash dishes, do laundry, come back and read chat history, repeat.

Looks like they forgot again. I streamed some crowded events using Second Life Release 7.1.2.7215179142 (64bit) and viewers were expressing incredulity over the smoothness of my video stream. I hadn't the heart to tell them that my 60 FPS video stream was being captured from a viewer that was rendering at 120 FPS at the outset of the adventure, limited by the "sync rate" of my 5120 x 1440 display. SL window was 1920 x 1440. Unfortunately, as time passed, the rendering slowed down, but not because the crowd was getting larger, nor because of a change of scenery. What I saw changing was avatars were changing outfits as the 3 hours long party progressed. Not sure if this changing of rendered outfits caused an accumulation of sludge or what. At the end of the 3-hour event, rendering was down to 48 FPS in a crowd of 38. Some attendees had said goodby and logged out. The crowd peaked at 44 attendees if I include myself.

They will ATTEMPT to shoot you down using derisive language and fail whether you are joking or not. I'm not tinkering with making "materials" until stuff settles down. I'll look at what other people make and not stress over it.

Yeah, I bumped into a tree while walking and it sounded like I hit it with a truck bumper. WHUD! I then got out some things and walked on them, bumped into them and dropped then. All sounded alike. Weird. Crazy loud too. The one impact I tried that wasn't loud, and perhaps didn't make a sound at all, was by control-dragging an inactive object into an avatar to move them. Dragging an active object into them did go WHUD!

Arguments on Second Life Forum are like

Yes, atlasing is good, but you and I both know that "proper hands" are diminishingly few in Second Life.

My take on all this is: Experts are people who gave themself the title. People repeat outdated first and secondhand information as it it's eternally relevant. People describe performance of hardware they don't have. People describe performance of software versions they have never used. So, looks like "people" is what all those have in common. So, after seeing all this rubbish flying around, I'll add some more. FRAMES mean nothing. What's in a frame? Stuff. How much stuff? Dunno. So, "frames per second" is completely useless as a performance metric BUT is a really good comfort metric, as long as the inter-frame time is fairly consistent. I remember, long time ago, GPU specifications had stuff like how many triangles it renders per second and what its texture fill rate is. Second Life Viewer does report triangles per second. Would triangles per second anywhere be useful to maybe come closer to a comparable metric than frames per second at such-and-such nightclub on December 11th at 2:26 AM wearing high-heels and a French teddy? Oh, in case that wasn't clear, the myth is that FPS is a useful bragging metric in Second Life.

Handy dandy "Search Menus" tool.

I did not use any of the Second Life Viewer's metric displays to evaluate the performance of my network or the performance of the viewer when I deliberately delayed delivery of packets via my network. I used the same external tools I use when measuring performance of voice and video transports. The Second Life Viewer's behavior as experienced by the user is all that I cared about. As data was delayed on the way to the viewer, I, the user, could 'feel' the delays in on-screen updates in the location of objects and avatars. There are two interpolation mechanisms in the viewer that have some effect on this. You know about them as you have described them in great detail in the past. I left them at their defaults. It's interesting to note that, yes, some packets may arrive too late to be used and may be counted as "lost" by the viewer, and that some message types sent via UDP will be resent if missed, either by loss or excessive delay. Mostly I was trying to get a feel for how network characteristics affected the end-user experience on Second Life. I ran all the same tests on several other applications. Telnet and SSH really sucked to use when delay was introduced. Voice was okay with some delay except for the time-shift issues that caused participants to overlap and collide when the delay was more than 120ms. One-way video gives no hoots about delay. ALL of them sucked when loss was introduced along with the delay, because of the timeouts and additional delays with any retransmissions. Most voice and video transmissions tested did not loss well. SRT introduced delays by buffering the video and requesting retransmission of missing data. It tolerated up to 20% loss unless the bandwidth available introduced so much delay that the retransmitted data arrived too late to be played, limited by the allocated buffer size. SRT with elastic-buffering just kept increasing the depth of the buffer until it hit a limit and crashed. HLS, however, just makes the user wait for the data to arrive, no matter how long that might take, at it is downloading files to play sequentially. With the Second Life Viewer, which I personally have used for many hours a day since March 16, 2008, loss in-flight ALWAYS sucks when that which is lost is required. You know the messages... The ones that result in retransmissions and timeouts, up to and including disconnects. However, if the round-trip time is reasonable and there is sufficient bandwidth to carry the retransmissions without causing additional loss, some retransmission activity can be tolerated. What seems to annoy me the most is the loss or delay for "course updates" that result in increased inaccuracy of avatar position and the loss of "full updates" that result in objects, including avatars, sticking around in the viewer when they should be gone and incidents of some objects, and yes, sometimes entire avatars, not appearing when they should be visible. I, however, wasn't adding the complexity of teleporting and region crossing. As you have described in excruciating detail, these activities are way more sensitive to network foibles and infidelities, resulting in much anguish over disconnections. I greatly appreciate the efforts being made to find the causes of these sensitivities and correct or mitigate them.

Sad we still only get shadows from two of the local lights. I feel like I am missing something.

WiFi has definitely improved, but we often get calls from people using "mesh", and THE PROBLEM IS ALWAYS PACKET LOSS on their WiFi.

Keep it up and I will TOAD you and make you run SL on dial-up! SL works on slow networks as long as there is no packet loss. It's an awkward balance but I have done it. And by "slow networks" I don't mean garbage multi-hop wireless links. I did say "no packet loss." This must include UDP traffic. I have total control of the data rate permitted on my home fiber Internet connection. I work for the company that provides it. SL works great on our network as long as the traffic from server to client isn't going through Cogent when Cogent is congested. Fortunately, we can just prone prune them when they get annoying. Anyway, I have set my data rate down to 768 Kbps and had SL work fine. At that data rate the downstream and upstream traffic are "rate-shaped", meaning buffered and released on-rate. I said "fine" instead of "excellent" because sometimes there is some loss because the buffer is of limited capacity. At somewhat higher rates, the buffer doesn't overflow, and at much higher rates, the buffer appears to be empty all the time. I know that "FPS" is the quality metric that users care about but it's not a decent metric to use when trying to quantify the rendering work being completed in a finite time because the content of frames is highly variable. Maybe use triangles? I know SL renders a hell of a lot of triangles per second. Try comparing that metric to triangles per second in some other rendering engines.

Yo. Dude. You are ... what are you doing again? Explain it so Linden Lab can understand.

New challenges every release. You said that, right?

/me loses all hope.

Some network operators, access and transit, discard UDP traffic in times of congestion, perhaps thinking that only BitTorrent still uses UDP.

I have done this. Of course, It also works for making stuff at altitude if you move your plane up high. When this doesn't work is when the object being placed has a visible representation that is smaller than the bounding box. That had me also enabling bounding box metadata display, and at that point the screen got so busy that I could not tell what was going on and just gave up. It would have been much easier if the viewer or simulator could just inform me about the one thing I am working on. This is Second Life, not manual technical drawing on paper where my only option is to make construction lines.

World Map still looks weird. Is the future here yet? https://jira.secondlife.com/browse/SVC-7552

I meet a lot of people that assume that if the software / service allows them to do something and gives no warnings then it must be okay to do it with impunity and no other user can tell them otherwise. I have been threatened by several that they would abuse report me for returning their objects that encroached upon my land. I don't let such threats stop me. If the encroaching object(s) bothers me in some significant way I will return it. If I get severe negative feedback from that object's owner, then I return any additional encroaching objects of theirs that I can, even if those objects were not bothering be before their owner shot off their mouth. Would be helpful if the viewer could warn people that something they are positioning is encroaching on a property line. Then, maybe, a smaller number of people would be arrogantly ignorant.

Blame space weather. https://spaceweather.com/ I'm not saying it is space weather, but space weather!

I wonder how costly operating the asset pre-processor service for this is.

Hey y'all! Watch this! (powers up Dell Dimension 4100 made in 2001)

Some creators manipulate things in ways things were never meant to be manipulated resulting in weird results at a later date. I could describe a few instances for you but would be accused of picking on "creative geniuses" that were well aware they were causing future problems.

Uhm, do Boopies explode similarly to how Rodney Linden's bear exploded? That thing got me ejected from a party!

Don't create a new demand for specific creator's prims that were somehow illicitly obtained. We already had that problem with some now defunct security systems. They are defunct because somebody was selling illicitly obtained transferrable prims that could be used as keys to disarm them. We discovered the prims had been obtained after some hooligans put much time and effort into defeating Second Life's permissions system. When I reported this, I was told "When there is a will, there is a way. When a sufficient reward is at stake, someone will find a defect and exploit it."