sadly you are right. it’s not preventing theft at all, nowadays. it has been a protection, but that’s history now.

so what has been left is some sort of inconvenience for any and every customer. the promise of an permission system permitting calculateable business for inworld content creation has failed us.

1. Set object to mod.

2. Receive goodwill from customers, sim owners. Do not get burned when script limits come into play.

3. Profit!

If I were ever to distribute this I would require it in the license agreement that the prims be mod. 1, so if the lab broke it the item would still be usable and 2, no mod prims suck plain and simple and there is NO reason to sell something no mod anymore. If someone wants to steal your design, they will, no matter what you do.

It isn't the price of the tool that bugs me. It is the potential losses from having to replace everything that went out with the script in it.

Oh I guess that is why we need to leave the stuff mod so customers can delete the memory using scripts rofl. ok.

I suspect — and I will be happy to be proved wrong — that stages 1 to 8 are about using llSetRemoteScriptAccessPin so that the end user can send running, self-deleting, scripts through the linkset with llRemoteLoadScriptPin when they're actually trying to resize it.

Which is all very well, but means it would take end users 3 seconds per prim, or 12 minutes, 45 seconds to resize a 255 prim object.

The best way to do this, to my mind, if you've got to use resizer scripts, is to supply the objects to customers with a script in each prim that you can delete when you've finished (or that deletes itself after the object's been rezzed for an hour or so).

Customers can always rez a new copy of the object if they to resize it again, or, if it's no copy, you can leave a resizer in the root prim and have them propagate using the steps outlined in the article.

The other real issue with resizer scripts is that people who don't know any better compile the damn things in mono, thus causing the problems outlined in jira issues SVC-4196 and SVC-3895 (basically freezing the whole sim for 30 seconds or so).

Whoever makes an open source low memory low script time one script resizer wins. Someone will. Just a matter of time.

One thing that is a very common misconception is that scripts create lag. They do take CPU time, however that time is at the lowest priority. This means when the sim is lagging (due to avatar load which is what really causes lag) then scripts will simply take a back seat and not run.

Don't get me wrong, I am all for this. The other items with resizers will kill a sims ability to effectively load important scripts and they will seriously slow down teleports.

The real issue at stake is slow resize time with 1 script running vs fast time with a bunch running and HERES THE IMPORTANT PART the ability to delete those scripts once you are done resizing. I choose fast with delete. No scripts is always best.