1.90 = Wtf?

Hmm.. I can't see how it could be any more work than introducing the thing at all. I mean, if it wasn't already in the "hard code", then it would take effort to introduce it. And that effort obviously wasn't put into THINKING about where it should go. The only reason I can think of that they didn't do it that was because it simply didn't occur to them - a perfectly normal human mistake. What I don't understand is why some of /them/ haven't been asking the same question!

If it didn't occur to them, they didn't think about it long enough. Simply working through it tells you that the least intrusive place to do this is AFTER the event, not before. So, if we accept that they thought about it long and hard (don't laugh), then there must have been an operational reason for putting it before. And I suspect that they could just hook it into the event firing code easier than working out when the event had finished. Sometimes the easiest things on paper prove to be the most difficult in practice, but that's not to say it shouldn't be done the more difficult way.

Maybe this is part of a larger plan ...

Since things don't wear out in SL ... maybe this is the way for us all join the "throw away" society. Everything that gets broken by this can be discarded and replaced.

Warm those vendors everyone

Well, strictly speaking, nothing's actually broken by this. It just throws up script errors that now show up as an icon over the item that then fades. It doesn't actually break the functionality of anything.

Okay, that would be waaaayyy more thought than what the Lindens have obviously put into this little "feature". (It's only a bug if they say it is. I will think of it as a bug and shall report it as such!)

*shrug* I've never had a problem with animations not stopping with something like:

attach(key id){
  if (id != NULL_KEY){
    //do whatever for attach
  } else if (llGetPermissions() & PERMISSION_TRIGGER_ANIMATION){
    llStopAnimation(anim);
  }
}

The object just got detached, how am I to KNOW that I still have perms? Maybe that's just me not trusting how lsl is/was *supposed* to work, though. I think we should all know not to do that by now.

IMO, I did it the correct way, which always worked, and is not effected by this change. I'll take that cookie now.

Perhaps the reason I've not had problems with it is because the llStopAnimation is still the very first thing being done when the script realizes the object isn't attached anymore. It just so happens to check to see if it still has perms at the same time it checks whether it's attached or not. Or maybe I'm just REALLY lucky.

Perhaps you are lucky, or live in good sims, but the llStopAnimation is the very first thing I do as well and it fails noticeably often.

Actually SteveR, you're right that a simple check would not cause this, I don't question that at all and, in hindsight, it's one thing I should have done in my skates.

I still think the timing of this permission loss is stupid before the attach() event is run, as it means that scripters cannot include their own code to force animations to stop, should LL's own implementation fail. We're all going to have to use some extra CPU cycles on anything that animates now, checking permissions each and every time we start or stop an animation, just to be on the safe side.

Of course, having said all that, trying to write anything that caters for any eventuality in a language that does not have any error trapping at all, or even adequate feedback of the success of failure of a given command, isn't something that's feasible. You never know, you had the foresight to include the line in your code and got away with this one, hopefully the next one won't bite you on the ass.

I guess I took the state of a permission granted for an attachment as a given and have been bitten by it Obviously not something I'll be doing again. Mind you, not that I'm doing anything much in SL currently anyway.

*waves at SteveR*

Brent Linden has confirmed that this will be changed:

/163/ad/90123/2.html#post932063

Ok, here's the fix to the fix that fixes your fix:

We will only automatically take away permissions for the camera, since that is why this fix was being put in in the first place. We are trying to prevent "camera griefing" -- or taking the camera and not giving it back! In the process we hit every permission, and after some thought, fire bombs raids on the Lab and constructive criticisms from you all, we decided that was a bad idea.

Thanks for your concerns, and see you in Preview!

Yaay Thanks

"Ok, here's the fix to the fix that fixes your fix:"

lol

grrr, can't help but love him.

Better update that he just posted that the fix that fixes THEIR fix won't happen for 1.9

Thanks to a fundemenal change in the way permissions act - (a totally legal and verified by LL behavior) - I have to take down all my diving board vendors.

if a fix becomes available I will update them.

I won't - however - give refunds.. thanks to the telehub precident of refunding devalued shit - and that this behavior was 'snuck in' at the last second.. I will be telling folks wanting refunds to contact Linden Lab.

I'm not greedy - I don't want compensation - but I think all requests for refunds and support should be directed at the source of the problem.

I feel a disturbance in the force... as if millions, ahem, thousands of second life users collectively screamed at LL support for unilaterally deciding to break every object of theirs that used to work well, did what they wanted, and raised no complaints from anyone.
Worse than that, they'll come screaming to US for a replacement! And we're supposed to shoulder the costs of this stupid decision!

Siggy, you should not get any error messages for any permission other than the new follow camera stuff, and since it doesn't exist in Agni yet, you don't have any content that relies on it and thus -- no problem!

You should not have to take down any vendors at all.

Thanks for letting us know Brent.

Maybe in the future it will be possible to make this feature optional for other permissions types somehow? Like, adding a toggle function:

llAutoRevokePermissions(PERMISSION_TRIGGER_ANIMATION, TRUE);

Just trowing ideas. Either way, thanks for fixing the fix.

Brent, if youre worried about camera griefing, how about adding a RETURN CAMERA popup button to the UI, instead of automatically revoking camera permissions? The button approach would seem to be consistent with existing functionality; we already get a STAND UP button when sitting.

Brent - I just had someone go into preview and test it and email me here at work - their diagnosis is 'borked'.

I was going to an involved post on what exactly is wrong with whats going on - but describing in detail how one of my premier items works on a public forum really leaves a bad taste in my mouth.. I'll PM it.

Seems I can't PM you... suffice to say the new behavior of relinquishing permissions on unseat sorta totally borks it. The keeping of perms after unsit was behaviour verified as 'correct behavior'. And now is 'incorrect'.

I'll be looking into it after work tonight and seeing if my friends diagnosis is correct - I susspect it does based on all descriptions of the changes - and the reports sent to me from preview.


On a side note: I find the breaking of existing content based on what was thought to be true and correct behavior in order to bring in 'the new shiney' - and to fix problems that may occur with 'the new shiney' (not to mention appearing not to make good on the other points that were said in the intial release posts) to be irresponsible and reprehensible.

Siggy, what do you think of the RETURN CAM popup-button idea? It seems to me that would achieve LL's goals without breaking anything.

Was on the test server and tested the following items and had no error messages or popups or bubbles:

Furniture with Crystalshard Foo's open source poseball script.
Random furniture from various people.
Some ice skates (no not the famous ones).
Dominus shadow car.

I think thats a good idea - I also think that releasing all perms etc to make possible a single new feature is something not thought through entirely. It seems like going for the 'quick fix' and pushing the new feature through prematurely.


In any case

I appologize to Brent for any heated comments said in frustration.

Crap, I love that diving board you made Siggy, I really hope it isn't borked. It's very kewl.

Okies from the latest update thread:


Definative answer - straight up... is this how it's gonna be?

If so - it borks shit - rewards bad scripting practices - and is gonna cause me a shitload of headaches over the next several weeks.

And being given a couple of days 'heads up' is pretty crappy too..

Simple 'yes' or 'no' will suffice - it seems the more that it's discussed the more convoluted answers I'm getting.

I say 'yes' .... or ... 'no' ... meh what do I know I'm simple.