1.90 = Wtf?

Oh yes perhaps they'll add a tab to FIND showing the parcels displaying the most floating icons. We can pay people to drop attachments on the ground to get on top of that board yeah r0xZ0rzzz foreveroneoneone.

*Thinks it might be a good time for competition to start showing up*

I think I'm having a hard time wrapping my head around this. So when would an error message happen when there used to not be one? When a script calls llStopAnimation after someone unsits?

If I'm understanding this correctly: Objects lose permissions and avs have all animations stopped immediately once people get up now, and so when the script tries to call llStopAnimation it doesn't have permissions any more and there's an error. Only now it appears as a cute little icon.

*sniff* Boy, this will make learning the scripting even more fun.

*points to a chair* That one's working fine.. see, it's got the little Icon floating above it! Now how did they get it to work like /that/?

You know, that could be a new form of quality assurance! If you don't get that icon, don't buy!

I'd still love to know what they were smoking when they decided that this was a good idea. I'm not going to ask for fixes for my stuff, nor am I going to fix things that are doing their job.

Okay. How's this sound? No one patches their scripts, 1.9 comes out, everyone gets these errors and...

...millions, upon millions of bug reports, a tsunami of OMG FIX IT! Crushing LL's servers as if God accidentally dropped a steel-toed boot upon them from the heavens. (If he plays SL, he probably would).

Alright... I know this is going to be very very annoying because a lot of scripts are going to start generating errors, but...

Isn't it good scripting practice to check perms before you call llStopAnimation? It should break scripts that took the time to do that, right?

Well. Imagine your in an animation that doesn't stop running, like Motorcycle Sit, Pilot, etc ,etc. There has to be a call to stop those.

On the other hand, it would be nice to have a STOP ANIMATIONS function built into the client.

Well, there was no need to do that previously, because you knew that if you were stopping the animation you'd already have permissions.

I shall probably change my scripts to check permissions whenever they start or stop an animation, if changes in the way permissions work are going to start randomly appearing and disappearing with updates.

This is going to be a REALLY fun time for Live Help, let me tell ya.

-Flip

Until now, once we had ascertained that a permission was granted, for instance when an object is attached, there was no way for that permission to be removed without known events occuring, e.g. attach() and it happened after they were called. With the limited scripting space available, unfortuantely it's not always possible to fit in every last check and double-check.

In effect, the way this has been implemented, actually barges itself into your running script forcing something to happen out of step. Permissions are now removed before the final event, e.g. attach(), instead of after. For a script that tries to clean itself up to now get penalised with script errors, to me, seems odd.

I agree that you could check perms before llStopAnimation, but there are flows that are accepted, and this was one. I'm actually more concerned that putting this removal where they have, if anything goes wrong with their call to stop animations, the scripter now has no way of forcing things to stop themselves. It would make sense for them to call it after an attach() or changed() event, in which case the scripter can still do clean up and doesn't have to rely upon the system to do it for them. We know how much things break around here - I wouldn't be suprised if their new permission removal didn't work in all circumstances.

Yes, what I simply can't understand is why the check doesn't take place after the attach() or changed(). It would completely solve the issue; tidy scripts would be fine, untidy scripts would have their anims stopped. Would that make too much sense or something?

Edit: it would also help for those times when attach() on a detach to inventory doesn't get enough time to stop an animation, through no fault of the scripter. That's been happening to me more and more recently.

Bingo, I think you've just got their reasoning behind this, at a guess. I wonder if the script scheduler has caused even more limited code execution on the attach() event on a detach to inventory, which has led to more problems with stuck animations? So, rather than change the script scheduler to do this part properly, they're cludging a fix before the event as a quick solution around it.

My team tested this in preview this morning, in case it would affect client builds that would require repair. We found that the icon was only visible to the owner of the object, not to onlookers. No chat spam or anything, and it faded out after some seconds.

Hello.

Enabran is busy right now. I am typing for him. I am his passion for Second Life.

Decisions like these make me want to wither and die. Not because I can't handle uncertainty. Of course I can. What I can't handle is that Linden Lab will implement this, let people be pissed off about it for two weeks, then change it again.

And again.

I'm going to go to sleep now. I sleep a lot these days.

Nah, the icons fade away.

All the customers of your products will notice is that yours have that annoying icon on them when you unsit yourself and your competitors don't. So in the end you will have to fix them anyway.

Ah well... This doesn't effect my stuff. I ALWAYS check to make sure I have permissions even with clean up. I never trusted SL/LSL enough to think that it would actualy work as expected. Suckers!

That's the spirit!

Sigh...

I dunno. I'd probably not buy one that I wasn't sure was properly scripted (given how often the Lindens change their minds about things). If the icon shows it was properly scripted to clean up after itself, then great! *goes back to camping and cleaning*

As i started SL it was the big time of the spamming "Permission Trigger..", back in those days it was a clear statement from LL that you "ALWAYS" should check your permissions, maybe that knowledge got lost over the time ... however i dont think people can call it good scripting to not check permissions couse they asked for em sometimes ago ..

Sure i dont think its good to change behavior that quickly/much, however, none of my scripts were broken.

( Actually i wonder if even half of the people posting here even script )

Anyone who introduces extra processing into a detaching attach() event - like checking for permissions that you know you have - is just asking for their animation stopper not to run at all. It doesn't half the time as it is, even when you have it as the first call and do no checking.

And whoopee for you - you did things a particular way that means they're not broken by a random change in the way permissions work. Well, here's a cookie.

OK, I'll bite. If I remember rightly, it was people getting permission request dialogs appear on their screen, accepting them and then finding their avatar do something silly. That's what the permission trigger spamming was about, and I don't think it's related to this point. I remember them telling people not to accept permission dialogs from objects they didn't know. Which is different to this.

In most instances were talking about permissions that were granted automatically from a single request on attachments, vehicles etc. and not "some time ago", same session. LSL is slow enough as it is, and I'm afraid with that in mind and with limited script space, it is totally unfeasible to keep on checking permissions every time you wish to start or stop an animation. Plus, we're all conscious about sim performance and scripting loads. Especially with the scheduler.

What is interesting, is that the way they now do it makes clean up code superfluous, so if they ever remove the automatic clean-up in future, or forget about it and break it, then many scripters just won't have cleanup code in it at all and won't that be fun! It's actually taking control away from the scripter and will encourage people not to clean up because it's not needed.

I just don't understand why they didn't do it after the attach() or change() event triggers - that would make the most sense, as it's a safety net for those scripts that don't end animations either through lack of cleanup or because the code didn't run completely when detached to inventory. I can only presume that they didn't because it was more work.

That's actually a really good point Ordinal. It's always been known the the attach() event is not guranteed to run completely when something is detached to inventory (not such a problem for vehicles, eh SteveR). Adding extra lines in does increase your chances of it not being run at all. That's why I run my llStopAnimations first of all in the attach() code when it's detached, as it's the most important thing to stop.