Prevent the script from being removed from the object

Hello guys!

Is there any way i can prevent my script which is in the object's content from being removed from it by next owner?

Script is set no modify, no transfer, and so does the object - no modify, no transfer!

However if you rezz object on ground and rightclick on it and choose "open", you can simply drag the script away from the object to your inventory. As a result - the script has been successfully removed from the object.

You would say - prevent it from by script from being rezzed on ground, but in non scripted areas you will still be able to do that since no script will be executed.

So .. any suggestions?

Thanks.

I'd also like to know if this could be done.

I've not found a way myself but in attempt to prevent "script-theft" some of my commercially commissoned scripts have validation in them to see who the Creator of the object is.

If the Object Creator does not equal a hard-coded value "CreatorName" string within the script then the script will not run, thus rendering it useless.

The gist of it is....

string CreatorName = "Joe Creation";
integer PassedCreatorValidation = FALSE;

default
{

	state_entry()
	{
		llRequestAgentData(llGetCreator(), DATA_NAME);
		if (PassedCreatorValidation)
		{
			// let the script do its stuff
		}
		else
		{
			// prevent the script doing its stuff
			llOwnerSay("Failed script validation");
		}
	}



	dataserver(key queryid, string data)
	{
		if ( data == CreatorName)
		{
			PassedCreatorValidation = TRUE;
		}
	}
// default end
}

Obviously the script has to be "no-modify" and the solution is less than perfect. But would be happy to hear other suggestions

No, you really can't. I think it is stupid beyond belief to allow people to delete the contents of no-modify objects, but that's the way it is setup. Certainly you can build some security into the script as mentioned in the above post (perhaps even making sure the object has no-modify permissions if its owner is different from its creator, so you can be reasonably sure the script hasn't been added to the object by its current owner). But you can't, for example, ensure your build isn't used in some unintended manner by someone who has removed scripts.

Another idea I've seen mentioned here recently is to test the owner when the script is reset. If you design your script so that it never has to, and isn't supposted to, be reset, then you can have your script enter a dead state or delete itself on reset (when the owner isn't you). Then your script couldn't be copied or moved to another object, since adding a script to an object will always have it start in an uninitialized state (essentially it is reset each time).

For example, something like (be careful not to add this one to an existing script you didn't originally create):

integer initialized = FALSE;

default
{
    state_entry()
    {
        if (!initialized)
        {
            if (llGetOwner() != llGetInventoryCreator(llGetScriptName()))
            {
               llDie();
            }
        }
        initialized = TRUE;
    }
}

That's pretty much how I do it, with a slight change:

LicenseValidate() {
    if (llGetInventoryCreator(llGetScriptName()) != llGetCreator())    // No need for hard-coded names here
        llRemoveInventory(llGetScriptName());    // or, if you wanna be mean, llDie(); or both
}

Then stick a call to LicenseValidate() wherever, like in state_entry, on_rez, etc. The only thing that this can't detect is if someone gets ahold of one of your prims with at least copy/mod perms (transfer would be bad), and then they have an endless supply of prims to stick your script into to get around this. Of course, it then becomes trivial to spot violations of your license terms, since the prims would have your name on them.

Another method is to allow resetting only by you. Hence:

default {
    state_entry() {
        if (llGetOwner() != llGetCreator())
            llRemoveInventory(llGetScriptName());    // or, if you wanna be mean, llDie(); or both
    }
}

An alternative:

default {
    state_entry() {
        if (llGetOwner() == llGetCreator())
            state Operate;
    }
}

state Operate {
    // The rest of your script
}

Many times, you sell objects in which the scripts are already long past the state_entry event, and not many ever need to be reset (or can easily be made that way). So, you can generally safely assume that, if the script gets reset, it is broken, or is a license violation. No-modify scripts aren't supposed to be resettable, per a LL change around a year ago. If you choose this route, however, be nice enough to give the object to the user with copy perms, so they can pull out another copy if that one gets borked because, sure as shooting, SL will cause it to get reset at some point through no fault of the user, and a no-copy brick that they paid big bucks for doesn't make anyone happy.

Much neater, thank you.

Mmm...I think it is the object permissions, not the script permissions, that determine whether the script can be reset. You can definitely reset no-modify scripts in a modifiable object. I do it all the time.

There should be a JIRA entry for this. We need another checkbox or something:

_Mod _Copy _Transfer

should be...

_Scriptlock _Mod _Copy _Transfer

or something to that effect

At the risk of getting hate-mail... what's the problem?

I have often pulled no-mod/no-copy scripts and set them up in my own objects. Usually because of prim-bloat, and once to adapt a 'legacy' object to fit onto the HUD. What's the harm? I paid for the original object; I don't like the original object; I reuse the script(s) in my own object. Occaisionally I've even added my own script alongside the original scripts (for example to add an llDialog interface).

I can't get any extra function from the script(s) simply by shifting them into an alternative object.

You can, though, if the script is never meant to be reset, because it allows you to reset it. This is a change in behaviour. Either one has to script things so that it doesn't matter if they are reset (and note that storing data permanently then has to be done outside of the object, since you can't store it within the object or script) or you have to have state_entry() checks for owner and so on to make sure the right person is resetting it.

If I manage to erase persistent data by pulling a script from its original prim... surely that's my bad luck.

My preference for disabling a reset is to use this kind of check:

if (llGetScriptName() == "FullProduct" iActive = 1;
else iActive = 0; // Freebie Demo

if (llKey2Name(llGetOwner()) == "Pale Spectre" || iActive != 0)
{
// initialise script
}
else llOwnerSay("Script reset not allowed - now you've broken it. ";

...which means only I am guaranteed to reset my own script during set up. Once it goes to another owner it cannot be reset, regardless of who created the prim it's in - obtaining a mod-prim created by me wouldn't be difficult.

I use this to 'cripple' versions of scripts that come pre-set as a demo when they are in fact the full script - using the script's name to distinguish its capability.

Basically, I'd endeavor to protect the script(s) regardless of the object.

I like it.

I think the real question here is, are we trying to prevent removal, or reuse elsewhere?

you're not going to prevent removal since the object can be opened by the owner and the script can be deleted (making the script copiable would almost cover it) even on a no-mod object...

now if you just want to prevent reuse in another object the simple solution would be make it no transfer (although that user could create multiple copies this way, only they could use them)

more complex would be to check if it was in an object you created AND to check some other property (like no-mod permissions, or some hidden attribute(s)) and only work if those are present.

if you're the creator, and the object is no-mod, the new owner couldn't drop it in a similar object of yours because no-mod would prevent it, and if it's not no-mod it could self delete, or just not work (careful with this as you'll need to add a short-circuit like creator == owner so it doesn't die while you're creating it=)

Perhaps not to "move" the script to another object, but deleting the script from the prim altogether. It would be nice for those who want to sell and control items that are copy/transfer.

For instance, if one wants to sell houses to sim/property owners so they can place the house on land to sell to others but does not want to allow them to just start reselling the houses or giving them away, this can be done via script. They can have the object delete itself if the permissions are not changed on the houses to prevent the object from being rezzed with full permissions lol.

The problem comes in when the onject is rezzed over "No Script" land so that the scripts can be deleted from the houses and the owner decides to resell them or throw them in freebie packs...or just places it and someone else buys it and so and and so forth.

That would be my understanding of why it would be a good idea to allow an option to lock scripts in objects so they could not be deleted. I am sure there may be more reasons as well. Another is when people delete scripts from objects and claim they do not work and ask for another...just brainstorming here though

~Maddy