How to make a selective tweaks to Mainland settings?

[Qie Niangao]

I thought I understood this stuff, but I've hit a wall of confusion that I can't seem to get past, no matter how hard I try.

The objective is to change just one sky altitude range of a Mainland parcel, and in particular I want to not change the day cycle from that of the region environment, such that the sun, moon, clouds, and all that jazz are still moving through the exact same paths at the exact same times, so when I step/fly outside the tweaked environment it only needs to undo those tweaks instead of the sun sweeping around the sky.

It's a little tricky and time-consuming to detect failure because an attempted tweak may appear to be working until the day cycle advances to a part where there's a difference. Eventually, though, everything I've tried has ended up failing somewhere in the cycle, with sun position somehow drifting enough that shadows move when crossing in and out of the environment.

I couldn't get this to work before recent changes either, but I think things have gotten worse in the most recent Linden and (brand new) Firestorm viewers. Now it won't let me even try to save the region environment day cycle to Inventory, nor apply it to the parcel* whereas I think that used to do something. It still does something on Catznip, although it doesn't seem to be the actual region environment that's saved or applied, instead concocting "3 hr day / 1 hr night #4" as the day cycle name for a cycle with keyframes at:

• 0% (0:0)
• 5% (0:14)
• 12% (0:28)
• 30% (1:13)
• 50% (2:0)
• 69% (2:45)
• 88% (3:30), and
• 94% (3:45)

That's in contrast to the evenly-spaced, every 30 minute keyframe rhythm of the Library "Default" day cycle. But neither day cycle seems to quite correspond to the Mainland region environment. So... how is this supposed to work? Is there somewhere to obtain the true region environment day cycle used on Mainland? (and any possibly different sub-continents such as Horizons?)

[ETA: So I tried to just create a new Inventory day cycle asset; in the Linden viewer I got one with similar keyframe schedule, but at 6 instead of 5% and at 31 instead of 30%; in the Firestorm viewer at first I got a blank day cycle and it let me Clone a track from "Ground"—I guess ground of the region environment? not sure—and now it seems to be populating new inventory day cycles the same as the Linden viewer, so I'm not sure how I ever got that blank new day cycle in inventory at first. I can't figure out what to even try now.]

____________________
*Linden viewer 6.4.21.561414 and Firestorm 6.4.21 (64531) using Customize from region environment show no keyframes at all, and trying to save or apply say: "We have encountered an issue with these settings. They can not be saved or applied at this time."  

Edited July 29, 2021 by Qie Niangao

[Qie Niangao]

A couple depressingly minor updates:

It appears that the new-from-scratch day cycles are actually the same in Catznip and the other viewers, with the different reported keyframe percentages merely a rounding discrepancy. And somehow Catznip uses that "new-from-scratch" day cycle when I try to Customize after applying the "region environment" to the parcel, but the Linden and Firestorm viewers do… something that seems to confuse the viewers as much as it confuses me.

But now I realize that the "new from scratch" day cycle differs from the "region environment" in more ways than only the keyframe schedule, including dramatically different SKY_AMBIENT settings. In fact for all I know it may actually use a matching keyframe schedule, I haven't gotten that far in testing, and that's where this gets depressing:

Out of desperation, I've started doing a whole lot of llGetEnvironment() calls to find out as much as possible about what that Mainland "region environment" really contains. This tedious exercise is ultimately doomed because a number of crucial environment settings are not exposed to LSL. I can see not exposing all the texture UUIDs, and perhaps the idea is to protect the "IP" of these Environment assets, but the explanation given for not doing it is: "We do not want to support legacy environmental settings once EEP becomes main stream." Huh?

Thing is, we're a couple of years into EEP now. Can it really still be unknown what all the region environment settings are on all of Governor Linden's estate regions? Should I file a support ticket? Try to re-open @Lucia Nightfire's jira? File a new feature request jira? Or is this all ancient history at this point, answered by known Library assets, as I supposed when I started this thread?

Edited July 31, 2021 by Qie Niangao

[Qie Niangao]

Still grasping at straws, but they're more slippery than I could have imagined.

First, I'm not sure if the current Mainland environment is what we should expect to be the future Mainland environment, inasmuch as the current one is apparently significantly dimmer than it was supposed to be. If I use a tweaked version of the current environment and then Mainland got a shiny new environment, I'll again have a discontinuity where my parcel borders the Gov's. That makes me even more eager to be able to read all the details of the current region environment settings…

… except that's the second slippery straw: I thought I'd at least figure out where the keyframes are in the region environment by finding inflection points in settings (e.g. SKY_AMBIENT) over the course of a daycycle. To make a start, I took whatever I got from the "new from scratch" thing (which we know isn't the true region environment, but may or may not reflect its keyframe schedule), and added a keyframe with a red SKY_AMBIENT. Then I watched what llGetEnvironment() reported for SKY_AMBIENT as the daycycle passed across the interval.

As I expected, llGetEnvironment() reports a smoothed value in the interval between keyframes. That's already challenging because we'd need to study that "smoothing" in search of the interpolation curve (probably not linear). But a surprise: the values reported by llGetEnvironment() don't seem at all close to what the viewer shows. My red sky experiment appeared in the viewer as I'd expect: reddest at the keyframe, then gradually shifting to the next value at the next keyframe. In contrast, llGetEnvironment() reported peak redness near the center of the interval between keyframes. (Not at the center, of course; that wouldn't be perverse enough; maybe splining across multiple keyframes or something.)

So now I'm not sure what the point of llGetEnvironment() even is, if its reported values aren't relevant to what's in the viewer, and instead reflects some unknown interpretation of what's specified in the environment daycycle. I suppose there's a bug I should report here, but it's gonna be a time-consuming mess to replicate and… I mean, is anybody even using llGetEnvironment() ???