Script Request ' Texture change based on day and time "

[Zeaig Zabelin]

I honestly am not sure how complicated a script this seemingly simple is actually to do in practice, Nor do i know if its even something that can be reliably done without some technical issues or bugs. But if anyone thinks they can possibly help me with this it would be appreciated.

 

I am trying to make a script that will change a texture via UUID on a specific date and time and then change back to another texture when the said time is over so for example.

 

On Monday, at 730pm SL time it will change to texture 1 and at 9pm SLT it will change the texture, to texture 2 and stay as texture 2 until next monday and the whole process repeats indefinitely.

 

How complicated is something like this, If its not and anyone would be willing to assist me i would be eternally greatful.

 

[Xiija]

check Ferd's and the LSL wiki for stuff?

 

http://www.outworldz.com/cgi/freescripts.plx?ID=895

[Rhonda Huntress]

Just taking a quick stab at it in psudocode.

( llGetUnixTime() DIV 86400) MOD 7

Monday = 4
Tuesday = 5Wednesday = 6
Thursday = 0
Friday = 1
Saturday = 2
Sunday = 3

// You can then use llGetWallClock to check the time of day in SLT

If (Monday AND (llWallClockTime () >  2700) )
  SetMondayTexture()Else SetNotMondayTexture()

Set a timer to check every 15 to 30 minutes or so.  You can add in a variable to keep track of which texture is up and only run the apply texture function if it is not already set to what it needs to be.

 

 

[Madelaine McMasters]

Hi Zeaig,

This isn't a difficult script. You'll need a way to tell which day of the week it is, and what time of the day.

Googling "lsl day of week" returns this link...

http://wiki.secondlife.com/wiki/Day_of_the_Week

You'll want the function version, which returns a string you can test against "Monday".

For the time of day, you'll want llGetWallClock(), which is described here and returns the number of seconds since midnight SLT...

http://wiki.secondlife.com/wiki/LlGetWallclock

7:30PM SLT is 12+7.5 hours into the day
9PM SLT is 12+9 hours into the day

There are 3600 seconds in an hour (60sec/min * 60min/hr), so you can compute the wall clock value for both of those times and check to see that llGetWallClock() returns a number between those two values. If it does, then you want to display UUID1, otherwise you want to display UUID2.

You will need a way to make your script check the clock every so often. You can do that either by using a loop inside of which you put all your code, followed by llSleep() for a minute or more (depending on how promptly after 7:30 and 9:00 you want the texture change to occur. Or, you could put your code inside a timer event that's set to fire every minute or more.

[Rolig Loon]

One way to do it would be to use llGetUnixTime.  Determine the UNIX time of one particular Monday at 7:30 PM SLT and then make periodic checks to see what time "now" is, relative to that date/time. So, for example, last Monday at 7:30 PM SLT, the UNIX time was 1471865400.  There are 86,400 seconds in a day and 604,800 seconds in a week.  Therefore, if you want to do something at exactly 7:30 SLT every Monday evening, run a timer that triggers every 5 seconds and check:

 

timer(){    if ( (llGetUnixTime() - 1471865400)%604800 <= 10)    {        llSay(0,"It was 7:30 Monday evening within the past 10 seconds. Does anyone care?");    }}

It never pays to look for the exact time, but the world won't collapse if you miss by 10 seconds.  Once you know what time it is, trigger whatever is supposed to happen at that time.

[wherorangi]

not sure what is the max. period a lsl timer can be set for. I dunno bc I have never tested it

if it can be set to a long period like a week or more then can/could make a alarm clock based on unix time

something like:

 

// alarms in seconds since Thu 0:00 unix time. Add more/less alarms as you like//             Mon 7:30pm, Mon 9:00pm  list alarms = [    329400,     334800];// some textures. 1 for each alarm timelist textures = [    "name or key of texture 1",    "name or key of texture 2"];integer alarm;  // index into alarms list (and textures in this example)SetAlarm(integer a){    llSetTimerEvent( (float)         ( ( llList2Integer(alarms, a) +          604800 - ( llGetUnixTime() % 604800 ) ) % 604800 )     );}    default{    state_entry()    {        SetAlarm(0);    }    timer()    {        llSetTimerEvent(0.0); // stop timer while we do stuff        llSetTexture(llList2String(textures, alarm), ALL_SIDES);        // set the next alarm        alarm = (++alarm) % 2; // 2 is the length of alarms list        SetAlarm(alarm);    }}

 

[Madelaine McMasters]

I like the idea of setting the timer to fire at 7:30 and 9PM on Monday, but the script needs a way to align itself to real time at startup and if/when something upsets it. There were quite a few times I logged in to my old skybox to find my fireplace script running, but in a state that should have been impossible. It had all the earmarks of an uninitialized variable, but there were none of those in the script.

Your script has two opportunities per week to re-align the timer. That may be enough, but if it's not, you could add a sensor to call SetAlarm() every hour or two or ten.

[wherorangi]

yes. some good points you have made

+

I just use unix time for the alarms, as example. If Mon 7:30pm is another time, like PST or Greenwich or whichever, then the corresponding unix time for the alarms can be pre-calculated and put in the alarms list. The SetAlarm function should not need to be recoded. Should work as is

+

like you say tho the zillion dollars question is how well the LSL runtime server clock and/or API which services the timer event is calibrated with real time

i would assume that the runtime server clock is keeping real time, and also assume that dependencies like the timer event and llGetUnixTime() are also running off this same server real time clock

for sure the timer event can fire at approx. min. interval 1/45th of a second. Theoretically it can fire at a rate of upto 1/90th of a second. 2 times per frame. (I read once where Some Linden wrote that). And also the min. interval can be longer than 1/45th of a second when the server is under stress

however I think that when (or if) everything on the server is running off the same real time clock, then the timer event when fired shouldnt be out time-wise by more than 1 interval of current duration ?

maybe. dunno. exactly

+

defo tho I think running a check sensor is a good idea. Something like say, starting the sensor 5 or so minutes before the next alarm time, and checking after the alarm time to see if the alarm did go off

 

[Madelaine McMasters]

I just had to force a hard reset on Mom's iPad. Apparently, it had got into some state where it thought the screen backlight was on, when it wasn't. It was clearly still alive, responding to Siri requests upon pressing the Home button, but the usual method of restarting requires swiping a switch icon across the screen.

I found the magic two-key (no need for the screen) combo to force a restart and everything was fine. The glitch exposed a condition that I try to avoid when possible in my own designs. And that's the case where the system can become unaware of the state that it's in. If I were the iPad designer, I'd make sure there's no way for the backlight to be off if I think it should be on, even if that means turning it on once per second.

This is the sort of problem I was trying to avoid by running the script logic in a timer that fires every few minutes. I have seen scripts end up in states that are impossible. I don't know the cause, perhaps a glitch in the script interpreter... who knows. I theorize that the likelihood of a script running error free for one week is less than for one minute, but the likelyhood of the server clock being wrong (all else working) for one week is less than being wrong for one minute. So, I favor tying the script logic back to the server clock, rather than a timer event driven by the server clock.

Obviously there are countless ways for things to go wrong that I can't or won't anticipate. There's more than one way to skin a cat... if it's a cat.

;-).

ETA: Error handling can easily be half a project's effort. At the end of every one of my projects, I was both amused and worn out by the fact that the failure modes and effects analysis (FMEA) was 10x or more longer than the functional spec. There may be more than one way to do a thing right, but there's an infinite number of ways to do it wrong.

[Rolig Loon]

---

Madelaine McMasters wrote: [ .. ] There may be more than one way to do a thing right, but there's an infinite number of ways to do it wrong.

---

/me rushes off to stencil that on her office door.  Well, if she had a door.  Or an office. 

[wherorangi]

i like when people ask these kinda questions. They raise all kinda other questions for us to have to think about

as you mention, stuff to think about like:

1) how do we check on startup the calibration of the server clock ?

probably the safest way to do this is to check it against another clock running independently on a different server over which we have more control. Like our own http time service for example

and also while the LSL app is running then also do periodic calibration checks against our http time service

2) what do we do if an alarm doesnt go off at all (the timer doesnt fire). How can we know that ?

i think that the safest solution would again be a independent http time service

+

a way to do this without an external time service is like you say, to fire the timer more frequently checking the time given us by the lsl server against the LSL app alarm time

however this doesnt actually solve problem 2. What do we do if the timer doesnt fire at all ? And how can we know this for sure ?

it can ameliorate the issue tho. Keep requesting the timer event at short(er) intervals and trust that one of our requests will actually fire, as close to the alarm time as is possible

and like you say using a sensor to monitor the timer alarm. Is not a perfect solution this, bc I think that if the timer is not firing (or is only firing sporadically) then a sensor in the same script would most likely be affected similarly

it maybe even that the alarm monitor could run in a separate lsl script and polls the alarm script. Yet with this then both scripts are dependent on the same server. So maybe better possibly, but not perfect either

+

like you and Rolig mention. For every solution looking for a problem to solve, theres a empty space just waiting to be scribbled on

i like scribbling. Is fun (:

[Rolig Loon]

All of this , of course, is why I suggested simply starting the clock from a known time and then checking in from time to time to find out how long it's been since that known starting point.  I'm basically lazy and I prefer solutions that call for the least magic that will get the job done.  

We know the UNIX time at 7:30 p.m. SLT Monday, August 22nd exactly.  So, keep a timer running and check as often as you like to see whether the 86400 seconds (1 day) have passed.  If you want higher precision, check once a second or even more often.  If you want to save on timer cycles, trigger the system slowly at first (once every hour or two if you really must) and then more frequently as you get closer to when the alarm ought to go off.  One thing you can be sure of is that UNIX time will keep ticking away at the same constant rate, independent of how fast your timer ticks.  Your script just has to be watching around the time when UNIX time is a day later than your starting time.

[wherorangi]

yes I agree with your thought processes Rolig

I think that we do have to trust the LSL server to do its job. It can get really murky when we dont. Things can get way over-complicated really quickly when we go all murky on ourselves

[Madelaine McMasters]

We trust the servers because if they're not working, someone will notice. That's not true for scripts like this until it's too late. That's why I'd tie the script back to the clock periodically. The whole thing could still lock up because of a script interpreter glitch, but there's only so much one can do.

[Madelaine McMasters]

---

wherorangi wrote:

yes I agree with your thought processes Rolig

I think that we do have to trust the LSL server to do its job. It can get really murky when we dont. Things can get way over-complicated really quickly when we go all murky on ourselves

---

Yeah, but when things get murky, we have to feel our way around, and that can be great fun.

;-).

[Rolig Loon]

It's not really a matter of trusting the servers.  We're trusting time.  Imagine the way that we would solve exactly the same problem without any computer at all.

I know that I have to be ready for an important visitor at 9:00.  I have a clock on the wall that I know is always ticking along at a constant rate.  I can sit there staring at the clock 100% of the time if I am truly obsessive, but it's a lot smarter if I only check carefully as it gets closer and closer to 9:00.  I take a peek every time I walk by and then, finally, about 8:45, I really do stand there staring at the clock like a little kid.  ("Is it time yet?...  Is it time yet?")  

My point is that it doesn't make any difference whether I trust my own watching ability. Even if I fall asleep or have a senior moment and zone out, the clock on the wall will keep on ticking.  When I do look at it and realize that --"OMG!  It's 9:05!" -- it's after 9:00, I still know when 9:00 was, within the precision of my own glances at the clock.  

UNIX time is the independent clock on the wall. It's ticking, whether we look at it or not. Our own failure to look at the clock, or the server's failure to keep our scripts running, won't affect UNIX time. When the servers do finally wake up and our scripts kick in, we can still always trust that we'll know whether it's before or after 9:00. 

[Madelaine McMasters]

I think I was saying what you're saying. If the server is down, who cares if script's aren't running. Nobody's there to notice. If the servers are running and they've messed up the clock, a lot of stuff is going to run weird and somebody should notice. If the clock is running fine and this script we're imagining is borked, nobody will notice until late Monday, if at all.

There are probably endless ways a script can stop functioning, but I'm thinking the most common kinds of problems are stalls and event queue overflows. If you script this thing such that there are only two timer events per week (7:30 and 9:00) then losing even one really messes things up. And if neither of the events ever references the server clock, losing one event messes up the script forever.

So, check the clock periodically.

[Rolig Loon]

Yup.  :smileywink:

[wherorangi]

---

Madelaine McMasters wrote:

Yeah, but when things get murky, we have to feel our way around, and that can be great fun.

;-).

---

my next murky. I has another one. jejejje (:

suppose we slept the script until 7:29pm next Monday. I wonder if it would wake up before 7:30 ?