Jump to content

Question on Term Limited Possibilties?


amarock Amat
 Share

You are about to reply to a thread that has been inactive for 3509 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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?

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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}

 

 

Link to comment
Share on other sites

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 

Link to comment
Share on other sites

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:

Link to comment
Share on other sites

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.


Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3509 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...