(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.
I can certainly appreciate that, it just seems like there's no direction. This whole 1.11 release was apparently geared towards a more usable interface, and instead we got one that's dramatically less. If those programmers need something easy to do on a friday afternoon, I have some suggestions:
1) Fix windows minimizing on top of each other. Honestly, this seems like a programmer could smash the keyboard with their head and have it fixed. Sorting through 3 or 4 or more windows that are all stacked on top of each other is ridiculous and has been a problem for years.
2) Make the client remember our settings. When I open the camera controls, why doesn't it stick? There's several tiny little things like this in SL, including sun override.
Honestly, trivial changes that have been ongoing problems or annoyances are all over the interface and have been there for years. Sure, prioritizing the entire BLOTTD is probably daunting, but why can't you do something simple like start categorizing it. 'Big projects', 'Petty Shit To Do On Fridays' and 'Stuff For Us To Ignore For The Next 3 Years' seems like a start. Instead we get camera flares, woo. (waves a little flag)
I appreciate the revolutionary new work model you all seem to enjoy so much at LL, i.e. "everyone works on whatever shit they feel like," but can't your development leaders actually provide some leadership for a change? Some shit is just boring to fix/implement, and it's never going to change, but that doesn't make it any less important. At this rate it seems that anything not interesting or revolutionary or glitzy just gets ignored indefinitely because no-one wants to touch it. Great model, really. There's nothing like telling prospective users 'Oh, that? Yeah, it's annoying, been like that for years and LL doesn't seem interested in fixing it.
'(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).
You completely ignored my point. Your imposed artifificial limitations DO NOTHING. You want to talk about griefers? Let's talk about griefers, yeah. Every seen one of these orbiters that has FIVE HUNDRED push scripts in it because 1 or 100 just isn't enough? I have friends who've been orbited to THREE HUNDRED MILLION METERS INSTANTLY. Your delays sure did a lot to stop them.
All your delays do is make scripting more inconvenient than it already is. Programmers, good and bad, are just going to work around them like they always have. If they can do it with 1 script, great, they will. If 2 scripts or 100 scripts works better, that's what they're gonna use. Instead of 'balancing the resources and limiting the griefing capabilities' you're just forcing everyone to use MORE resources to accomplish the job anyway. Please explain how that is a superior solution.
(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.
Okay, I think the obvious first question is: Why is this a 'hidden feature' of the gray goo fence? Why are developers not informed of these little hidden nuggets of information when they're implemented? If you want us to take SecondLife seriously as a 'platform' then I think you're going to have to lead the way, and that includes not going 'Well, I'll impose some hidden restrictions and hope nobody notices!' Most of the residents of SecondLife are reasonable people, we can appreciate the need for the gray-goo-fence, just tell us what it does! Don't leave us scratching our heads and going 'Hmm, why is this failing with no errors and no warnings and seemingly random and arbitrary results?'
Second question is: Can you actually tell me what the throttle point for it is, so we know what we have to work with as far as message rates go?
In the meantime, I'll work around it. Something that I had been thinking about as a result of this was the overall ineptitude of the MessageLinked function to begin with. Was it implemented before LSL supported lists and vectors and rotations, or is it actually more economical on the system for us to convert all of these back and forth between strings (which is a crazy intensive process for lists to preserve each element's actual data type in the list), or is it that LL simply never imagined a need to transmit such information across link messages? Is there the possibility of MessageLinked getting upgraded eventually with something like...
llMessageLinked(integer link, integer num, string message, key id, list stuff, vector junk, rotation somethingelse);
...with the list, vector and rotation arguments being optional to maintain backwards compatibility? Or perhaps just a new MessageLinked function that leaves the old one the way it is?
