Automatic day/night texture change

[Kitty Nakajima]

 I am looking for a script that would change the texture on specific faces of a prim depending on whether it is daytime or night time. It is for a rainbow I have on my land and I would like it to disappear from dusk until dawn so I would need the rainbow texture to change to an alpha texture. Any help will be hugely appreciate

[Rolig Loon]

Any script that you write to toggle an effect on/off at dawn and dusk ultimately depends on knowing where the sun is.  That what the LSL function llGetSunDirection does.  Just put it into a timer event and watch the vector that it produces each time you ask.  Specifically, watch the vector's Z component, which tells you how high in the sky the sun is.  If Z is greater than zero, the sun is UP.  So, there's your trigger:

timer()
{
    vector Sun = llGetSunDirection();
    if (Sun.z >= 0.0 )
    {
        // It's daytime!
    }
    else
    {
        //It's nighttime!
    }
}

In practice, you will almost certainly find that you need a little nuance, because the sky doesn't become instantly black the second that the sun drops below the horizon, but that basic function gives you the idea.

You can take a slightly different approach with recently-introduced functions, llGetRegionDayLength and llGetRegionDayOffset, which are handy because they help take into account any regional adjustments that the owner may have made to the day cycle.  Take a look at the example at http://wiki.secondlife.com/wiki/LlGetRegionDayLength#Examples, which lets you calculate the sun's progress in terms of a percentage of the total day length, where 0.0% is midnight and 0.5% is noon.  You can decide experimentally when the sky is dark enough to call it "night"  or light enough to call it "day".  For me, 22% < daytime < 78%, so I use those two marker percentages as the triggers to toggle lights, particle effects, and whatnot.

That should be enough to get you started on writing your script.  It's a nice beginning project for a new scripter. If you are not confident enough yet, you can find a willing scripter by posting in the InWorld Employment forum.  You'll also find scripts in Marketplace and in various on-line script libraries, or by posting in the Wanted forum.

[animats]

Quote

llGetRegionDayLength

That's region day length. Parcels now get to play with day length, too. (Although it looks awful when they do. You enter a parcel and the sun goes zipping across the sky. Please don't use that feature on small parcels on mainland.)

Does llGetSunDirection pay attention to parcel EEP settings? It should, and the wiki hints that it does. Anyone tried?

By the way, doing this for a rainbow is a great idea. Some things really need to turn on or off with daylight. I've seen a parcel that has "god rays" coming through their trees. It looks great in daylight and really bad at night. (Also, if you make something with glow, check your lower levels of detail. The "god rays" object turns into a huge glowing blob at distance at night. I thought it was a griefing object.)

Edited July 4, 2020 by animats

[Rolig Loon]

3 minutes ago, animats said:

That's region day length.

Yup, it is. And we also have llGetDayLength, which does exactly the same thing at the parcel level.  Not surprisingly, there's an almost identical example in the wiki at http://wiki.secondlife.com/wiki/LlGetDayLength#Examples .  

As you noted, the wiki says, "llGetSunDirection is the vector to the parcel's sun, llGetRegionSunDirection is the vector to region's sun. If there is no custom environment set for the current parcel llGetSunDirection returns the direction to the region's sun."   Its mention of a "custom environment" at the parcel level seems to imply that llGetSunDirection is EEP-aware.  Like you, I hesitate to mess with parcel-level EEP, so I haven't verified it.  It's jarring enough to encounter different settings as you cross region borders.  A patchwork of environments in a single region might be really unsettling. However, I can imagine situations where that's exactly what you might want to do, so it's good to have the flexibility.  

[Rider Linden]

Yes,  All of the sun and moon functions (direction, rotation) and the day length day offset functions are EEP aware. The  llGetRegion* (Sun/Moon)(Rotation/Direction) functions will always return the value for the region even if there is an environment set on the parcel. 

This family of functions are also altitude aware.  This means that if the object containing the script is at 1100 meters and the region or parcel owner has set a custom environment at 1000 meters they will recognized the sun position from the custom environment. 

[Qie Niangao]

A special-case consideration is that EEP also allows Experience scripts to set very cool per-avatar Environment settings (which the viewer regards as the "shared" Environment, even though the settings aren't necessarily shared by other avatars on the parcel or region at the same time). In such cases, the Experience scripts may know the sun position they've set for each agent at any time, but the day/night texture change would be viewed by all the same.

So, unless those per-agent Environments have synchronized sun positions across all agents on the parcel, one may need to choose either per-agent EEP or day/night texture settings.

[Delain Canucci]

Does anyone know if this day and night cycle also works on a particle script ? 

 

[Rolig Loon]

Any script that uses llGetSunDirection can detect whatever the local EEP settings define as day and night.  See also the new functions llGetDayLength and llGetDayOffset and their region equivalents, described in the LSL wiki.

[Oz Linden]

On 7/4/2020 at 9:52 AM, Rolig Loon said:

Any script that you write to toggle an effect on/off at dawn and dusk ultimately depends on knowing where the sun is.  That what the LSL function llGetSunDirection does.  Just put it into a timer event and watch the vector that it produces each time you ask.

... but please don't do that with a timer that fires more often than once every few minutes; it's a waste of the simulator script time to check more frequently than that.