Resetting scripts and permissions

I notice that in some cases I don't seem to be able to reset scripts in an object.

I think that the Tools | Reset Menu is grayed out if the object contraining the scripts is no mod? Is that correct?

This seems a little risky - if the script crashes for any reason (sim crash, heap space, script bug etc.), doesn't that render the item broken and if no-copy as well requires getting a replacement or a fix?

Has this always been the case?

If an object is no-mod, you cannot reset the script in it.

If the script is 'stable', you generally won't run into problems.

Personally I don't think this behaviour is desirable. Just today I met someone with a broken diving board. We all thought it was likely that the script had broken, but being no-mod there was no way of resetting the scriptn. The creator had apparently not been responding to IMs or notecards (of course this may be that the creator is currently away or perhaps left SL sometime ago etc., so may not have been deliberately ignoring them).

I think any programmer here, if they were honest, would admit that any piece of code being the trivial (in LSL or C++), regardless of how carefully written or tested, will almost certainly have a bug somewhere.

Given the limitations of LSL, the odd mix of standard flow and event driven flow which can result in arduous code at times (if you are trying to use linked messages to import functions from another script for example), it is even harder to fully test and debug LSL code, especially with multi-user items.

Add into that the quirks and bugs in SL itself, and problems that can be caused by sim crashes and bugs in the LSL engine, and i can think of lots of ocassions when even the best written and tested scripts could fail thus rendering what might be an expensive item worthless - all for the lack of being able to reset scripts in no-mod items

On the other hand, I can't think of any ocassion when you would not want the end user to be able to reset the scripts in an emergency (possible include notes that resetting will loose data, etc. but people are used to settings being lost when you reset RL items).

What do others think - is this worth a change request in jira?

Samm

I'd say so. As you pointed out, there is no obvious reason why not being able to reset a no-mod script would be advantageous. Feel free to show me an instance where it would.


Most of the "toys" I design fall on the very complex side of things due to the frequent fuzzy logic I implement, and I have always been forced to sell the times as (mod) or implement a script reset function so that people can reset the items when sim crashes and the occasional physics glitch causes the logic flow to go astray.

The only example i can think of is when you may really want an item to only have a limited number of uses. However, this can be done using a script such as the following:

key creatorKey = "..."; // your key here

default
{
    state_entry()
    {
        if (llGetOwner() == creatorKey) {
             state working;
        } else {
             llSay(0, "Item broken - contact ..."); // or similar message
             llSetScriptState(llGetScriptName(),FALSE);
        }
    }
}

state working
{
// rest of script

This has the advantage that should you want to re-enable the object all you have to do is take the object from the current owner, reset the script and then give it back, and it allows you to put in an appropriate message as to why the item is no longer working etc.

Samm

Advantage for not being allowed to reset a script:

Combat Meters. A well known 'cheat' in a combat meter is to 'reset' it in order to regain all your stats, lose deaths, etc. Making the object no-mod prevents a meter reset and eliminates this chance of cheating.

Coincidentally, the only no-mod items I make relate to combat meters and systems.

in this instance, wouldn't it be better to have an "opt out" type of system for not allowing scripts to be reset? Such as a permissions flag (like the mod/copy flags) where only the creator can reset the scripts within.

Well you could use the above approach and include a big "DO NOT RESET THIS SCRIPT" in the documentation

In any case what is to stop someone just getting a new combat meter in order to cheat?

As Senuka says, if there is a real reason why you need to prevent scripts resets which can't be effectively "emulated" in the way I've described above, this is distinct from wanting the prims no-mod. Indeed this should be a property on the script so that you can have a script not in a prim also have a no-reset property or a mixture of resetable no no-reset scripts in a prim.

BYW, I have added this into jira at https://jira.secondlife.com/browse/VWR-575 with a link back into this discussion.

Samm

I've added the idea of a no-reset property into the jira - pleaae comment on this though, as personally whilst I understand Kenn's requirement, I still think that allowing people to easily create no-reset scripts is dangerous. I mean imagine if you had to replace your computer whenever it crashed!

This appears to be a Bug [A problem which impairs or prevents the functions of the product] rather than a New Feature [A new feature of the product, which has yet to be developed]. Since it was not mentioned in the patch notes as far as I am aware.

I've been fiddling with this issue regarding the problem of transferring scripted objects reliably.
Transfer is necessary for both initial sale and to allow the purchase of items as 'gifts'.
In my case a script with a lot of states makes it hard to anticipate just where in the script it might be taken into inventory and later transferred. If you don't want to allow anyone to activate the script you need to add a lot of owner checking or the script will freeze waiting for a response from a previous owner key. An easy reset would definitely hit a state entry that would initialize all owner keys for all listens and dialog.

So - here's what seems to be happening.

If you have a script where the Permissions are set MOD - NO COPY

in an object which has the Permissions MOD - NO COPY

NO ONE WILL BE ABLE TO SEE THE SCRIPT IF THEY GO TO THE CONTENTS.

Apparently both Mod and Copy are necessary permissions for the next owner to be able to see the script. However.

If the new owner selects the object to EDIT - YOU CAN RESET THE SCRIPT. - using the TOOLS MENU - Reset Script In Selection. - You can also Start and Stop the Script.

This of course means that the next owner can Edit/Modify the object and quite possibly break it. But that's how you learn - at least the object can be put into a reliable state initially.

For me it works because I have simple objects and complex scripts and apparently they can't see, copy, or change, the script itself.

IF ANYONE KNOWS ABOUT A VULNERABILITY IN THIS APPROACH PLEASE RESPOND.

Tried this and it seems to work, but in fact, the script's perms don't have anything to do with it being resettable and able to be started and stopped. That works for no-mod / no-copy scripts, too, as long as the containing object has mod permission. (Well, there might be one difference: for no-mod scripts: I don't know of a way to reset them one at a time, but rather can reset them all at once from the Tools menu.)

I don't know one way or another if there's any special vulnerability for mod/no-copy scripts.

@Samm
Generally I support the request of being able to reset scripts in owned objects.
As a workaround for the item you dealt with: have you tried to re-rez the object? If it contains a script reset at the event on_rez, it might clear the issue.

Edit: in my view, it's always a good idea to include such an option in items created, have some animation furniture that reinitializes when rezzed, so if there's some trouble, eg the rezzed poseballs remain at their place when moving the main object, I simply can take it and re-rez it.