so, they kill something that is useful and used in people products with NO WARNING?

Bovine Stuff, I don't understand at all, this has ruined our business.

I doubt they will fix this. I have other issues here that have sat for months without action. I will try to code a workaround; in the meantime, if anyone who purchased En Garde wants a refund please IM Rifkin Habsburg.

@LL
I told you so.
And you wonder why people say LL is bad at communicating?

This could have been avoided by posting in the Scripting Tips forum.
This could have been avoided by posting on the Scripting mailing list.
This could have been avoided by posting on the wiki.
This could have been avoided by posting on here on PJIRA.

Some free advice:
Use the myriad of communication methods at your disposal to communicate with the public.
A small 10 minute investment could have improved your image with the community instead of further sully it.

There's no plan for this to be permanent, and I'm asking for this functionality to be added to the test plan for future releases. (I'm bothered too - it broke some of my furniture!)

Do me a favor and raise the issue on sldev or in the Monday bug triage if something like that comes up again. We want to safeguard existing content, and making sure multiple Lindens saw that would have prevented this. The Linden you spoke to must not have known that this was such a widely-used hack.

"I'm asking for this functionality to be added to the test plan for future releases."

How about future being IMMEDIATELY? My business has taken a major hit and I've got people clammering for a refurnds! It's gonna be bad enough it if we have to go out and replace everything with a hacked script, how about just PUTTING IT BACK THE WAY IT WAS till a better fix can be written and TESTED THIS TIME?! I'm looking at losing upwards of L$30,000 if this is not resolved QUICKLY.

There are many that give long hours to create an event to bring others into this program, and are also effected by LL's hastily reactive approach to bar a problem area. As with all situations, the ones that are effected and punished are the ones that probably are not using it inappropriately. Those greifers have now moved on to the another situation, still uneffected or reprimanded.

I can say that the items purchased for our event are now going to stay in our inventory come event day and our event will be basically Uneventful.

Not only do LL have their reputation on the line when these things occur. They force ALL to the front line to receive a blow in that regard, as well.

Maybe Lindens should play their own game a little more often. Does anyone actually test these bug fixes on the beta grid or some secret grid somewhere? If not, you guys might want to think about doing that. Could save you some time and PR headaches!

However, I take offense at your statement that this is a "hack".

IF LL DOCUMENTED THEIR FUNCTIONS, and if this was a use of an undocumented feature, THEN, you might be able to call it a hack.

However, LL does NOT document the intended behavior of their functions. Instead, they leave it to the community to discover the apparent intent of the functions and document them. Thus, WHATEVER A FUNCTION DOES is it's definition.

This is LL's fault. This is NOT a hack. We're only doing here what we're FORCED to do for all LL functions: discover what they SEEM to do, and take it for granted that it's intended!

Whoever is in charge of LSL documentation at LL should be deeply embarrassed. They deserve ridicule. The documentation of LSL functions is insufficient even for INTERNAL documentation, and is laughable for a customer-accessible interface. It looks like they found someone incompetent and gave them the documentation job because nobody else wanted to do it. (Thus the Wiki was born, and the rest is history.)

Thi is in my opinion as a software engineer for 30 years, including over a decade being senior architect for middleware, where API documentation is crucial.

SL is excellent and shows a lot of hard work and good judgement on a lot of very tricky technical issues. The LSL documentation is way, way, way below that level.

Sorry for the rant, but you have no basis on which to call API use "hacking" unless you have a well-defined API. It's not your fault that LSL is not documented, but since LL took this path, they're stuck with the consequence: they can NOT ever say that we're misusing the API unless it's for an obvious griefing attempt.

(Note: I'm using the old meaning of the word "hack", meaning diddling with software to get an intended result without regard for good software structure, rather than the newer meaning of circumventing security mechanisms. My use is consistent with Soft Linden's, above.)

• winks* Thanks and have a winning day

I've fixed this, am testing it now, and we hope to roll the fix out soon.

Please help me thank dibbs Dovgal, Esmee Isbell, Silicon Plunkett, and Strife Onizuka for providing useful comments.

Why then does llGetNumberOfPrims() include the number of sitting avatars?
Why then does an avatar sitting or standing generate a CHANGED_LINK event?

With all due respect, you can't say something like "prim linksets never include avatars" when LSL has behaved until today exactly as if they do. Your statement may reflect an intent, but it certainly does not reflect the reality of SecondLife's behavior that we have all had time to become accustomed to.

Oh and thanks to DanielFox for showing Qarl and Soft how little they know about their own platform.

The problem here is - LL might be almighty when it comes to giving us features/functions or not, but they are not almighty when it comes to taking them from us again.
I mean creators and designers are the backbone of SL. If content designers have to leave because LLs latest actions break their products and businesses, then LL takes a pretty hard hit. Stuff like this gets passed on and word of mouth can be deadly in the information age.

So if a function is used by a mayority of uses in SL, you can't just take it away again, and it automatically stops being a "hack" as in "ok, you shouldn't have been using this anyway so you can't complain when we take it from you".
Because that's what Qarl and Soft wanted to express when they said that this was a hack - "don't blame us, YOU're the ones who used this hack when you shouldn't have".

I think it's understandable to defend ones actions and from a programmers standpoint, Qarl and Soft might even be right. But this is a public jira and it gets read by a lot of people who are not programmers, who might be really angry at LL (once more) and this stuff stays on the web forever. And Lindens (sorry, please excuse my language) bitching about who is to blame in the comments here just doesn't make things better.

Jules
(who really tried to be civil)

Juliet - i'm sorry you're angry - but yes, this is a hack. regarding your proposal about business owners and serverside releases: you're aware that we release our server code to the preview grid before we release it to the main grid, right? so in fact, EVERYONE can test their products before a release. my understanding is that we broke this policy for this release, because of the conflict with the havok branch. that was a mistake, and we regret it. going forward, our nearly completed het-grid project will allow sim owners to pick and choose when to upgrade their sim - which should alleviate nearly all of this problem - early adopting sims will warn you of product failure before the entire grid updates.

Mistakes happen - if they would all be addressed and resolved this quickly, SLife would be alot better.

Be smart instead, don't hack up nonsense functionality using code exploits and third party BS. If you want more functionality ask Linden for it! Otherwise you have no real or legitimate leg to stand on when Linden randomly exorcises your pretty little contrivance as part of a routine debugging of the infrastructure.

Let's face it, there are plenty of valid issues to whine about, acting like a dumbass however isn't one of them.

p.s. I think it's just plain lucky that Linden didn't ignore this issue.. they certainly don't own you people a fix

And this is the way to extend LSL capabilities when there are no other ways to do it. Do you think that people would be doing this if there were formal LSL defined techniques to allow avatars to move in this way? And there is no down side to the effect, (until it is turned off of course).

Either way, I am very glad that Linden labs responded to this and I give them kudos for being supportive of even non-intended yet useful extensions to what were obviously unanticipated results to the way they organize their data structure.

For example, is WarpPos as supported feature? I believe not. Yes this is used all over the place., And make the SL experience more vibrant for all.

I have no issue with LL creating a new sit-target system. It should allow for getting, setting and updating sit-targets.

Despite the current implementation being a hack and requiring the use of hacks to provide functionality, it is what we have.

If LL is going to make this official functionality, it would be nice if some of the uglier math were done by the PRIM_POSITION flag for avatars. To do this the old PRIM_POSITION value should become legacy (so old scripts don't break) and a new value assigned to PRIM_POSITION. The ugly bits of math that I am referring to have to do with the agents size, there just isn't a good reason to keep that exposed. If the ugly bits of math were properly hidden, then the below function should work without further change.

UpdateSitTarget(vector pos, rotation rot)
{
llSitTarget(pos, rot);//Set the sit target
key user = llAvatarOnSitTarget();
if(user) //true if there is a user seated on the sittarget, if so update their position
{
if(llGetAgentSize(user))//This tests to make sure the user really exists.
{
//We need to make the position and rotation local to the current prim
rotation localrot = ZERO_ROTATION;
vector localpos = ZERO_VECTOR;
if(llGetLinkNumber() > 1)//only need the local rot if it's not the root.

integer linkNum = llGetNumberOfPrims();
do
{
if(user == llGetLinkKey( linkNum ))//just checking to make sure the index is valid.

}
while( --linkNum );
}
else

}
@end;
}//Written by Strife Onizuka, size adjustment provided by Escort DeFarge

https://jira.secondlife.com/browse/SVC-750#action_28997

Not to mention in our conversation we were talking about the sim crashing bug with using PRIM_TYPE on agents (which I already knew about), and so any public discussion would have to be handled delicately. Such a discussion could be done on an NDA mailing list.

Strife, if you could make a JIRA for what you think a new dedicated function should do, that would be ideal. I'd discourage any refinement of the existing routine, rather just supporting it as-is while trying to steer new scripts toward a dedicated function with well-defined effect.

When hierarchical linksets happen, then I think we might see it done properly.

If it was never intended for an avatar to act as a member of a linkset, why were three, consistent interfaces that treated sitting avatars as equivalent to prims exposed to end users? This is not just one function call name at issue.

I think there is one point here that I haven't really made clear with my second post but I think it is so important that I will try to rephrase it again:

Whenever a hack gets used by quite a big number of users - say 10%, then it stops being a hack.
It simply becomes a regular function that has to be protected and needs to be treated as if it was intended in the first place.

Why is that? Because the residents are right, the builders are right and the scriptors are right at the moment, that their number is big enough to hurt the grid a significant amount when they are upset about a problem.

Lindens have to understand that giving functions and features to residents is more or less a one-way-street once they become widely accepted. If a significant part of the economy and communnity relies on a so called "hack", then it can't be taken back anymore.

Everything else hurts Second Life too much. So much that people will be discouraged enough to leave.

From what I've heard, todays avatars were originally "primitars", back before it was called "second life", and actually composed of primitives. If so, this WOULD certainly explain the carryover that nobody bothered scripting OUT of the system, as well as today's current problems and questions.

Anyway, I look forward to a speedy fix. I also look forward to a more formal/rational/supported avatar positioning scheme as LSL evolves. I hope it is provided as an alternative set of functions/structures rather than modifying or extending the existing ones. I think LL should also consider a formal mechanism for deprecating outdated portions of the API so that scripters are continually warned of planned API changes (compile warnings, anyone?), along with guidance on how to update their code to newer standards/conventions.

Then there is the clearly pointed out argument that LSL is an almost entirely undocumented language, and we are given no clear guidelines on what is, or isn't expected behaviour.

Regardless, restoring the previous behaviour is good.

With the patch:

llSetPrimitiveParams - always excludes agents from the set
llSetLinkPrimitiveParams - only allows position and rotation changes if the target is an agent

If anyone finds llSet[Link]PrimitiveParams-related problems after the update, please create a new JIRA and point to it in the comments.

I was so bummed when this happened and so exhilarated now!

Please make a Jira entry for your suggestion. I agree with the above, except that we'd want a new name for the new PRIM_POSITION constant. Old scripts when recompiled should behave the same.

Please see https://jira.secondlife.com/browse/SVC-1433