Question on Term Limited Possibilties?

[amarock Amat]

Am curoius on folks thoughts, I am figuring maybe of making some freebie weapons for the setting am in , but would like to limit it for like 30 days use or such, so I don't tank other makers. Is their a way to limit a worn item not to be useable passed a certain date?

[Rolig Loon]

There are many ways to do that.  Most aren't foolproof but unless you are really worried about that, you should be able to write something that will work for you.

One easy way is to use llGetUnixTime in the on_rez event.  Store it someplace safe like the Description field of a small transparent child prim and then run a timer that compares it to llGetUnixTime again periodically.  When 30 days ( = 2592000 seconds) have passed, do llRemoveInventory(llGetScriptName()).  You'll obviously want to code a way to keep the script from overwriting the stored time every time the object is rezzed. Remember to make the script no mod so the new owner can't tamper with it. There's nothing to stop someone from removing the script, of course, but then the weapon is non-functional anyway, which is what you wanted. 

[amarock Amat]

Hmm...should that be scripted as the first stage of the script,or towards the end?

[Rolig Loon]

That's really not a terribly important decision to make.  After all, LSL is event-driven, so the concept of a "beginning" or "end" to a script is muddy at best.  You set the timer going on rez and it just ticks away, regardless of whatever else the script may be doing. Whenever it fires, it checks the lapsed time since it was first rezzed and then goes back to ticking quietly in the background.  Most of your script does whatever it needs for making the weapon work.  The self-destruct part is just like this ....

 

integer gBeginT;default{     on_rez (integer start)    {        llSetTimerEvent(30.0);     //Set timer to sample unix time periodically        gBeginT = (integer) llList2String(llGetLinkPrimitiveParams(12,[PRIM_DESC]),0);    // Look to see if there's a stored value of gBeginT in link #12        if (!gBegin)    // If not, store one.        {            gBeginT = llGetUnixTime();            llSetLinkPrimitiveParamsFast(12,[PRIM_DESC, (string)gBeginT]);        }    }    timer()    {        if ((llGetUnixTime() - gBeginT) >= 2592000)        {            llRemoveInventory(llGetScriptName());        }    }    // Plus the rest of your script that does weapon stuff}

 

 

[Nickel Briand]

You may delete the timer in this case and remove inventory directly inside the on_rez event  ( and maybe too in the attach event )

Indeed , the object of the OP is an attachment or can be useful only when it s attached . 

Of course , after the 30 days , the user could use always his object  until the next rez . ( so , in practice , 30 days and some hours )  But the on_rez event is fired at the login if it s a an attachment . And he couldn t stay logged eternally 

[Rolig Loon]

That's probably true, and not a bad idea in general.  You'd be surprised how many people actually do stay logged in for days on end (not exacly eternally, but a long time).  Whether he checks only on rez or uses a timer event really depends on how picky the OP is about wanting to disable the device after 30 days.  :smileywink:

[Innula Zenovka]

I think what I'd do is use multiple states.

In state_entry() of state default, I'd just check if the owner is the creator of the script.   If not, do something with llSetLinkPrimitiveParamsFast to turn the weapon into some blank cubes and remove the script (this is to stop people cheating and resetting the script to restart the timer).   If the owner is the creator of the script, then move to state next.  

In state next, simply use the changed event to detect a change of owner, set the timer going, and move to state running.

Use state running to do the actual weapons stuff and hold the timer event.   When time runs out, simply return to state default.

I think the way I'd handle the timer, is, when I started the clock running in state next,  set gIntDeadline as llGetUnixTime()+ 2,419,200 (seconds in 28 days, for the sake of simplicity), and set my timer event to go off in 2,419,200 seconds .  

Then, each time the object is attached or rezzed, check llGetUnixTime() again, subtract it from gIntDeadline (to take into account the fact the timer has been stopped while the item's in someone's inventory or it's attached and they're logged out) and, if the deadline hasn't passed, reset the timer event for the new interval.  If it has, then zap the object.