Recompilation of No Mod Scripts

Does anybody have any issues with new owners of objects containing a No Mod Script not being able to recompile, reset or restart a script?

I noticed that during a script update, the new owner was unable to recompile a mono (or LSL) script using the tools- recompile command. Scripts are No Mod Copy Transfer, while the object containing the script is Mod Copy Transfer

I also tried to recompile with edit rights and was unable to.

Yes the script works, and the new owner has a running copy of the same script inside an object. The problem is only apparent when updating script from inventory.


Any input?


Thanks

That is correct. You cannot recompile or reset scripts for which you don't have modify permissions. Compilation just isn't going to be possible, but you can always provide a user interface feature (touch dialog, for example, or chat command) that will cause the script to call llResetScript().

In the past, I'm sure I've been able to reset a script which I wasn't able to modify... maybe I was wrong...

Easily confused these days...!

Yeah, something's missing there.. I frequently reset scripts in products I've bought.

Normal in recent times has been that you can reset a no mod script, but can't reset if the containing object is no mod.

It has been this way for quite a while now. I actually use it to protect data in my VK-DBMS scripts. I use an alt to compile the script and send it to me no mod, I then include it in the object I am working on and can happily reset the object as often as I like, whilst testing, and my data remains intact. As Hewee says I always include a command in the object that allows a reset of the Database script.
Many people are scared of losing data in SL and jump trough hoops to store data off-line, but this simple trick has happily preserved my data for ages, the only time I have a problem is if the script runs out of capacity, which I do try to prevent by using the badly broken llGetFreeMemory() function.

Yes, the object is modify at a minimum and it worked until not too long ago.

This affects anybody that needs to send out mono script updates to their clients.

I dunno guys, I never sell a script with mod perms, and when it's been needed, my customers have always been able to reset them..they maybe didn't know how to I'll grant you..but they've always had the ability to do so.

Well the *recompiling* part is expected not to work, you can't send source code to the compiler if you don't have access to it.

I did just check a simple case, a no-mod "Hello Avatar" variation in a modifiable prim, sent to another account to smoosh the perms, with simple counters to see if reset is effective. X does still get knocked back down after a reset attempt on the no mod version of the script.

integer x;

default {
    state_entry() {
        x++;
        llSay(0, "Hello, Avatar! x is " + (string) x);
    }

    touch_start(integer total_number) {
        x++;
        llSay(0, "Touched. x is " + (string) x);
    }
}

One additional gotcha: the running checkbox will be dimmed for a no mod script, so it's important that the script is given out in a running state, that automatic transfers use llRemoteLoadScriptPin to preserve that, and that manual prim drags from inventory are done *without* control held down.

Thanks Viktoria, I had better go and re look at my storage scripts because it now sounds like things have swung the other way again. That is sure going to break a lot of my content, or at least remove the protection the data had.
I really hate doing product development in a world where not only do the goals keep moving but the damn pitch changes shape frequently.

Is there an existing JIRA requesting that the ability to "set running" for a no-mod script be available?

Test results:

passed an object with a nocopy, nomod script
The option to Reset or recompile is not available under tools

remove the script from the object and place into an object I built
script is still nocopy, nomod but I can reset the script.

This is annoying as for a long time it was script not object based and was a great way to protect data from an object reset.

I have no idea at this time how to work around this issue, but it certainly means that most of my content has now lost functionality and is liable to break if the user resets scripts.

The way LL intended the restriction to work is that reset would be controlled by the object permissions. If it was disabled in a modifiable object, that would have been a bug, even if it turned out to be handy for you

Sorry, I just want to clarify.

I am a scripter, and I frequently work with Recompilation as well as the options in Tools for Non Running scripts.

Recompilation should be possible when the Object containing the scripts is modifiable, regardless of the perms that the script has.

I know this for a fact, because just 2-3 days ago I was doing it myself. I test all of my products, as people can reset a script and think they will receive a brand new version of a demo or something. It has happened before.

I load my scripts with triggers due to this. Every time I send out a script I ensure that the script will only work with my items, and that resetting it will not reveal to the owner any privileges he/she shouldn't be getting.

When I tested this yesterday, I noticed Recompilation fails.

Please know...recompilation isn't supposed to Fail. When it is not supposed to be available, it isn't. The option isn't there.

But when it does appear, it isn't working properly. I don't know where people get the idea recompilation of closed source scripts was never possible, but for someone who's spent over 1200 hours in the past 4 months scripting, please believe that it was once possible, until around 1-2 days ago.

CDru

It was possible (And should still be?) with LSL2 scripts, however Mono scripts have never been able to be recompiled unless you have permissions to the script itself.

If there were circumstances where no mod scripts could be recompiled, that was an exploitable permissions bug that has been fixed.

Why that would be a bug and absolutely not wanted: on viewers 1.20 and earlier, if you can recompile, the source code has been transmitted to the viewer, where compilation happens. If the source code is in the viewer's memory for recompilation, then it is there for anyone to take, and no modify would effectively be full permissions.

Which would explain why this has been changed silently by LL with no prior discussion and not much likelihood of it being changed again, regardless of broken content.

Maybe it was possible with LSL2 scripts a long, long time ago, but until the introduced Mono recompilation of scripts from menu was actually broken and non-functional (even with full permissions). They fixed it when they introduced the options to compile to Mono/LSL. So I'm not sure where this big change people are mentioning comes in.

As for resetting, I might have been confused with object permissions. I DO seem to recall being able to reset scripts in a Multi-Gadget (sold with modify on the object but not on the scripts) and such on occasion.

The bottom line is that the new owner of a script should be able to reset, restart and or recompile it, if that is what it takes to make the script do its job.


The no modify permissions are there to protect you from people copying your work and should under no circumstance affect the useability of a script. Reset buttons are on just about any electrical device there is in the world , because electrical devices fail frequently and need to be reset.


Not being able to get a script started with the tools menu, is kinda like buying a new car that does not have a starter in it, because the car maker is trying to prevent you from starting the car in case you might get creative and then go run down random pedestrians..for fun

And the same argument works the other way too, if the scripts' job is to protect information, it should be possible to disable random resets, recompiles etc. and explicitly include a command to reset. In the same way the equipment manufaturers include a reset button to use your analogy.
But it is a mute point as LL will not be changing it.

I understand your point, but many scripts require that they NOT be reset (and thus, recompiled) by the non-creating owner. Certain business scripts do this for good reasons (certain state is set initially and mustn't be changed later). While you could make an argument that there should be a better way, this was how it worked when those scripts were written and it would be a bad idea to change it after the fact.

Good point. Too bad LL didn't think of this originally, but they didn't.

The *real* bottom line is that LL seriously fouled up by not documenting the required behavior for LSL and issues like this. Because they didn't, scripters had to "try and see", and how it worked became the gold standard for how it *should* work.

So, LL is now in the unenviable position that many times they can't fix poorly implemented things because too much content relies on the peculiarities of the bad implementation.

Welcome to SL!

QFT

I started a thread over a year ago when the unannounced change was noticed, titled something along the lines of: "Do we need to start building in a reset function into scripts?". There are a few ways to add it easily and it should be a part of everyone's scripting toolbox.

Unfortunately, resetting a script that has a stack overflow takes a separate script. In that case, the trick is figuring out a good way to activate the separate script to reset, without negatively impacting the user interface for the original script.

I assume llResetOtherScript() works if the other script is in stack overflow, which might not even be the case. I think I remember reading something like that.

These days, I provide most of my scripts full perms, so they can always be reset by the customer. That model doesn't work when the script itself is the valuable commodity, and is a license agreement violation for most purchased scripts.

I thought that if you didn't want people resetting your scripts, you had to put them in a no-mod object.

Yeah, that is what testing confirms, reports to the contrary in this thread are a little puzzling.