llResetScript not resetting properly?

I noticed some odd behavior in some new scripts I started today, odd behaviors involving llResetScript() that I've not seen before this last update.

I'm scripting a multi-person dance floor, and the floor is auto-calibrating for how many people it can animate at one time, and what dance animations are loaded into it. To make sure that it always resets itself whenever an animation is added or deleted, or the number of people it can animate is changed (by the addition or removal of 'child' scripts), all the scripts have the following:

changed(integer change)
{
if ( change & CHANGED_INVENTORY ) llResetScript();
}

Simple enough, right?

Except that SOMETHING isn't getting reset properly.

After adding an animation (or otherwise changing the inventory) of the dance floor prim and the scripts reset, then I click on the floor, I get the drop-down menu asking to animate; click yes, the animation starts, then immediately stops.

If instead I right-click on the dance floor and choose "Reset Scripts in Selection" from the "Tools" menu, then it behaves normally when I click on it and get animated dancing.

Any ideas?

There have been lots of asset server issues lately. Maybe it is related. Is the problem steady or intermittent ?

As far as I can tell, steady... in that of over a dozen trials, it's happened every single time.

[edit: oops! you say *all* the scripts have the CHANGE_INVENTORY handler... any chance they could be in some state other than the one handling that event?] There are no doubt other slave scripts in the prim that are actually pushing the anims, and those don't reset on changed inventory. Why it worked before is beyond me, but if it's indeed due to a change in this update, it could be anything in the slave script logic that starts and stops animations. As a workaround, you might either add that CHANGED_INVENTORY handler to the slave scripts, or, in the main script, llResetOtherScript() for each of them, perhaps in default state_entry.

All of the scripts do indeed have a llReset on changed inventory... the master script and the ones that animate the dancers.

Every script except the master is identical except for script name, and the slave scripts only have the default state.

The master script DOES have an "off" state (for when the dance floor contains no slave scripts or no dance animations) but there is a reset-on-changed-inventory event *IN* the "off" state as well.

Plus, since the slave scripts CAN'T animate someone without the key of the avatar having been passed to them by the master script, it's not like the master script is getting stuck in "off"... otherwise the animation wouldn't even START like I described.

[scratches head]

ive been having reset issues also, i can fully reset a script using a listen and me saying a command but as soon as i get an object to say the command the script doesnt completely reset.

[edit: Maybe the blog item, http://blog.secondlife.com/2007/06/16/lsl-script-issue/ underlies this.]

Really grasping at straws here. It might be helpful to get some debug info to just be sure all the scripts really are at least re-entering default state upon reset.

If the scripts are all properly re-entering default... then I suppose you'd want to investigate what can trigger the animation to stop, and trace which such event is happening when the reset seems incomplete. (Thinking of the old Solop Server, it uses sensors to detect if an av has wandered off without stopping the anim, for example.) And then investigate what might have changed to make that event behave differently after update, conditional upon some difference between manual and programmatic resets.

Although very unlikely to be related, the original problem was about animations starting and stopping, and there has been an incompatible change in the latest release in how animations behave when replaced by another animation with the same name (/52/26/190844/1.html)... but for this to apply directly to the original problem there'd have to be, like, an AO, and coincidentally-named animations, and some other unknown coincidence involving the manual vs programmatic reset.

There's also a thread in this forum (/54/ff/191262/1.html) reporting unspecified script weirdness since 1.17.