[sldev] More crash rate statistics

Stickman stickman at gmail.com
Fri Aug 7 17:40:08 PDT 2009

> Here's a challenge to sldev. What do you think a) is the one variable
> viewer performance should
> ultimately be measured by and b) what are, say, three predictive
> variables that influence the dependent variable.

What a fun challenge!

It has been mentioned before in sldev that the developers/content
creators are not your "average" SL users. So the metrics they choose
may not be the best ones for the populace at large. But ask the
populace at large what they want, and even using statistical analysis
on their answers you may not get the heart of the matter. It's like
asking someone to self-diagnose what the issue is when only a trained
doctor knows the bodypart with the problem exists.

Anyway, for me personally... ... ...what a difficult challenge. D:
This isn't fun anymore.

The main thing that's important to me is productivity. Being able to
properly create things inworld. Kinda hard to fit into a metric. Not
crashing, naturally, is important to productivity. But there's a lot
of other factors, too, which seem like more of a problem than crashing
is, or ever was.

The metric to measure performance I would use is:

Communication and response from viewer to server.

The top three predictive variables are:
-Functional Inventory (never really had a problem with it, though)
-Rezzing working and timely (including textures, sculpts, etc)
-Attachments working (No "attachment already pending" getting stuck, etc)

There's a few other issues, like uploads, IMs, FPS, crashing, and
whatever else, but at this moment I'm not having a problem with them,
so they don't seem as important.

Also, a thank you to whoever fixed the double-upload notice in 1.27.2.
That's been bugging me a lot.

But -- that's me. For the average user, I would guess they care about
the same communication element the most. But I am going to guess that
their top three predictive variables would be:

-Functional teleports
-Functional attachments
-Functional rezzing/displaying of existing prims

This is based on what I can visibly see others doing a lot and having
trouble with. So they may not be long-term predictive elements if they
become rock solid, but the core issue of communication would remain
the same.

> *I* personally could live with more crashes if I would get working snapshots and fully rezzing textures instead.

The same amount of crashes as a viewer or so ago and having fully
rezzing textures instead? Yes, I can live with that, too. I had to
stop using Snowglobe because of the texture issues. I couldn't even
open them from inventory. I am really looking forward to full
http-texture support, as I expect a lot of speed out of it.


More information about the SLDev mailing list