Light On/Light Off Script Help
|
|
Aaron Levy
Medicated Lately?
Join date: 3 Jun 2004
Posts: 2,147
|
08-17-2006 20:12
I'm working on a simple script that turns a prim's light on when its night and off during the day. default {
state_entry() {
llSetPrimitiveParams([PRIM_POINT_LIGHT, FALSE, <1, 1, 1>, 1.0, 10.0, 0.75]);
llSetTimerEvent(5);
}
timer()
{
vector sun = llGetSunDirection();
llWhisper(0,(string)sun.z); //debug whisper
if (sun.z < 0) state night;
}
}
state night
{
state_entry()
{
llWhisper(0,"night");// various things to do when night falls
llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <1, 1, 1>, 1.0, 10.0, 0.75]);
llSetTimerEvent(5);
}
timer()
{
vector sun = llGetSunDirection();
llWhisper(0,(string)sun.z); //debug whisper
if (sun.z > 0) state default;
}
}
I got most of the code from this forum, but I can't figure out why this isn't working, UNLESS it is working, and the sun position doesn't change when you use the World -> Force Sun feature. When I change it to midnight, the sun position whisper (debug whisper in the script) still continues to move slowly and does not reflect the Force Sun settings. Is that the case, and this script actually works? |
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
08-17-2006 21:00
When you force the sun, you do it client-side. The script runs server-side. Only REGIONS that force the sun position might mess with the code that way. So it may be working.
|
|
Joannah Cramer
Registered User
Join date: 12 Apr 2006
Posts: 1,539
|
08-17-2006 21:06
From: Aaron Levy Is that the case, and this script actually works? Yup, and very likely. As side note, since sun position only gets updated every 10 secs or so, i'd drop the frequency of timer accordingly ... just a thought, you never know when the tiny bit of extra free time can be handy for the sim ^^;; |
|
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
|
08-17-2006 22:55
From: Joannah Cramer since sun position only gets updated every 10 secs or so, i'd drop the frequency of timer accordingly i would drop the timer in this case, the script is not accepting any outside data so you can use a llSleep and avoid the event ...
evil_loop()
{
llOwnerSay("do stuff");
llSleep(10);
evil_loop();
}
default
{
state_entry()
{
evil_loop();
}
}
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
08-17-2006 22:58
Oh god! DON'T DO THAT!!!! If you are going to use a busy loop, make it an actual loop. DON'T make endless recursive calls! Stack space is not free, and it definitely isn't unbounded!
It is nicer and probably better for enhancibility to use a timer anyway. Why try to avoid it?
|
|
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
|
08-17-2006 23:04
it pauses the script then does the exact same thing vs making the system activly wait for a timer event
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
08-17-2006 23:06
From: Osgeld Barmy it pauses the script then does the exact same thing vs making the system activly wait for a timer event What do you think the system has to do when you call 'llSleep()'? It has to do the exact same kind of thing. You aren't saving the sim anything. |
|
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
|
08-17-2006 23:13
From: Hewee Zetkin exact same kind of thing. i guess, way i see it, timer events set a timer make the sim deal with it, and then trigger an event, then the functions within the event VS set a timer, let the sim deal with it and run the functions ... no event and it saves a ll function in most cases setting a timer is a valid choice, in the case of a possible great deal of lamps the llSleep seems more economic espeically since there is no user or outside input, its just a cycle getting data |
|
Kayla Stonecutter
Scripting Oncalupen
Join date: 9 Sep 2005
Posts: 224
|
08-17-2006 23:29
From: Osgeld Barmy
evil_loop()
{
llOwnerSay("do stuff");
llSleep(10);
evil_loop();
}
default
{
state_entry()
{
evil_loop();
}
}
The problem I have with that code is the constant recursive calls of the function. You're calling the function from within itself, meaning they never exit and just keep building up, which will lead to a Stack-Heap collision (just tested and confirmed with a simple counter, got just over 2000 before crashing). If you want to use a llSleep(), do it this way: vector Sun;
default
{
state_entry()
{
do{
Sun = llGetSunDirection();
if(Sun.z > 0)
{
llSetPrimitiveParams([PRIM_POINT_LIGHT, FALSE, <1, 1, 1>, 1.0, 10.0, 0.75]);
}
if(Sun.z <= 0)
{
llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <1, 1, 1>, 1.0, 10.0, 0.75]);
}
llSleep(60);
}while(1);
}
} |
|
nand Nerd
Flexi Fanatic
Join date: 4 Oct 2005
Posts: 427
|
08-18-2006 02:11
Only difference I can see between using a llSleep and a timer is if the code you are looping has time penalties (e.g. e-mailing), so if you use a llSleep you'd end up with the sleep time plus the penalties whereas with a timer it should fire at it's interval.
Without knowing the internal workings of LSL it would be difficult to gauge the difference between using a loop with llSleep and using a timer. Anyone got a benchmark process for LSL we can use to compare script time?
_____________________
www.nandnerd.info
http://ordinalmalaprop.com/forum - Ordinal Malaprop's Scripting Forum
|
|
Aaron Levy
Medicated Lately?
Join date: 3 Jun 2004
Posts: 2,147
|
08-18-2006 08:58
From: Joannah Cramer Yup, and very likely.
As side note, since sun position only gets updated every 10 secs or so, i'd drop the frequency of timer accordingly ... just a thought, you never know when the tiny bit of extra free time can be handy for the sim ^^;; Yeah, it's normally set at 600 seconds, I have it set at 10 so I could get debug info quicker and actually watch the numbers of the sun moving. |
