STOP 'fixing' SL - please!

Have you tried sending support the log file they're asking for? That might help diagnose and fix the bugs...

To test a new version of the game, you have to download a new version of the game. How could it possibly be different?
How on earth is that different from the preview grid, other than the fact that AW is so much simpler than SL?

That was true in 1.6, 1.7, and 1.8. Make a copy of an attachment before detaching and your copy won't have any changes you made since the last time you attached it.
Teleporting is still MUCH faster and more reliable than it was in 1.6, 1.7, or 1.8. I haven't had to take off all my attachments to teleport since 1.9.

And most of the changes are the result of this fix.

Uh yes. yes i have. about 3 times already... And they never reply!

Yiffy, could you post a log file to the forums so we could take a look? It's hard to know whats going on otherwise :-/

Are you running a firewall, on a network with NAT translation, packet shaping, packet filtering, wireless network or satilite internet connection?
If there is another thread where you have answered these questions in part or whole, you can post that instead.

SL is very bandwidth-wasteful! There's no reason the entire 20MB client needs to be redownloaded every time a new version is released unless something has changed that actually affects the entire client and all of its files. There is a large ..SecondLife\app_settings\static_data.db2 file that could just be patched instead of redownloaded, for example (and, of course, secondlife.exe). All the character directory files aren't necessary (at least textures and LLM files--whatever they are) for minor changes (GUI, no less) to chatting. AW has used a patcher since at least 1997--and it's only 3MB total (aworld.exe: 780K vs. secondlife.exe: 11.6MB)!

Because it doesn't require logging into a separate preview/beta universe ("grid" in SL terms) to test them!

I agree, but it seems that Secondlife will have to go through changes before it runs at a decent speed. I guess we all just have to wait until that time comes. Sometimes the problems people are asking are because of their system configuration, sometimes its the client. Once again, I guess the only thing we can do is wait.

modifying the client to support patching would make it more complex and increase th number of bugs, and it would have no significant benefit.

The 20MB it downloads is nothing compared to the gigabytes of content that will flow down the wire as soon as you log in and move around. So who cares?
If you're not logging in to an upgraded server, how would you test server upgrades?

Bullshit. The significant benefit is a faster upgrade and one less thing to have to UNNECESSARILY wait a longer time for.

*I* do, obviously. SL's mindless cache redownloading is another issue of its wasteful bandwidth, too. The cache redownloads recently downloaded files WAY too often (and it's even worse since SL 1.9); it doesn't remember textures, object info (name, description, etc), etc very well. Textures are almost always mindlessly redownloaded every SL session, even with a max cache size of 1GB. SL constantly asks the server for info on EVERY tooltip when it should remember the last known retrieval and simply update it if it changes (like AW does)--leaving the current version as is with no "Retrieving..." text in the fields.

Stop making excuses for SL's poor design.

Obviously, you don't know how AW works (despite having already explained it to you). Reread my previous replies.

In AW can a script update the description field of an object?
How is the client to know if it has the most up to date version, if it doesn't request it?
Considering that description fields are limited to 127 bytes wouldn't be just as easy to send the most up to date version of the description as it would be to send a version number?
A push system where all description updates were sent to every user in the sim could result in update lag, and could be used as a griefing tool.

I find it curious that you bring up AW so often. I'm sure LL is well aware as to AW features and capabilities; it would be stupid for them not to know thier competition. I'm sure there is a plausible reason why SL isn't AW.

There is no "description" action command in AW (and I'm not sure if the SDK can update object descriptions, but it probably can). I just have a problem with how SL briefly flashes "Retrieving..." for the description and owner fields when it should just show what it last cached (and actually REMEMBERING its cache across even the current session!) and only update the fields if there is a change. And, no, a "version number" would be far less bytes than 127! Obviously, not ALL users would need to get ALL description updates simultaneously.

I have to question if LL does INDEED know about AW in any great detail since it seems to lack some of its most BASIC features like patch updating, decentralized servers, etc.

Plus, I have far more experience in AW than SL so it's the closest thing I have to compare with SL.

It's going to take about as long to transfer a packet of 30 bytes or 150 bytes, it's pretty silly. Keeping version numbers would require more complexity, but your right it could keep a small cache for hover tips and show the cached version while it downloads the new version.



I'll agree, patching would be an improvement, we have discussed this before I think. LL's buissness modal requires centralized servers. What makes SL successful is that assets and space are limited, people are forced to interact, just like the real world. But they are also able to do what they like in SL (with in some limits). People running thier own sims or grids doesn't lead to a cohesive world. You need infrastructure that has to be constant, sims have to be there (they cannot be offline because someone desides to take them offline or thier internet goes out etc). Though at this point SL is pretty diluted.



You may find that people are more friendly to your suggestions if you describe them without mentioning AW.

No, a "central" (more like distributed like peer-to-peer networks work) server could manage intersim communication. But, really, there's no reason why sims can't just do it on their own. Yes, a cohesive world is nice, but is not a requirement. Sim runners could choose to "connect" their sims to others, if they like, or run them separately as "islands". Dummy sims could be run by anyone to put more space between others, too--a distributed computed virtual world.

Um, why? Do most SLers not like AW or something? AW is SL's dad, pretty much...and There it's mom. heh

But, really, if people here are THAT insecure about AW, I don't want to have a discussion with them anyway.

It's a minor benefit. If it bothers you, download the client directly from the website... it's a lot faster.

Yes, the cache is broken, and that's a real problem. Speaking of real problems, you're still missing a point that I've alluded to in other threads... so let me make it again, explicitly:I'm not. I'm quite critical of SL when SL's got real problems that really need to be addressed. A couple of minutes once a week isn't one of them.

Um...no. There is no speed difference.

And YOU are missing the point, Argent. It's about efficiency--and SL ain't efficient. Problems are problems. SL's wasteful bandwidth is just one of MANY REAL problems it has.

My problem with the constant changes is that they seem to be tinkering. Messing with stuff that they don't understand because it isn't labelled DO NOT TOUCH in neon letters.

I'm not saying that they can't understand it. Heck maybe they even wrote it, but they're getting messy and they aren't taking messes that they've made seriously. No real progress can be made in such a situation -- it's time to CLEAN UP.

There are no superhumans yet it's easy to understand that adding a feature to a program as complicated as SL is --- if it worked perfectly and made complete sense --- would be a feat for the human brain. It's also easy to understand that if people are allowed to choose projects as they want, that NOBODY will choose to BE HOUSEKEEPER.

I'd put half the devs on debugging... I'd choose the ones who most hate it, since they're likely 9/10 of the problems.
Or this rapid fire barrage of glitzy buggy software will be the doom of Secondlife... perhaps that's the point. I've seen too many businesses ripped apart by investment corporations and a disinterest in communication.

Hmm, since when have guests been allowed to post here (or even SEE the forums)? Weird. Anyway, good points. The problem I have is that these inter-major-point releases (between versions 1.8 and 1.9, for example) don't seem to be tested outside of LL and are just mindlessly released to the public. Where's the preview/beta hooplah that surrounds major point releases, with minor releases? It's not like SL doesn't NEED testing at times; it needs CONSTANT testing! LL just doesn't seem to be able to keep up on its testing on ANY version.

Changes, to LSL espicially, have to be carefully tested, due to the impact such changes may have on the world's economy. We should be notified (in the announcements forum, or in a sticky in the Script Discussion forum) of any pending changes to the LSL API. LL is able to do something easily that other programming language maintainers cannot: their system gives them the capability to know exactly how many scripts are using any part of the API, yet they seem to ignore these numbers (if they even gather them) when they change anything.

It's counterintuitive really. It makes it seem LL really wants to break scripts, so scripters have to stay on their toes to keep things working. No scripter can be a casual user of SL and run a successful buisness. Things like this have happened in the past - LL broke a great many scripts when they randomly decided to change the way the script VM removed listen handles. Any script that changed states with an open listen had to be rewritten and redistributed. Nothing prompted this, open listens weren't crashing sims, or misbehaving in any way; the change wouldn't even decrease lag (in the long term, after scripters fixed their nonfunctional scripts).

The changes made to the XOR function struck a similar note. Luckily, *this* time, they reverted the new behavior, and wisely implemented a corrected alternative. This just goes to show that they still haven't got the depricate & add procedure totally correct yet.
==Chris

Perhaps your Internet connection is either much better or much worse than mine. When I download in Firefox I get the download in less than half the time of the Linden downloader.
No, it's not. But making rare operations faster is not a good way to spend developer time, especially of what you're doing is going to make those same rare operations less reliable.

Algorithmically, there's no difference between a cache and a partial download of an updated client. Given how poorly they're handling caching do you really want to depend on their ability to implement a caching algorithm just to get a clean client download?
Some problems are more important than others. Creating a partial download for a once a week (and often optional) operation will have much less impact than (for example) using a TCP instead of a UDP connection to download textures.

Perhaps my connection is just more consistent.

Again, you're missing the point. The point is to get LL thinking efficiency, not wastefulness. Client update patches are just ONE part of this move towards efficiency. Other parts are cache remembering (what a concept), GUI menu design (less wordy, icons vs. text, etc), etc.

Using a better procotol would help in fixing part of the cache problem, but SL just has a problem with REMEMBERING its cache over sessions. There's no reason it shouldn't be simply showing/playing the cached versions and only updating them if they have changed, vs. not showing/playing anything at all and, for example, keeping the mouse click events in queue and then mindlessly playing them all at once after the click GUI sound finally redownloads. How stupid is that?

SL has a problem remembering the cache *within* sessions.

Agreed 100% - an irritation like downloading the whole viewer everytime is an irritation. The 1.7 update that caused me to crash every 20 minutes that was a problem. Granted fixing the updater once *should* solve it permanently, but even though it winds Eep up, it is only a niggle, there are a lot of things that need repairing first IMO.

i don't need to. the lindens contacted me. They found the problem. IT WASNT MY SIDE THIS TIME YAY!! The user server had to be rebooted. SOme accounts wer glitched. The day of the last update, they rebooted the user servers.

I had a quiet chuckle on seeing this "STOP 'fixing' SL" thread.

Those who expect any kind of stasis in SL don't seem to realize where Philip is coming from nor heading, and the business requirements thereof --- *HIS* business requirements, not yours. Perhaps this little thread on Philip's blog on Jumping the Shark might make things a little clearer.

For those who don't seem able to hold their attention on an article that long (but very well written), here is my short summary presented as it is and without any diplomatic beating around the bush:

And to summarize the above even further: If you expect SL to remain as it is and stable, you are totally screwed. SL *has* to forge ahead rapidly, or all will be lost.