llSitOnLink() - A Tale of Linden Mediocrity and Incompetence

[Haravikk Mistral]

I'm not sure how many of you aware of it, but there is a new function in RC right now llSitOnLink(), and while it might sound nice to finally have a scripted sit feature, it is unfortunately a very sad tale of just how much contempt the Lindens view us with, as the reality is that this feature is deeply flawed, yet the Lindens are refusing to do anything about it while there is still time.

 

Problems With the Feature

To give you some idea of why this annoys me so much, I suggested the very same feature almost a decade ago (in fact probably longer, as I originally proposed it on the pre-JIRA issue tracker), which you can view under SCR-3.

You may note right away that the design of the actual function is different; instead of taking an agent key and a link number, it takes two keys. This is important because it not only means the function can do everything llSitOnLink() can (using llGetLinkKey()), but it can do so without scripts having to actually reside in the target object; it could for example (and crucially) be used from a HUD or other attachment, or could teleport you from one object another.

The other problem however is the fact that the Lindens are refusing to the use permissions system to implement this feature; they are essentially trying to use the experience system as a lazy shortcut. While the experience system has its advantages, it simply isn't suited as a replacement to a permission in this case for a huge number of reasons (I'll limit myself to four):

 

• No Auto-Grant: It is not possible for the experience system to automatically grant permission on sit (or attach for llSit), and this is a huge oversight, as it means that the most basic use-case of llSitOnLink(), moving an avatar between sit-targets, cannot be achieved without the additional boilerplate of the experience system. The only way this could be achieved would be with a workaround, at which point… why not use a permission which can do this?
• Experiences Can Be Blocked: In permission based objects, the experience system is a convenient way to grant the permissions persistently, however, if the experience is blocked, the permission can still be granted and the device can continue to work normally. This is not possible for a feature limited solely to the experience system; this means that switching seats on a vehicle can (will) simply stop working, and in a very unintuitive way for end users, so if this feature can't even handle that simple use case, what is it actually good for?
• Premium Members Only: Only premium members can create content using this feature, but why? It's a very basic feature so why shouldn't a regular member be able to create a vehicle with seat-switching? The whole reason I liked Second Life was the openness of content creation; while there are some cases where experiences are the right place for a feature, this is not one of them, not even close, and I am deeply concerned that it is the start of a trend of restricting new features to premium members only.
• Permissions Do It All: Not only are permissions finer grained, more compatible and easier (and free) to implement effectively, they also provide all the protection that this feature needs. Sat on something that maliciously used the auto-grant on sit behaviour? Stand up! Attached something that is forcing you to sit? Detach it! The experience system offers nothing that permissions alone can't do, except for persistence, but then the experience system can just as easily do that by granting the permission, there is no reason for this ludicrous and entirely arbitrary restriction. Implementing a permission for this would be as simple as copy/pasting PERMISSION_TRIGGER_ANIMATION; it has the exact same auto-grant behaviour, making this a few minutes of work at most.

 

Response by the Lindens

I have been trying for weeks now to raise all of these concerns (and more) with the Lindens, and their response? Many don't seem to even understand the issue in the first place, while others seem bewildered by the idea that they are being questioned at all. Most have ignored me, my JIRA issues attempting to raise specific issues and propose solutions have been closed without comment (or comments proving a Linden didn't even read it) and when I asked that someone actually talk to me about it? Banned from the JIRA!

User group meetings have been little better, as it is almost impossible to get an issue properly discussed when many people have issues to raise and the subject changes too quickly, while the Lindens largely result to the bad parenting 101 default response of "because I said so".

After all that time however I finally got Oz Linden to actually consent to speaking to me via e-mail, but this again has been an entirely pointless endeavour. Despite raising all of the issues with the feature clearly, Oz has yet to address a single one of them; all I've gotten is vague hand waving "woe is me" crap about limitations, without not a single scrap of detail to any of it; I even responded refuting every possible objection and Oz didn't address any of that either. I even tried to compromise; if the experience system is non-negotiable, then at the very least llSit() with two keys would still be infinitely more flexible, as we could put it in a HUD and implement permissions ourselves. But no, nothing. I don't know what the point of his contacting me really was, as right now it feels like just another insulting display of contempt, giving me false hope and then yanking it away, as I received no sign that at any point he was considering changes; I didn't even receive so much as an apology for my treatment up until that point!

Getting the two key variation of the function would take perhaps two minutes of work for a Linden with access to the simulator source code (hell, if they gave me access I could probably have it done in a day or two with no prior familiarity with the code), but it's the same old line I've been hearing for 11 years as a paying customer; "we're too busy", like they're the real victims here despite being paid money to deliver sub-par work that any self-respecting developer should be ashamed with (I personally would commit sepuku or ask to be taken outside and shot).

They certainly weren't too busy to squeeze out a function that is vastly inferior to what I proposed 10 years ago, and upon release will continue to be overshadowed by RLVa, a free, open-source feature added by a third party viewer developer, which has been delivering precisely the two-key format with fine-grained permissions that I've wanted for a decade. For years now I have had to rely on a third-party viewer feature; anyone in a similar situation will know what it's like trying to tell customers they need to install a third party viewer, and enabled a feature called "Restrained Love" just to gain access to a basic feature.

 

What can be done?

What can be done about it is a question I'm not sure I know the answer to; for now I am just hoping to document this sorry saga of my attempt to get a single half-assed feature fixed before it is inflicted upon the main grid.

But if people are interested by it, please make yourself known here; better yet, please attend the next Server/Sim/Scripting User Group meeting.

Perhaps if there are enough of us there to voice our disatisfaction we might be able to convince the Lindens that half a feature is not good enough; I for one am tired after 11 years of broken promises, half-implemented and/or poorly designed features delivered at a glacial pace, and Lindens with entirely undeserverd superiority complexes telling us we are wrong to be unhappy with their amateur-hour mediocrity. Sorry, I take that back as it's unfair; amateurs at least try their best and learn from mistakes.

What I do know is that I have spend thousands of USD in Second Life, and I have been treated with what can only be described as institutionalised contempt just for trying to see a basic feature implemented to a reasonable standard, and I am sick of it.

 

I've created a petition for those that wish to add their names:

Implement llSit() as Originally Proposed in SCR-3 Ten Years Ago

[shaniqua Sahara]

from what i understand Ebbe doesn't want to hear from anyone that isn't officially connected to his ear.

I think I remember something to the effect of telling users he doesn't want feedback, to stop telling them things you think they should do. it might even be in the TOS in some form.

 

after sansar tanks Ebbe will go back to flipping burgers and you can buy SL in bankruptcy court and implement your features then.

i wonder how much time and money has been spent on sansar.

 

[Haravikk Mistral]

You're probably right; I've been sick of the way SL is run for some time now too. I mean, it's ridiculous that they're still charging $195/month for a mainland simulator (or 50% extra for private); for that kind of money I can buy 10-20 cloud compute instances, each just as powerful as the hardware LL allocate per sim, and run an entire mini-grid of open simulators, so what are we even paying for anymore except the sallaries of people who hate us?

10 years ago that might have been close to what a dedicated server or good VPS would cost, but it seems the ridiculous cost is nothing more than an attempt to delay the inevitable. No-one I know has land anymore, nor wants it, as hoovering up half a region for L$10,000 isn't worth it if you have to pay through the nose to keep it.

The increased prim allowance is likewise a bad joke; it's the kind of increase we should have had 5 or 10 years ago, now it just feels like a slap in the face, or sprinkles on a turd salad.

[Qie Niangao]

 

Perhaps more effective to back-out references to this:

---

the most basic use-case of llSitOnLink(), moving an avatar between sit-targets, cannot be achieved without the additional boilerplate of the experience system.

---

A variant of that use case appears a couple places here (including "switching seats on a vehicle"), but it's quite tangential to the function's real utility. With PRIM_SIT_TARGET (now, or since 2011, llLinkSitTarget) and llAvatarOnLinkSitTarget, it's (relatively) trivial for a non-Experience-based script to move seated avatars around among those target locations, regardless of which sit-targets they happen to occupy. ("Relatively" because it would still be necessary to back-out the ancient sit target offset mess, if sit targets are really how the script is retaining avatar target locations -- which is almost never the case anyway.)

The essential use-case is "teleport you from one object to another" which you (rightly) point out is restricted to communicating objects that are scripted with this new llSitOnLink function. That restriction certainly incurs a cost against the "efficient scripts" ledger. Presumably it's intended to be sure permissions are associated with products intuitively for the end-user: the thing on which they end up seated is the thing that had permissions. I absolutely understand the benefit of doing it the other way (e.g., the HUD that can pilot you around unscripted sit targets), but I can't be sure I've thought through all possible security implications. (Yeah, detaching that HUD defeats any threat, but the system would need to somehow make it evident that the HUD caused the seating, and... yuck.)

I suspect "Premium Members Only" is perceived as a feature, not a bug. I wouldn't raise it, myself, if I hoped to get results from Lindens (as opposed to merely rousing the rabble, I guess).

In general, though, the Permissions argument is valid. In fact it's a bit problematic that this functionality is automatically permitted for Experiences that users accepted prior to the function's introduction. Now, practically speaking, nobody would want the users to have to re-grant Experience permissions for everything just because some Experiences might start using this new function. But in theory, they should have to query to add any such new permission. At heart this is a usability problem with the Experience system overall: while having all the associated permissions lumped together is handy for user and scripter, it leads to that scary long list of permissions requested to adopt any Experience, even if it will only use one of them.

One other note: Even though all the baggage that comes with Experiences may not be necessary or even valuable for this functionality, I can pretty much guarantee that the functionality would never have even been considered at all if we hadn't fussed about how much we needed this in order to make Experiences useful. 

[Haravikk Mistral]

---

Qie Niangao wrote:

A variant of that use case appears a couple places here (including "switching seats on a vehicle"), but it's quite tangential to the function's real utility. With 

PRIM_SIT_TARGET

 (now, or since 2011,

llLinkSitTarget

) and

llAvatarOnLinkSitTarget

, it's (relatively) trivial for a non-Experience-based script to move seated avatars around among those target

locations, 

regardless of which sit-targets they happen to occupy. ("Relatively" because it would still be necessary to back-out the ancient sit target offset mess, if sit targets are really how the script is retaining avatar target locations -- which is almost never the case anyway.)

 

---

The point isn't that it can't be done by other means, but that it isn't possible to do cleanly with llSitOnLink() which should be the obvious choice; I've used llSetLinkPrimitiveParams() to do this for years, I'm not looking for ways to do it, I'm looking for a feature that's actually fit for purpose after a decade of needing this feature (llSit(), not llSitOnLink()).

---

Qie Niangao wrote:

Presumably it's intended to be sure permissions are associated with products

intuitively

for the end-user: the thing on which they end up seated is the thing that had permissions.

---

If that's the case then in four or more weeks a single Linden hasn't once said it; Oz Linden has implied there are technical reasons why permissions are difficult to implement, but utterly failed to give a single one. I have pointed out that, though the permissions bitfield is finite, there are still around 17 slots available for new permissions, and like I say in terms of functionality the requested behaviour is identical to PERMISSION_TRIGGER_ANIMATION, so implementing it that way cannot possible be difficult, so once again this is a Linden using the "you don't know what we know" line as a cheap foil, when chances are I know a lot more about software development than all of them combined.

If the issue is on granting the permissions in an intuitive way then it isn't relevant; under the llSitOnLink() proposal it will already be possible for scripted objects to haul you around faster thatn you can possibly track down the device at fault, but in fact standing up will not be sufficient to stop it. Instead you must delve into the experience system window (which you may not fully know about) and block the correct experience.

The proposed permission implementation is actually better in terms of safety as it would only auto-grant on objects you are sat upon (easily revoked, and easy to know the culprit, since it's something you chose to sit on), likewise with auto-grant on attach, again easily solved, as how many potentially malicious objects is an avatar actually going to attach? Besides which, when attaching a trustworthy HUD, it can implement far richer and more detailed "permissions" than LL can; just take a look at even simple RLVa relays, which tell you what has requested permissions and (depending upon the mode its in) can allow you to individually revoke them. Otherwise the permission is per-object and only so long as you are in the region, so teleporting away is always a solution in the worst case scenario; if a problem persists, it's definitely an attachment.

Besides which, with a permission it is possible for the viewer to block permission requests or identify them; this is not possible at all with the experience system. You could for example have an option to block sit permission requests from some or all sources, which some viewers have for animations.

---

Qie Niangao wrote:

One other note: Even though all the baggage that comes with Experiences may not be necessary or even valuable for this functionality, I can pretty much guarantee that

the functionality would never have even been considered at all

if we hadn't fussed about how much we needed this in order to make Experiences useful. 

---

This is probably likely, but the thing is experiences are useful; I like the feature for what it is good at, I like persistent permissions, and persistent key/value storage etc. It already does what it is good at, shoe-horning features into it for no reason is not valuable.

However, my objection to llSit() being usurped for that purpose does not extend to the other feature enabling objects to prevent unsit; this absolutely should be experience limited, as handling that with a permission would be difficult. But there is simply no reason for llSit() to be butchered into a useless function to window dress the experience system with something it doesn't need.

---

Qie Niangao wrote:

 

I wouldn't raise it, myself, if I hoped to get results from Lindens (as opposed to merely rousing the rabble, I guess).

---

"merely rousing the rabble" seems to be the only option left; I've tried the JIRA, I've tried user groups, I've tried talking directly to a Linden (reminder: it took four weeks to get something approaching an actual conversation from someone who ultimately can't even be bothered pretending to care), and I've been treated like **bleep** the entire time.

[Innula Zenovka]

You are, I think, mistaken when you say, "Premium Members Only: Only premium members can create content using this feature, but why?"

Only premium members can own experiences, but once an experience has been created, the owner can set it to a group, and the group owner can assign the abiltiy "Experience Contributor" (as I think it's called) to particular group roles.   Then anyone with that group role can create content for that experience, whether or not they are premium members.

[Haravikk Mistral]

---

Innula Zenovka wrote:

You are, I think, mistaken when you say, "

Premium Members Only

: Only premium members can create content using this feature, but why?"

Only premium members can

own

experiences, but once an experience has been created, the owner can set it to a group, and the group owner can assign the abiltiy "Experience Contributor" (as I think it's called) to particular group roles.   Then anyone with that group role can create content for that experience, whether or not they are premium members.

---

That doesn't really help though; that's even more complexity for what should be a simple feature. It also doesn't change the fact that you still need to be in a group with which an experience is shared in that way, that's still a lot more than just being able to type the letters "llSit()" into a script and being half way to finished.

[Innula Zenovka]

Sure.  I wasn't commenting on whether or not this function shoud be part of the experiences system.   I was simply trying to make a factual correction, since a lot of people (not you) do seem confused about who can and who can't compile scripts set to an experience.

[Haravikk Mistral]

So the latest update to this entire debacle; I noticed today that my wiki editing privileges have been revoked. So naturally I filed a support ticket asking why only to be told I've had them revoked for some kind of infraction.

After asking to be told what that would be I have now had my in-world Second Life account banned as well (like I can edit the Wiki with that?)

 

It is clear that I am being targeted for harassment by Lindens, which is apparently their response to any and all criticism. I don't expect I'll be able to post to the forums for much longer.

[Qie Niangao]

---

Haravikk Mistral wrote:

my wiki editing privileges have been revoked.

---

This may not apply here, but just in case: the wiki has been closed to resident edits for months, with only special exemptions. Maybe this is something different -- perhaps you were among the annointed few who could edit -- but otherwise not being able to edit the wiki is just how it's been, ever since some spamming a while back. (I know there was also promise of some new fix to defeat the spam and restore normal wiki function, but I never heard it was complete.)

[Haravikk Mistral]

---

Qie Niangao wrote:

---

Haravikk Mistral wrote:

my wiki editing privileges have been revoked.

---

This may not apply here, but just in case: the wiki has been closed to resident edits for months, with only special exemptions. Maybe this is something different -- perhaps you were among the annointed few who could edit -- but otherwise not being able to edit the wiki is just how it's been, ever since some spamming a while back. (I know there was also promise of some new fix to defeat the spam and restore normal wiki function, but I never heard it was complete.)

---

If only that were the case; I had already requested to get the privilege back. Whichever Linden has been harassing me revoked it again, falsely claiming that I in some way "misused" editing permissions (despite only making something like half a dozen edits in the past two months and only to my own pages); I tried to point this out to support staff, and instead of doing something about it they suspended my in-world account for "consistent misuse" of the wiki, which is simply impossible; and even if it were it is an irrational response for something that at most might justify a warning!

The Linden support staff are entirely unwilling to even consider that one of their own might be abusing their powers to treat me this way; it's like the whole thing is us against them, that being paying customers, content creators and residents vs. despotic Lindens on power trips.

[Whirly Fizzle]

Haravikk, I don't want to be rude but I saw that wiki edit you made under the recent changes in the wiki - if I'd made that edit, I'd expect to get my wiki edit rights yanked too.  That edit was really inappropriate. 

[Innula Zenovka]

Thanks, Whirly.     I found the edit you mean, and , while I understand (though I don't share) the frustration behind it, I have to agree with you.