llReplaceEnvironment() changes Day Length and Offset when it shouldn't, and prevents the viewer's About Land / Environment from reporting changed Settings
tracked
Qie Niangao
I'm attaching a long but trivial script that triggers misbehaviors, describing what's wrong at each touch-activated step. What llReplaceEnvironment does wrong to the actual environment settings is to set Day Length to 4.0 and Day Offset to 0.0 despite being called with values of -1, which should retain the values unchanged. More confusing, though, is it leaves the parcel environment in a state that the viewer cannot report the names of the new Settings it has installed.
Note: For convenient test setup, the script uses UUIDs to represent Settings, but it gets the same results using names of those Settings in the object inventory, so whatever is preventing the proper naming of those Settings in the viewer, it happens whether or not a name is supplied in the function call.
Log In
Maestro Linden
updated the status to
tracked
Maestro Linden
I can reproduce this with my own test script when testing in SLS 2026-09-28.36457939353.
- Go to a parcel that you can manage
- Open World -> About Land -> Environment, and set some custom environment on the parcel. Customize the day length and offset values to make things interesting.
I used 26.5 hours day length and 4.5 hours day offset.
- Using an LSL script, query the ENVIRONMENT_DAYINFO parameter at the local parcel position. Per https://wiki.secondlife.com/wiki/LSL_Constants/llGetEnvironment , the values returned are integer day_length, integer day_offset, float secs_since_midnight
Maestro Linden: pos <128,128,23>
Env test: Set vector pos = <128.00000, 128.00000, 23.00000>
Maestro Linden: get ENVIRONMENT_DAYINFO
Env test: llGetEnvironment() returned these values at position <128.00000, 128.00000, 23.00000>:
ENVIRONMENT_DAYINFO, 95400, 16200, 51868.636719
The output here confirms that the day cycle for the parcel is set to a 26.5 hour (95400 seconds) day with an offset of 4.5 hours (16200 seconds). Note that when the viewer shows a negative offset, the value will be 'wrapped around' to a larger positive value.
- Have the test script call llReplaceEnvironment at the parcel location, specifying -1 for the day_length and day_offset parameters, which shouldleave them unchanged.
My particular test script checks each parameter after the operation to see what changed. Since it's a new environment, we expect changes, but day_length and day_offset should
not
change.Maestro Linden: replace <128,128,23> 23636925-73a4-e559-6b73-7471e87c8fb7 -1 -1 -1
Env test: llReplaceEnvironment(<128.000000, 128.000000, 23.000000>, 23636925-73a4-e559-6b73-7471e87c8fb7, -1, -1, -1) returned 'success' = 1
My test script also iterates through all the parameters and notes which ones appear to have changed by the replacement operation. I've excluded the output here for legibility.
- Repeat (3) to see if the day cycle parameters represented in ENVIRONMENT_DAYINFO actually changed. We see a bug - they did change! day_length was reset to 4.0 hours and day_offset was reset to 0.
Maestro Linden: get ENVIRONMENT_DAYINFO
Env test: llGetEnvironment() returned these values at position <128.00000, 128.00000, 23.00000>:
ENVIRONMENT_DAYINFO, 14400, 0, 12950.349609
The viewer UI in World -> About Land -> Environment confirms this unexpected day length and offset change.
Qie Niangao
Maestro Linden Thanks, this is much clearer and more concise than my script, and using output from llGetEnvironment is a lot more precise than staring at the sky and water. I only wish llGetEnvironment got
more
info about the envrionment… including the name of the Settings asset in use on each sky/water track. That's the other problem I was trying to report here: whatever server-side info the viewer uses as a source for the names it displays as the active Setting for each track, it's not being updated by llReplaceEnvironment the way it is when a track is manually replaced by drag-and-drop on that UI. Maybe there's a feature request here, more than a bug, but it is
very
confusing to replace a track's environment and not see it reflected in whatever the viewer is reporting for that track. (At a minimum, somebody who understands what the heck the viewer is
showing needs to help augment the wiki and/or knowledge base so we know how to interpret what we're seeing.)Thanks again