Profaitchikenz Haiku

Best guess is, if you didn't cap script time and people began bitcoin mining or else wrote recursive functions that never reached the back-out point, the scripts would grab every bit of processing time they could.

Doh, I never thought of looking in them, just assumed they'd be binary files

I was thinking about your poser, it currently works just for the local client which is great for taking a snapshot but having got a successful position I would like to then build it as a pose in Qavimator so that it becomes visible to others. The next step using that method is to create several poses that form the sequence in a dance or complex movement, and put each pose into Qavimator at different steps, using the natural transition of the bones from one pose to the next to create the final movement. It's obviously not a patch on mocap but it's quite successful if used carefully. Currently I use the inworld tool to create these poses which are exported as bvh files, but qavimator does not allow the import of poses at different stages, so each pose has to be laboriously written out as the joint details and then equally laboriously entered at the appropriate stage in the working file.

QavimatorBeta can. But the interface just isn't good enough for all the extras, there's not enough space in the field for bones, it's a bit tedious. My suggestion was to have an interim solution until the Animator is ready, it's obviously not as good as saving the animation direct from in-world.

As a workaround or an experiment., I'd like to see the joint details (X-Y-Z pos & rot) chatted out frame by frame as a stream of chat so I could plug them into Qavimator. I appreciate this isn't an elegant method or ideal for a long-term solution, but it would be a lot better than my current method involving an in-world bvh generator using a couple of mannequins. (It has a sort of uneasy similarity to the use of dolls in police investigations - "using the dolls show us exactly what happened ")

Looking at some of VK's code snippets (see thread Identified seating bug with running animations without a touched seat ) I do see calls to llRequestPermissions and have to say I can't see at first glance why there should be a problem, that is why I suggested adding a diagnostic inside run_time_permissions. This could be a timing thing, of course, except that RTP will occur as a result of llRequestPermissions and so it's hard to see how it could have the wrong avatar key when it gets to work. Really out on a limb here but supposing the script has permissions for agent-1, then it has a perms request for agent-2 , so it queues RTP, but it hasn't finished changing the stored key of the agent it last held permissions for by the time RTP actually gets to see what it's meant to be doing? The other trunk-hugging possibility though, is that there might be an issue with the key returned from the Json for the seats, or there is more than one point in the code where the call to request perms is being made and it is not using the expected key.

I'm not sure why you posted the same thing a second time, maybe you hope that we'll all suddenly go "Oh Ok, we've been having a laugh, actually all you need to do is..." but I'm afraid it isn't so. However, I can suggest a line of investigation. I read what Qie posted, and after sleeping on it, I am wondering if this is an issue with multi-sits, the first avatar gets the auto-granted permission because they sat, but what of the second and so on? Are they getting an auto-grant that over-rides the first one? Are they not getting an auto-grant because they are being added to a link-set instead of becoming a sitter? Try this: Inside run_time_permissions, as soon as you have tested for the required one being On, use llGetPermissionsKey and llKey2Name to see exactly who is about to be animated. It might be the most recently-added sitter, it might always be the first sitter who actually claimed the sit target, but whoever it is, you need to know who is the intended target of the animation. If it isn't who you were expecting it to be, then you need to look backwards through the sequence prior to any call that would cause run_time_permissions to occur and see what is being set up, or not.

I'm sure I already answered this See the two specific caveats you have posted, permissions persist across state changes, and a script can only hold permissions for a single avatar. If you want to have several avatars on a single prim and animate each of them you need a second script for the second avatar, a third for the third sitter, and so on. For the second sitter, send a link message to the second sitter script giving the avatar key and name of animation to play. The second script must do the request permissions and start/stop animation for the second avatar. The State change will not alter which avatar has currently got permissions held by the script, that remains unchanged until the avatar stands.

Try claiming that it is this dead junk that is contributing to the lag and lost script run time?

Another "Rez" See, I think SecondLife should play this when you rez an item, not the rushing sound they currently do.

Which many people seem to be doing anyway This problem with unpredictability suffers from the fact that there is a workaround, restart the region repeatedly until the problem eases. While there's that method, I can see why the Lab might decide to let it ride and hope that the cloud migration cures it anyway due to better hardware.

Nothing to do with experiences being introduced, I suppose?

It took a bit of digging to find why you couldn't animate the second person, and the detail was buried. But I think you are going to have to do this: Have your main script - sit and animate the first person to sit on the stool, and keep a record of the second sitter, initially NULL_KEY Script 2 - let's call it side-sitter - which s addressed by a link message from the first script. When an additional sitter is detected, the main script must pass to side-sitter the key of the new avatar, and the name of the animation, plus I suspect the message number 1 for animate them and 0 for stop animating them. There's some other details to be addressed, such as should the main-script pass NULL_KEY to the second as a way of saying "clear the second seat", but I have faith in your ability to get there

You have to use request perms as it's the only way that you get to specify the key of the avatar to be animated. without it, calling StartAnimation is simply going to play a new animation for the last avatar for which it obtained animation permissions. ETA Ah., I see the problem, from the wiki for llRequestPermissions Scripts may hold permissions for only one agent at a time. To hold permissions for multiple agents you must use more than one script.

You need somebody else to witness what's happening, as often the clientside animations might appear to be frozen to you but somebody else witnessing them does see the animations working properly. it's something I don't understand myself but I've encountered it enough times to be aware it's a prevalent problem, just no idea why or how to circumvent it.

I presume the obvious has been tried, restrict object-entry, rezzing and scripts to group-only?

But for how long? A few years ago it would have been Sourceforge or FreshMeat , two years on somebody will come up with a snazzy new name (like MeWe took over from Google+ and Dischord from whatever).

Yebutt, I left school decades ago. Your example fits perfectly into my "part of a team", it leads to a sort of "Render unto Ceasar" scenario, but here in SecondLife I see no need for conformity to that degree. I admit I'm biased after years of wading through changed code where somebody has done little other than effectively reformat it to their idea of what it should look like, giving a real headache to somebody like me who's looking at the differences between one version and the next to try and spot where the problem has been introduced.

Readbility and beautification of code is really driven by who needs to see it? If you're part of a team, then all the other members of the team, so there is a justification for a standard. If you're going to present it to all and sundry then there's no defined standard, what you need to aim for is clarity and a structure that helps it make sense. If your style differs from theirs (and it must), let's say you don't prefix all global variables with g, that's less important than you declaring globals before they are used with either an explanatory comment or else a name that is self-explanatory, likewise functions, and where you are compacting expression, a comment often helps. And you can't have too many parentheses so long as they balance. If it's just you, then the main criteria is, when you look at it two years hence, will you still be able to understand it? You are the audience, and so long as it makes sense to you, that's all that counts.

Got to say enforcing coding standards, whilst I could see the need for it when I was working on large projects with many coders, is something I dislike. Imagine if they made authors adhere to it in their works of fiction? I should have been a pair of ragged claws, scuttling across the floors of silent seas

Ok, finally found my notes and scripts. What I was seeing was, despite doing the tests for agent size indicating the avatar was still in the region and permissions showing permission to trigger animations was still set, trying to stop the last-applied animation was giving a permissions error for any TPV with the setting on to revoke permissions when standing, but not for LL viewers or TPVs without that setting. At the time I then was seeing this vary from place to place and this was when the percentage scripts run was beginning to drop. I didn't know if the scripts run drop was the cause of the delay, or if the TPV's revoke-permissions method was taking a while to actually change whatever the stored settings were (i.e. with the LL Viewer, standing stopped the animation but the permission was still there so the script-call succeeded. with a TPV the object permissions might have been revoked after the test to see if animation permissions were still granted but before the call to stop the animation, hence the error message). I had begun experimenting with adding llSleeps of short durations to see if that got improved reliability but given some of the parcels I was looking at had script run percentages of less than 60 I was loath to add further delays. I've done some quick testing and I think you're right, the animation gets stopped as soon as the avatar stands. In that case I don't see any need to stop them in the script.

Ah. muy bhad. Just checking back it looks like I gave up on stopping the last animation over a year ago because it wasn't possible to do it without getting the script error for the TPVs so it does seem to back you up, the animations are stopped. I miss the good old days when somebody would arrive near you in a strange grotesque pose leftover from whatever it was they had been doing last, and you had to give them the red rose of release.

I'll have to dig out my notes again, but I was looking at the following scenarios after a sitter has been animated by the script. Sitter stands up but remains nearby Sitter does a flying-sit to a nearby scripted-sit object Sitter crashes/logs out Sitter TP's out of the region without first standing I was also testing Avatar_size, which returned zero_vector for the crashed-out or TP-ed out sitters I was seeing a disparity between the error messages depending on whether the sitter had a TPV with "revoke permissions on stand" active, or had the LL viewer or else a TPV but the revoke permissions option unchecked. I was mostly worried about the sitters who TP-off to another region because of the known issue with people returning to a region where they had previously accepted animations from a scripted object still being under control of the script in that they had never explicitly revoked the permissions. But if you say that all viewers now revoke permissions when standing up I might be worrying to no purpose.

Only in TPV's which have an option to revoke permissions when standing. I've been banging my head against a wall on this. In the scripts I have, a script error pops up when an avatar using a TPV with this option set stands. On the official LL viewer there is no such script error. And since you can't detect what viewer the sitter is using you can't code for it.

I doubt that snippet would have helped since it isn't actually setting a sit target, just counting how many have been set in the link set, but in the particular problem it was a one-prim multi-sit issue, and (as usual) nothing to do with the script but everything to do with encroaching physics shapes. Just as fish (apparently) do not see the water in which they swim and we do not see the air in which we move, when your house is within the physics shape of a giant skybox you don't see it.