7 Day Trial

Is there a reason you don't see many scripted objects offered on a limited time trial basis? Is there a security issue?

For example if I were to write a script that would self delete 7 days after activation and also have it die after a particular date (say 1st of the month) should it be reset by some unscrupulous person. (This would require monthly updates of the scripted object that you are offering of course.) Is this as foolproof as it sounds? Is there a better method?

Hm.. Probably want to have the default state_entry check to see if llGetOwnerKey equals llGetInventoryCreator (llGetScriptName()) and do a llDie or something else to keep people from resetting it. Also, check the changed event for CHANGED_OWNER to detect when somebody first rezzes the object and on_rez/timer for when it's re-rezzed or just to periodically check how long they've had it. No-transfer or remembering if the previous owner is the creator is probably a good idea, too - have to watch for alts passing it back & forth..

The only real hole in this that I see is that somebody could rez it and just delete the script. If the object sans scripts isn't useful/cool, that's probably not an issue, though.

edit: and I'd avoid basing the date on things like the 1st of the month - too much hassle every time somebody's grabs one on the 31st.. Thinking about how to keep people from just grabbing a new copy every week is probably good too; maybe charge 10% or so of the 'real' objects cost for the trial object. You could also probably work out a way to upgrade from the demo to the real one at a discount so people who get the demo don't have to pay extra..

That's the big thing. I have given and sold time-limited trial versions but the trick is making sure only one trial is used until much later (you don't want to stop someone trying it again 3 months later when they've decided to take another look) and making sure there's an easy update path to the unrestricted version. Then again, most scripts are sufficiently cheap that it just isn't worth the effort of adding in the restriction/de-restriction code, along with the overhead it adds to processing/memory depending on how you implement it.