User interfaces, priorities and link messages, oh my!

1) Did LL sit down when they originally designed SL and decide to collectively fuck the last ten years of UI development?

In all seriousness though. I was sitting here tonight changing the permissions on a soon-to-be-for-sale object composed of 29 prims and containing a good 60ish scripts, and another 20+ animations when a variety of things were getting angry with each other in my head.

A) Why can we use sounds and textures inside scripts via their asset key BUT NOT ANIMATIONS? Cause people can use animations they don't have via key? Why is that so much worse for animations and not sounds and textures?

B) When editing the properties of an object in inventory or, more importantly, in an object's contents, why is everything immediate? Why do I have to click on one checkbox, wait while it updates the object, click on another checkbox, wait again while it updates. Why not let us jack all the checkboxes up and hit OK and apply it all at once? Isn't this unnecessary bandwidth and processing time being used by the system?

C) Why do I have to set every single script and animation on an object to the right permissions? What's wrong with a 'Apply this setting to all contents' box? Seriously?

D) Why are tear-off menus that no-one gives a crap about (seriously, UNIX has had this for forever and this is useful in some programs, because it actually tears the menu off. SL just turns it into another view obstruction. Why not do something actually useful, like, I dunno, let us drag 'windows' inside SL to outside of SL like they're actually seperate windows?), very annoying glitzy snapshot effects and pie menu animations that apparently 1 in 10 people like, all more important than basic interface usability?

E) Has LL ever considered taking a lesson from every file manager in existence and turning our inventories into split folder tree/file views?

F) Why the hell do windows still minimize on top of each other? I've been here for well over a year now and this been like this at least since I joined.

2) Can someone explain LLs priorities? Tear off menus? Scalable UIs? Great... what happened to stuff that actually matters, like faster bytecode compilers so all of SecondLife runs faster? I know you've said before you have people working in on 'teams', but if someone is twiddling their thumbs why do you give them crap like this to do instead of letting them help on another project that's more important?

On the note of faster bytecode compilers, why does LL force us into fucking the script schedulers in the ass by imposing artificial limitations on what our scripts can do? For example, all these delays builtin to various functions (most of them, really). What's the point? Now instead of doing something quickly with one script, I have to make 2 scripts or 20 scripts that run synchronously. Yeah, that's such a major improvement. Now we're eating up twice the memory, and forcing the scheduler to pay attention to more scripts, plus triggering more events inside the object constantly for synchronous action.

The delays are a quaint idea, they really are, but haven't you learned yet that programmers are going to get around them anyway, and in the end it's only worse?

3) Can one of the dev Lindens there weigh in on this (preferably on the above also):



Do scripts have a hard limit on events in their queue before they start overflowing stuff?

Thanks Karsten, your suggestions got forwarded around internally. Some of your points like C) and E) are on the Big List of Things to Do. F) annoys me badly. Which brings us to A) because we sure are looking for a UI expert:

http://lindenlab.com/employment/ui_expert

Also, with the XUI changes, they're part of a bigger umbrella. Tear-off menus is the start of what will eventually become, hopefully, a powerful way you have your own custom menus and palettes to have the interface the way YOU want it. It isn't clear yet but it's better to make a move on such a thing instead of not moving at all. Pieces of a bigger puzzle.

Scalable UI matters a lot to some people very hard of sight. I heard some good stories from the visually-impaired.

I'll check with a dev about your question!

(1) Begging your pardon, but I'll skip this multi-part question in the hopes that someone else with more time then I do can carefully examine each item and reply in great detail. Instead I will address your general dissatisfaction with the SL user interface and mention that a group in LL has been organized to try to overhaul the UI, in parts as well as in fundamental ways at the core. The plan is to get to a point where the UI is much more featureful, but also flexible and customizable so that people with strong opinions about how things should work can force their preferences.

(2.a) I've mentioned the answer to the first part of the question a few times, but here it is again. The order that things get done is not necessarily the same as their importance for a variety of reasons. First of all, prioritizing everything that needs to get done is fraught with difficulty, and there will always be disagreement in a crowd of smart reasonable people as to the order things should get done. Second, even if we had perfect prioritization, we have a limited number of developers to throw at the problems at hand. If we had an unlimited supply of robot developers working 24/7 then we could just identify the issues by importance and start assigning people to tasks until all of the important ones were in progress. The developers would then work non-stop until each project was finished. Since that is not the case what happens is that the projects phase with developers daily schedules, vacation, release schedules, and human preferences.

Sometimes a developer will finish a big complicated project on Thursday. Rather that start crunching on another challenging multi-day project on Friday the developer might choose to work on a smaller, more interesting, but less important project that can be done in a day or less. Sometimes a developer is excited about a particular project that is big, but not very important. That developer might chose to work on that project on the side as a refreshing endeavor at the end of a hectic day, eventually getting it done over a period of weeks or months.I think some of the features you singled out above fall into these scenarios.

There are a few other scenarios which can scramble the order by which things get done, but I won't itemize them all here; you an probably figure out what they are. Rather I will merely point out that we do not live in an ideal world.

(2.b) As to faster bytecode... The current delays in the scripting engine are to help balance the script resources for all the scripts, as well as to limit the greifing capabilities of some features. Granted, the system is not optimially balanced, however that is a big project and one might argue that rather than tweaking the numbers of the current system, it might be more worthwhile to work on switching to a different bytecode system. See item (2.a).

(3) This is a hidden feature of thegray-goo-fence; the links are failing, not the link_message() events. It turns out that links are rather expensive on the system, and I'm not inclined to release scripted links from the fence until I am able to run another pass on the grey-goo detection system and refine its intelligence. Unfortunately, I'm working on something that is a bit more important, see item (2.a); you're going to have to work within the current restrictive envelope until I can get around to the grey goo fence again.

Sorry Karsten, I misunderstood. I was thinking of llBreakLink() and llBreakAllLink() operations, which are counted by the grey goo fence, and were not announced. The reason they were not announced is because they were added later as an afterthought when someone realized that a grey goo attack could be exacerbated by unlinking multi-prim goo. Due to how the grey goo fence works, the events had to be included in the grey goo fence in order for them to fail when the fence is in force. I did not think anyone who was NOT making grey goo would actually hit the rate limit of 240 events in 6 seconds by calling only llBreakLink().

As to the llMessageLilink()... it is NOT blocked by the grey goo fence. Rather, it has a buffer of limited size. Much like network packet routers, and other first-in-first-out (FIFO) dispatchers the pileup of incoming messages must be limited, or the system can drag to a halt thereby making the pileup worse. Hence, if the buffer is full, incoming messages get dropped.

I'm not sure what the buffer limit is, but I would expect it to be 64, 128, or 256. Nevertheless, the _effective_ rate of the messages that can be sent without having any of them dropped will vary, depending on how fast they can be processed. The general load on the simulator from other scripts or lots of objects, textures, or residents will affect how many CPU cycles the script engine gets to try to empty its message buffers among other things.