Talk:Region Environment Settings

Please for now restrict discussion to whether or not the feature works as described on this description page, and whether or not the workflow and UI are understandable and usable. Other enhancements, such as being able to exchange settings or support for other features like rain and snow are not in our current project scope, so please just save them for another time or place. Oz Linden 20:15, 2 June 2011 (PDT)

Suggestions

• In the Edit Day Cycle window, the line that reads '- Use the scrubber to preview your day cycle' is not user intuitive. It took me a while to figure out it meant to slide the yellow down arrow left and right to watch the sky change. Please consider something more constructive like 'Slide the arrow above the time line back and forth to preview your day cycle'. This will make it clear and easy to understand by those not part of the dev track who have NO idea what the secret code name for every piece of the screen is (scrubber to me is the script I use to clean prim params and scripting from an object in SL and something I was my dishes with in RL... scrubber, huh-wha?).

Charlene Trudeau 11:07, 3 June 2011 (PDT)

• In the edit day cycle window, I'd like to see a preview option like previous iterations (Stop, play, timescale). this would allow people minimise the edit day cycle window, and preview the cycle as it changes, without anything blocking the view.
• The window itself also it quite large, perhaps rearranging the buttons and such, and moving the help lines "click on a tab..", "Click and drag...", etc to a help button, which could bring up a detailed Help browser window. This could be applied to the other edit windows also.

--Uni Ninetails 16:59, 3 June 2011 (PDT)

Questions

• Should we use color pickers instead of the 4-slider sets for the sky and atmosphere colors? They would consume more screen space, but might be more intuitive, and already support direct entry of numeric color values. We do this for the water preset fog color.

SL day cycle question and discussion

Andrey Plechen wrote:

I have a question about day cycle settings. Wiki page tells that SL day cycle is ~4 real hours. So what is a starting point for SL day cycle? I imagine 12:00 AM of SL day cycle matches to 12:00 AM of the real day cycle and repeats every 4 hours. Can I determine somehow the current time of SL day cycle?

Oz replies:

An outstanding question, and one I've been meaning to ask... I'll get back to you.

I've done some reading in the code.... it looks as though the relationship between real time and time-of-SL-day should be stable; a given real time should always be the same SL time. I don't, however, see anything in the code that makes it easy to tell what that relationship will be.

The server sends the time to the viewer expressed as a 'sun angle' in radians. The same value (in vector form) can be read by scripts using llGetSunDirection. A related value can also be read using llGetTimeOfDay; though the documentation on just what to expect from that is much less clear, it does say: Second Life days cycles are 4 hours long (3 hours of light, 1 hour of dark). The sunrise and sunset time varies slowly.

that variation seems to be an attempt in the code to somehow approximate the seasonal effect of axial tilt. Sometimes I wonder about the people who built this thing.... I think that the easiest way to figure out what the relationship really is is to do some experiments using LSL... I'll do that and see what I find.

Anyway... this does have an implication for us. It turns out that there's a difference between a region set to have a fixed time of day (previously set in the Region/Estate floater Estate tab) and one that just has a fixed sky: the phase control from that dialog causes the two LSL functions above to behave differently. When the region is set to a fixed sun, that causes the llGetSunDirection to always return that fixed value rather than one dependent on the time (it also seems to change llGetTimeOfDay, but in a less clear way). Our current implementation will break that, since we are never setting the fixed sun flag.

There's an awkward disconnect in the old functionality though... the estate time phase on a fixed sun region controlled what llGetSunDirection returned, but that had no relationship to the sun angle in the windlight sky preset selected. It was possible to set the estate phase to one value and then set the apparent position of the sun to something else in the sky preset. If the estate manager did that (under the old controls), the llGetSunDirection would return a value that didn't match what the user saw. I suspect this came about because there used to be just the one control for the region time, but when windlight sky presets were created they added an independent control.

I think the correct solution to reconcile this is for us to change the code so that if the estate manager selects a Fixed Sky in the Region/Estate Environment tab, then we tell the sim that it is a 'fixed sun' region, but instead of having a phase control there, we extract the sun position from the selected sky preset. This will ensure that the llGetSunDirection will return a value that points to the apparent sun in any fixed sky region. In regions set to use a day cycle, the sun position in each selected sky preset will control the apparent position; those will only match what llGetSunDirection returns if the user who created the sky and day cycle presets did so in a way that approximates the underlying SL time of day, but I don't think there's anything we can or should do about that.