Suggestions reality check needed.

Or in other words ... it's depressing to see so many clever people offering excellent ideas, only to have them predestined for the bit bucket. Many have very clearly taken lots of hours to think about the ramifications and possible means of implementation, only for all this effort to be wasted.

Over these few years of SL's life since pre-launch, how many suggestions have been proposed, and how many taken up? The percentage implemented is so utterly tiny (say 1 in 10,000, or 0.01%?) that it makes a mockery of the forum: it should be called the "Allow The Clever Ones To Let Off Steam" forum, truth be told.

Perhaps because of this, we've seen many many designers, programmers, and artists who were once prolific contributors go silent --- some merely no longer offer ideas here, and others have left for good it seems. That's sad.

It's also inevitable. LL doesn't have the manpower to implement any significant part of all of this. That's no surprise of course, but it is slightly surprising that despite knowing this, the flood of suggestions continues to pour into Feature Suggestions and down the drain into oblivion.

Why am I writing this? Because I think that a substantial proportion of these ideas being offered are absolutely priceless --- LL couldn't buy such a steady stream of insight and of user requirements if they had 10 times as much money to spend on official developers. And this very valuable torrent is being knowingly dumped, through lack of alternatives. That's not good.

So, here is a little question for this forum, which is a sub-forum of Resident Forums->Feedback: do you have any Feedback for LL in the form of Suggestions on how they might reorganize to be able to make better use of this mountain of ideas? Voting didn't do it --- all it achieved was prioritization without increasing the rate of takeup, which is still near nil.

Something better is needed. Letting off steam may be therapeutic for a few, but in general people's time should not be wasted, knowingly.

HEAR HEAR! Well said in entirety. You point out the problem, admit LL has their plate full, ask for options. Couldn't have put it better.

I have only one thing that I can think of: separate the toys from the important things. HUDs are nice, and of great value. Dunno as they were more important than a lot of other things that have been suggested. I could have done without SL videos like forever. And floppy prims? Cute, but not when core bugs still exist.

When LL looks at a suggestion, they should ask, "How front-burner valuable is this?" and if it's priority valuable, do it! Toys are nice, but basic functionality is nicer. I'd trade all the flexible prims in 1.9.1 for an additional texture permission that allows no-trans textures to be transferred if they are decorating a prim. In fact, I think every texture merchant and builder on the grid would give a [insert favorite body part here] for that feature.

I agree on this. My main gripe is the number of good, easy to implement suggestions (some of which are 1 minute changes that would be very beneficial to people like slight UI adjustments or such) here that seem to pass by in favour of a number of performance destroying, complicated and often not ideally implemented features.

Take 1.9.1 (now 1.10.x), it's cool and all, and it's made a great step with occlussion culling to improve performance, but every other feature IMO is worthless as far as I (and majority of users I think) am concerned. But they are performance intensive, things that could hurt slower machines, just for a relatively cosmetic thing.

Really what they need to do is consider what their priorities should be, the latest graphics features and effects, or gameplay and useability? Because the majority of ideas here are in terms of gameplay and useability, be it interface changes, privacy options, new build options (that allow prim-heavy solutions to be replaced by faster, easier ones), scripting changes (again allow impossible things that LSL can't do, or that requires lots of roundabout code to do) and all the others.

I'd be much more excited about the upcoming release if it was occlussion culling (great performance booster) plus a decent, well-defined, useable and flexible set of privacy options. We've had loads of them, ranging from fairly simple and far too restricted, to complex and limited but also have had many relatively simple (some more difficult to implement I suppose) but powerful suggestions as well.

Thanks to both of you for replying, positively.

I tried to avoid giving any solutions of my own in my post, to see what new things people could come up with. If there is anything that this forum has proved, it's that there is no shortage of good ideas around.

For example (and I'm saying this in order to close off that particular avenue in this thread), literally thousands of posts in these forums have examined the ways in which Open Source could help bolster LL's manpower deficit. There must have been at least half a dozen entirely different methods described by which some of that huge manpower reserve could be harnessed by LL. But leaving aside everything to do with FOSS completely here (please), there must be a ton of other solutions out there as well.

I started to think "Oh no, not another feature" on reading Haravikk's post, but then I realized that he was not really describing an actual feature but a class of features as being of overriding importance, namely all those that are efficient.

Now I'm pretty sure that this is something that everyone except the terminal "I'm alright Jack's" can agree on: that one of SL's worst traits is pure and simply, slowness, unless you have fairly top-end machinery. Indeed, I have several local friends who left SL with comments along the lines of "I just can't be bothered to play anything so sluggish". Well they certainly have a point, but while I agree with them and with Haravikk, ultimately this is just prioritization again. It still won't increase LL's rate of development, nor the related rate of takeup of good Feature Suggestions nor of top voted-on features.

If one understands that LL's small team cannot possibly maintain an effective rate of development of good suggested features (and that's undeniably clear to anyone who is able to count and not afraid to state the obvious), then it is probably also true that what's needed to solve the problem is something entirely new in an organizational sense.

Random thoughts on organizational possibilities:
No doubt there are dozens of other avenues along these lines, all aimed squarely at the central problem of tackling what is now clearly an endemic internal problem at LL, ie. not just a lack of manpower but apparently an inability to break free of that constraint.

Things just aren't in a good state of health at all: the ratio of Features-Implemented to Features-Suggested tells us that in huge, neon-lit capital letters. And that's certainly not because the suggestions are poor. Some lateral thinking may be needed.

Well, I have (and have had for some time) many theories on why SL is so sluggish. Some are likely only partially right... but others are probably right on the button. Here are a few areas of "major lag issue" I theorize:

* Seriously outdated Havok. Forget the eye candy. Update Havok!

* Avatars far too complex. The most serious lag issue on SL as far as I can determine client-side is avatars. LL just made them too complex for their software engine to handle. Get 20-30 avs in the same area and you have a recipe for stand-still lag. It's a durn shame we can't get 200 avatars on a sim for big events. I mean avatars on SL look great, no doubt about that. Looking great doesn't mean beans when ya can't move or type. I think they could drop a notch on avatar rendering complexity and still do pretty well graphics wise. Of course, that can be adjusted client-side, but no client side adjustment is going to stop an avatar with mega-prim hoochie hair, or an av ridiculously blinged out to 1000+ prims.

In a related issue...

* Over-stuffed bandwidth. I have no way of knowing this for a certainty, but I have a heavy feeling LL simply does not allow enough bandwidth per user to handle the needs of the system. I strongly suspect if bandwidth were increased, we would likely see lag disappear overnight. That is pure allocation of resources and is likely a result of trying to support too many free users at the cost of system performance... which is really not fair at all to the paying users. I don't mean to start a "I can't afford SL" battle because it's a dead-end argument. But when people do pay for a service, they should have a right to expect decent performance. Maybe that is one way LL could encourage people to be premium... offer to double or even triple their bandwidth allowance. I bet a whole lot of people who couldn't afford SL would suddenly, magically come up with some funds.

* Basic database issues. I have felt for a long time (from perceived activity) that SL's basic database structures are totally kluged. One can't do an inventory search without lagging to as standstill for up to 3 minutes. (I mean, how long does it take to do a simple text search, anyway?). Textures sometimes take ten minutes or more to load (to the point that many vendor and market areas are close to unusable any more). Sounds are heard 15 seconds after a gesture is performed (kinda messes up the whole gesture concept). It just seems that the deep-core data structure and data routines simply do not work well. My suggestion would be to stop developing toys and concentrate for a while on re-writing the core database routines and structure.

* Illogical structure design. What logical reason could there be for requiring someone to enter 3 letters in the Region Search engine before any sims show up? My paranoid side tells me it was some ill-conceived "security" move that has little basis in reality or logic. Every list-based search engine I have ever used has started displaying a list from the first character entered. Imo, that's just plain bad program planning (even Lindens have commented this was a bad idea). Why is it that the FIND function only lists the first 100 finds (you can't even find all the Lindens now). And I think it's pretty solid that when someone enters ELF in the Search engine, they are NOT looking for "Help YoursELF Industries". These are basic conceptual problems that have gone unfixed for a long time. And it's not like they haven't been discretely pointed out to LL time and again for months on end.

* Stacked servers. No matter what the claims, I find it difficult to believe that stacking four sims in the same box doesn't present bottlenecks. Even if they do have four microprocessors... they still share the same hard drive, same databus, same network card. Sure, one can design caches and buffers and streamlined routines. But none of such is going to completely stop collisions of four full sims trying to access the same resources at the same time. Four sims on the same box would also potentially make the box four times more likely to crash and require resetting. I can understand the concept-- but I have a lot of trouble buying the claim that there are no lag issues at all.

* Serious server-side issues. Granted, I have never seen their setup and have only second party info, but I have to believe that when sims all across the grid are functioning pretty well and then suddenly, out of nowhere, lag to 0.3 Time dilation and 0 FPS.... there is something deep core in the server/software system that is just plain broken. And I would have to believe that there are still some serious bottleneck issues in SL-- major ones-- that simply have not yet been identified.

Probably because people are too busy working on floppy prims. ;D

These are just some theorized issues, but I have a strong feeling that they are based on very real server/program-side issues. I keep waiting for a LL programmer some day to suddenly slap his forehead and say, "What were we thinking when we wrote THAT???" And suddenly... poof! Lag vanishes. Just like the old ghosting bug that constantly caused people to relog several times a day. LL said they had been looking for over a year and could not find the ghosting problem. It was harped on and harped on and then one day suddenly just disappeared... like a vapor in a mist. No explanation. No reason. Gone.

Yup, for sure, deep core needs to be re-examined and re-thought. And again, I think the bandwidth issue needs adressed.

Oh, Wayfinder, don't get me started on technical reasons why SL is sluggish --- well, not in this thread anyway.

Yes, you highlight completely valid problem areas, but suffice to say that all this has been analysed to death in thousands of posts, to no effect whatsoever. We've even done fairly scientific tests to eliminate factor after factor so that the reasons for slowness are narrowed down to a handful, to no effect. We've argued and analysed until we're blue in the face and come up with core insights that point to inherent problems on the client and server ends, to no effect.

It's even gone beyond this and "escalated" (clearly I've been too long in industry ...) to Philip himself, and as he's a rational guy who understands technical arguments, he followed the reasoning and agreed that the SL infrastructure is scalable only if everyone stays at home, but totally non-scalable for events and mobile objects, which is fundamental. Acknowledging this should immediately halt further work on a dead-end infrastructure if one is sensible, but again, it was all to zero effect. We are exactly where we were at the beginning, nowhere. Bad news is accepted when explained rationally and calmly, but it's still ignored. (Check his blog.)

Which is why I'm not even bothering with the technical details any more. There is no point, LL's ability to react is logjammed.

I'm sure that there would be the will to address all of these things if it were possible, but it just isn't possible within Philip's current team, and I'm sure that he knows it. I'm no diplomat nor manager, but even I know that you can't pull the rug out from under your people by telling them directly that they've been working on a flawed core design. But Philip *is* a diplomat (you have to be to become a successful CEO), so I *do* expect him to weave his magic and find ways and means of achieving things with people like I can achieve only with technology.

At the end of the day, the problems here are entirely organizational, and the near-zero take-up of even the very best Feature Suggestions points to those problems very eloquently. But offering more and more Feature Suggestions won't do it. We're only letting off steam here.

LL *can't* respond adequately as things stand, regardless of what is written here. Of course that includes not being able to respond to anything that this meta-thread might bring to light, but at least if we see an organizational solution, then perhaps we can go to Philip directly again, or approach others who know him.

It's a sad position to be in, but we're here because we love the concept of SL and can see a wonderful future for this general area. Unfortunately, LL can't get there from here, by design, both technical and organizational. And unless we help them do something about that, their future as well as our expectations will continue to be dashed against these same totally immobile rocks.

What if only certain parts were made open-source? Like LSL for example, whoever is the scripting guru atm would then do their own work, plus making tasks available as requests to the open-source community.
Same could be done to many aspects I think. So overall suggestion for that would essentially be:
Take all the heads of each 'department' (I suspect they aren't organised like that but you know what I mean), and have them look at where and how they could benefit from community involvement for that aspect, and have them each run appropriate schemes. For example, anything that is open-source coding, great, that can be handled by various software already, just make sure it's moderated enough to be manageable (e.g initially a user can only submit code to implement a particular intended feature).
Community involvement can extend to other things as well though, take land management and sim development, I suspect there are loads of people who wouldn't mind placing chunks of road here and there, as there are people who find it rewarding to help LL and SL as a whole.

I suppose in simplest terms it's: "Let the community do more things to help!", on the whole I doubt people care if LL are a company, this product is one people really get involved in, and wouldn't mind helping out with to make the experience better.

On the issue of slowness, I think part of that is down to how poor SL's caching system seems to be, as my bandwidth is fully utilised, but just flying between two commonly visited places in the same sim often results in me needing to re-download everything (or at least large chunks of stuff) for that place
That's IMO the next thing they should concentrate on for 1.11.x or whatever.

Can't really agree on this one. I've been in business too long and seen too many businesses turned around by a gutsy manager to say we "cant' get there from here".

Some of the things I mentioned are not only addressable, but could be addressed fairly easily (such as the bandwidth concept). The "illogical structure" issue could be fixed pretty fast (how long did it take them to install that 3-charcter search engine? How long would it take them to simply switch it back? One line of code?).

Other items are more extensive, but Philip wouldn't have to necessarily pull the rug out from under development to get these things fixed. They already completely restructured inventory once. In doing that, they accomplished one very good and one very bad thing: Good--they made inventory much more usable and user friendly. Bad--they made it lag like a fiend... lag that never existed in inventory access prior to that time (remember when all inventory access used to be instantaneous? I remember that. Ya couldn't find anything because there was no search feature, but it was greased lightning). Remember when sounds used to actually accompany the gestures they were intended to support rather than coming in 15 seconds later? Remember when textures used to load quickly rather than forcing someone to stand in front of a vendor for 10 minutes waiting for the texture to rez? These things once worked and now they don't. Those are things that need to be addressed.

As you accurately stated, the problem is organizational... basically failing to take the bull by the horns and make essential decisions. If the system is ever going to live up to its potential, these core items need fixed first. Of course, that takes a very pro-active management attitude, and is usually accomplished by one or two or three people shaking the kettle a little bit.

I remember reading the process Linden Lab uses to permaban a griefer. The process was extremely long and drawn out and complicated and time consuming and involved some 25+ individuals. My pro-active solution: a board of 3 judges reviewing the issues and either sending a severe warning or pressing the button. Problem solved.

That kind of "let's get this done" concept is something that LL might want to employ in more areas... and it needs to be applied to important things that will make the system run better and faster, not more in-game toys to add to lag and cause further problems (frankly, the whole "floppy prim" and "local lighting" focus just astounds me when there is so much else that needs attention).

Worked as a programmer/consultant for years. I see a few disadvantages with the entire concept of open source.

1. It tends to create chaos if there isn't a strong central agency in charge of accepting-rejected open source changes. (Look at all the different "versions" and implementations of Linux for an example).

2. It presents a problem with conceptual trade secrets. No one wants to work a farm and give away the hay.

Back to your initial concept though, I have to wonder something:

SL is currently supposedly somewhere between 170,000 - 200,000 members. It is barely operational. Whenever we get more than 5 avs on a sim, it starts lagging. 30 avs lag to a standstill.

They project 1 million users in a year. How is that supposed to happen? I mean, if a room is already full, inviting more guests isn't going to solve the problem.

If they are planning to expand their user base and membership, someone needs to realize NOW that hey need to pay heavy attention to user suggestions, heavy attention to foundation problems, and eliminate the lag issues now. Otherwise, they're just looking at a recipe for imminent disaster.

Well, one thing that would really help with lag is getting the Mono engine out for LSL.

It's completely insane that a simple script executing a few hundred lines per second can use up to a millisecond or two out of every 22.3...

That's about 8% of one of the CPUs. Considering the average CPUs they use, that's 200 million cycles per second, for a dinky little script.

Now explain to me how something adding a few integers 200-300 times a second can use 200 million cycles a second on a modern processor!

I saw screen shots of LSL running on the Mono CLI, months ago. And they drop this to give us floppy prims?

I fully agree with this right here, as I dont even use half of the graphics features that SL offers. I have a top of the line video card, 64 bit processor, 6Mbps cable internet connection, and when I activate the higher graphic features, it still slows down to 5Fps. Maybe if I using my computer at LL in california on their internal network, I would be able to use all the graphics features. What we need operability and useability, not bling.

Wayfinder, I don't want this thread hijacked with arguments for or against open source. That path offers a very easy solution and I have argued for it in the past, but I don't want to go there, here at least, because that's already been done. There are other possible ways for LL to make rapid progress, and I listed a whole pile of them. Let's examine alternatives of that kind, or others, at least on this thread.

At the risk of going off-topic though, I have to respond to your two points which I consider to be completely mistaken:

1. Linux is a multi-billion dollar industry, evidently "chaos" works just fine.

2. A very poor and flakey early operating system called Windows 3.1 once got copied and replicated and pirated and cloned and given away and generally distributed around the entire world with very few constraints, until it became "the norm". Judging from Microsoft's bank balance, I wouldn't say that they suffered unduly. LL has nothing to lose.

But I'm not proposing that in this thread. Anyway, they're already using open source, lots of it. Just try doing an ldd on the alpha Linux client, you can see for yourself the huge number of open source subsystems that they link in. That will increase eventually by their own admission, but LL needs a solution NOW.

I just hope that they do that right, by which I mean, use the unmodified Mono engine so that open-source development can continue to improve it in parallel with LL's own work.

Any code that LL grab and customize and try to maintain separately will be a millstone around their necks, a drain on their resources. It's the wrong way to do things, but sadly it's the "normal" way for companies and developers who don't have open source running in their veins.

We'll just have to wait and see. If they merely link in standard FOSS subsystems and let the community work for them, they'll go from strength to strength and never lack for manpower.

Hear hear!
I have every single "bling" optioned turned off on my desktop (my more powerful machine) and I still get 2-10 FPS all the time. We got up to 1.10.x and I'm not going to be able to do a damn thing, local lighting and floppy prims turned off (assuming I can).

Things need to be fixed!

OUCH! Right in the heart. That one had to hurt! LOL

And... for sure. Couldn't agree more.

However, someone pointed out (hey, I think it was me )... why would they want floppy prims? I mean, what real use is there that would cause them to place this as a priority over everything else? Flapping flags are nice, but they're not earthshaking. What could possibly need to be floppy and scriptable to become rigid...?

Ah... comes the dawn. ;D

Custom Trees~!
Because we all know, everyone wants floppy trees.
I think I saw tails mentioned once, but I don't know what it acomplishes...

Well, according to my reality, which is arguably different from most other's, there hasn't been a significant feature added in over a year and a half that works reliably (nor have there been many significant features added). Que sera...

Well, according to my reality, which is arguably different from most other's, there hasn't been a significant feature added in over a year and a half that works reliably (nor have there been many significant features added). Que sera...

Yes, visible development has simply .... stopped.

The only significant new release that I've witnessed in over a year is the alpha Linux client, but we are told that that work wasn't done by Linden Labs anyway but by a contractor. Furthermore no work has been done on that since release, despite a load of things not working --- all they're doing is updating its version so that it can continue to connect to the grid.

Which of course is the reason for the thread. Things can't work this way. It's not just Feature Suggestions that has become a joke, it's pretty much everything related to development.

Of course, what may be happening (because pigs sometimes do fly) is that 99% of effort has been redirected to version 2, the culture has changed from relative openness to complete secrecy, and they are hard at work on a new dynamic infrastructure that scales for events and for mobile objects. Nothing wrong with a bit of fantasy ...

Alternatively of course, they're dead in the water. That word "logjam" conveyed a suitable image.

Perhaps they can't improve the program because that is not their real goal.

Their goal is to have fun, like a bunch of nerds in high school building Tesla coils or sending up igniting hydrogen balloons.

Tacking the problems that need to be solve to make SL work well would not be fun.

What's fun is - get an idea, rough it out, make it work 50 percent, get your idea confirmed as to its basic correctness. Making it work the remaining 50 percent is tedium.
It's more fun to start on halfway implementing the next new idea that comes along. The users don't even see most of the half developed ideas, the users only see the ones that managed to get 80 percent finished in detail.

Expanding the workforce would make the place not be like a clubhouse for overgrown teenage geeks, so the workforce doesn't get expanded even though it might be possible to get the expansion funded. Same for every organizational change that would make it possible to greatly improve the software and database system, it's not gonna be fun, so its not gonna be done.

I hope this is just incorrect speculation, but this is the impression I get. as to one cause of the programs slow and twisted progress.

You're not the only one who has made such an observation. I don't mean to sound negative or state that LL never accomplishes anything worthwhile. They actually do. There are some features (Estate Management tools, the soon-upcoming group tools) that are really nice. But at the same time, there are bugs that have been there for an eternity and as you've pointed out, it sadly seems it's because everyone wants to play with new gizmos rather than tackling the core problems.

lol, this is a theory? huh, always took it for granted. Not that I blaim them.

Well if Sarendale, Wayfinder, and Rickard's interpretation is correct, and I grant you that it is consistent with the facts that we know and the symptoms that we observe, then it leads inevitably to the following conclusion:




I hope that your interpretation is wrong.

Business people inhabit a totally different world to my technical one, but I don't necessarily think bad of them until the evidence makes that plain.

Philip Linden rides very high in my estimation. Your interpretation would make him no better than some of the business lowlife out there.

Well, I won't comment on knowingly misrepresenting information, but I will comment on corporate mentality, especially when serious investors such as Ebay become involved in a company. Ebay is immensely successful and profitable, but it is well known that their business concept is anything but customer-friendly. It's basically one of throwing customers in the water and yelling "swim or sink!"

Philip is definitely a visionary. The success of Second Life is obvious. But as you said above, some observations are "consistent with the facts that we know and the symptoms that we observe". When I look at Second Life, I see a mentality very typical of the late 90's/ early 2000s dotcom companies. Plenty of venture captial and all the playground they could want. Absolute geniuses doing a lot of really fun things... driving their companies into the ground.

Typically, high-level programming geniuses make lousy business managers. They are often very successful because their product is so valuable people beat their doors down to buy it. But that doesn't mean they're good at business, or that they're customer friendly or even that their product is the best on the market (example: Micro$oft Windows, which is as resource-glutting, confusing, prone-to-problems and overpriced a program as I have seen). It just means no one else has what they have and as a result they sell a ton of it.

In the case of Second Life... the system is arguably the most addictive thing I've seen on the net. It's pretty impressive in many ways. And some of the basic designs of the system I have to give a nod of appreciation. People always focus on the bad things and never focus on the really kewl features (such as being able to earn a living at it or being able to write your own code within the world). SL is head and tails above everything else I see out there. You can tell someone had a lot of fun putting it together. Face it-- it's a creative-person's dream come true.

BUT... at the same time we see problems with the system that are just incredible to believe. SL has been in operation since 1999 and they're only now getting around to group communications? That ghosting bug lasted for (two? three?) years before they finally got rid of it (I'd have had programmers on that turkey and gone in two months, not two years). They turned an unwieldy but lightning-fast inventory system into a very user friendly but bug-ridden and slow inventory system-- and still haven't fixed the glitches (just how long does it take for 4ghz computers to search a text file anyway?). Object permissions are a bolluxed mess. Sounds that once worked fine now come in 15-30 seconds after the gestures they're supposed to accompany. Deep-core bugs that have been around for ages-- serious bugs-- are left unscathed while new "silly" toys are added to the system on a regular basis (really...videos, floppy prims, local lighting? Are these even close to top-priority needs?).

I mean, the toys and eye candy are nice and I'd applaud them to the gills-- if the major bugs were being taken care of. But the fact that they're not is evidence of the "prgrammers playing" mentality that is very, very common in the technical industry. Give a programmer a choice between streamlining the foundation to remove lag-- or program a new, fancy HUD system-- guess which one he'll choose every time?

I neither distrust Philip Linden... nor do I believe everything he says. I'm not a brown-noser. I tell it like I see it. I'm not opposed to exposing a few skeletons-- with the ultimate goal of helping iron out the wrinkles. Generally I am pro-Linden Lab and pro-SL, despite appearances to the contrary. LOL. I'm certainly not going to call Philip a liar and I personally have never caught him at a direct lie (can't say that about others though. ). I do think that as is the case with many visionaries, Philip's admirable vision sometimes goes beyond the edge of common-sense reality. Hazard of the trade and a mark of good visionaries. Quite often I hear LL claims that don't jive with the reality of the system. As I've told them-- some people out here are not total idiots. LOL. But Philip intentionally misrepresenting thing? Can't say as I've ever seen that. Maybe some visionary excess on a regular basis but again, comes with the territory of being a visionary.

One user once put it very well: Let the visionaries run the company and the visionaries will ruin the company. Grant them room to play, but let a customer-saavy businessman hold the reigns.

Mind you, I am not slamming LL or SL here. I'm saying that there are a lot of obvious, established, observable problems with SL that are going to go from being very annoying to very messy as the population grows. They're expecting possibly one million members over the next year... on a system that already lags so badly users often cannot move and even have to relog or TP to another area. No matter how fancy the car, if the brakes give out you're in trouble. 8O