When will we get a replacement for Reset/Recompile Scripts in Selection?

A while back, in order to fix a claimed "security issue", Reset Scripts in Selection for no-mod objects was broken.

Then, later, to fix another claimed "security issue", Recompile Scripts in Selection was broken totally.

When will we get these functions back? I have tools and work that I need to do with them which won't work anymore as a result of these changes, and the "manual method" of touching every prim, editing the script, saving it, etc just is not feasible.

Please consider returning this functionality in a future update.

along similar lines, allow a checkbox in the permissions settings to let others reset the scripts if they are nomod/nocopy.

Noo. It is Not broken.

A few days ago, an unfortunate accident with negative mass prims caused all of my scripted attachments to crash, and stay that way. Resetting them helped temporarily, but they all crashed on teleporting again.

BUT. Recompiling them, and THEN resetting them, fixed the problem. Only one of my attachments, which was no mod, was permanantly damaged.

For this reason alopne, I believe recompile is an essential feature. Please don't remove it. Disabling reset for no mod objects, seems fair, to be honest. For a start, things like temporary demo versions of products, require scripts to disable/derez the product when time has expired. These are alays no mod., If it were possible to reset the scripts, people could just continually reset and use a demo infinitely.

and if a script "breaks" in a no mod object, every time a user will have to contact the creator or seller so that someone can fix it.
Disabling resetting script for no mod objects doesn't sound THAT good to me.#
But okay, if that happens, I'll simply have to stay away from objects that I might not be able to reset.

It's worse than that. If a script "breaks" in a no mod object, the creator or the seller wouldn't have the ability to reset it either. It's effectively orphaned from the Reset in Selection option. The owner would have to dig through the prims, find the borked script, and reset it in the editor. Not at all practical or convenient.

Aside from the case where there was an LSL bug fixed after you bought an item containing a script, why would recompile ever be something that customers would need?

While I am talking about the loss of Recompile for even one's own scripts and objects, once in a while, it becomes necessary to load scripts into a high-prim-count object using llGiveInventory en masse, and the ONLY way to get them working is via Recompile, or opening each and every prim's contents, opening the script, making a trivial edit, then saving them. Definitely not an option when you are talking 500-1000 prims per object over 10-20 objects.

I know that it was an issue in the past where you could use a proxy or a hacked client to steal scripts that were no-mod via Recompile (all compilation is done by the client; dumb, I know, but there it is; source code is downloaded and compiled code is uploaded). However, that should NEVER be an issue where I have full rights to the scripts in question.

WarKirby:

Yes, it IS broken. It hasn't worked since the update a couple of months ago where it was "fixed". Try it again on one of your OWN scripted objects. You will see a window pop up which says "Starting Recompile of nn Items" "Downloaded, now compiling 'Some Script'" and it NEVER finishes or does anything else. It's been this way for MONTHS now.

No, I am AGAINST allowing Reset Scripts in No-mod object. There are many scripts rely on the fact that buyers can't reset their scripts. All rental scripts will be broken if renter can reset it. Such functionality should be controllable by script first.

Hrmm...

Next Owner Can:
[x] Modify [x] Copy [x] Resell/Give Away [x] Reset

I thought someone had already reported this on the Issue Tracker but it was something else; if any one of you would be so gracious as to report it and garner votes, feel more than free to link it to the Linden Lab Internal ID:

SL-32761 - Recompile scripts in selection does not work

which was entered on 2007-01-17, and which is on Studio Blacklight dev group's list. This not working confused me too.

Feel free to ping me, torley at lindenlab dot com with the Issue Tracker ID if it gets reported publicly, so I can cross-link the internal one amidst the many issues we're keeping track of. Thanks very much.

Rental scripts? Wouldn't they be owned by the landlord?

Actually, I would be more for putting in a script flag, changeable by script function, like llAllowUserReset(TRUE).

I would wager that there are a lot more scripts out there that would benefit from being able to be reset than would be hurt by it. Personally, I have never written a script under the assumption that it would be protected from being reset by the user. Not sure why anyone else would do that, considering that sims can roll back, and potentially reset scripts themselves anyway. At least, that is the assumption I always make.

If I need persistent data that is unaffected by the script being reset, I use servers (either scripted ones in-world, or external servers).

Still, if it is that big of an issue, do something like the above; leave the default as FALSE to grandfather existing scripts, and give us the means to toggle the flag via script. I would also think that detection of "dead" scripts would also toggle the flag to true automatically (like ones which have stack/heap collision-ed), but that's a feature request.

No. Nargus created a script that allows someone to rent one of his dinosaur avatars.

I actually opened this topic in jira ( https://jira.secondlife.com/browse/VWR-575) based on a discussion I opened in the scripting forums (/54/ad/180244/1.html).

As regards, Nargus's requirement a modified version of the script I put in the thread may help. Alternatives are storing permanent infomation in a hidden prim's name or description (you can use encryption to detect tampering) or even in an off world store via the http functions.

Or...

Indeed, and I included the idea of a reset permission in the jira report - albeit as a property of the script itself rather than of the containing object.

However,

a) allowing a reset of scripts in a no-mod object may be easier to implement (especially as it appears that this used to be the case) than added a new permission to scripts

b) if it were a new permission, creators may set it (or leave it set if it is the default) without fully realising the consequences (that the script will be rendered broken if it ever crashes). You are unlikely to use the script approach outlines without realising the consequences!

I was more looking for a reason why a customer - somebody who had bought an object containing a script - would need to recompile. Maybe I mis-read the OP.. Thought there was some suggestion that people should be able to recompile scripts on no-mod objects.

Personally, I'd vote for being able to reset scripts in any object you own, no-mod or not. Sorry, Nargus.

I don't think anyone has a valid reason to need to recompile scripts they do not have full permissions to, which is exploitable. However, if they have full permissions, they should always be able to recompile, if they wanted to or not.

Recompile is only really useful for scripts that you load into an object via llGiveInventory. In all other cases, you load the scripts in along with their object code and they run (or can be set to run) normally, so it isn't useful for those.



Well, that was the way it used to be, and almost everyone was (apparently, anyway) happy. Now, people have lots of throwaway items they paid good money for because the scripts have crashed, or otherwise stopped working, and there is no way to get them running again.

Writing scripts which depend on disabling reset I think is dangerous, IMO, because there are still ways to cause scripts to get "reset" (rollback a sim, for example). Still, I would support some kind of solution which allows it to work or not, selectable by the script author.

One word. Blitzers.

An item of mine was broken by one, If it hadn't been copy.. I would have been screwed. The creator is no longer in SL and the script is no mod. Recompile + reset is needed.

Done.

https://jira.secondlife.com/browse/SVC-202