Scripting Bugs

This is an elusive bug because it doesn't happen with the default 4-hour day length, but it can be reproduced consistently with any other day length. If you put this script into an object: default { state_entry() { llSetTimerEvent(1); } timer() { integer daylength = llGetDayLength(); llOwnerSay((string)daylength); } } (timer event can be more than 1 second if you want it less spammy) 1: Make sure the parcel's day length, as shown in About Land > Environment, is the default 4 hours. 2: Wear the object while standing, you will see that the reported day length will be correct, as shown in About Land > Environment. (14400 seconds = 4 hours) 3: Then sit on an object. The script will still report the correct day length. 4: Change the parcel's day length to any other value while you're still sitting. 5: The script keeps reporting the 4-hour day length. 6: Stand up and the script will report the correct day length, as shown in About Land > Environment. This means for some reason llGetDayLength() keeps reporting the default 4-hour day length when the avatar wearing the script is sitting on an object, no matter what the parcel's day length is set to. I know there is a newer llGetEnvironment() function that can retrieve parcel day length, I tested it and it does not have this issue. However I believe it is less costly to run llGetDayLength() and llGetTimeOfDay() separately every second in a watch than calling llGetEnvironment() and then retrieving the time of day and day length values from the list, so it would be crucial for this function to work correctly under all circumstances.

Rez a box, place this script inside of it: default { state_entry() { llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { list env = llGetEnvironment(llGetPos(),[SKY_LIGHT,SKY_SUN,SKY_MOON]); vector spDir = llGetSunDirection(); vector rpDir = llGetRegionSunDirection(); vector envDir = llList2Vector(env,0); quaternion rot; rot = llRotBetween(llRot2Up(ZERO_ROTATION),envDir); //rot = llAxisAngle2Rot(<0,1,0>,90 DEG_TO_RAD) llGetSunRotation(); llSetRot(rot); llSay(0, "sunDir: " + (string)spDir + "\nenvDir: " + (string)envDir + "\nrpSunDir: " + (string)rpDir); } } Click the box. Observe that the prim will rotate towards the celestial body, however it does not point directly towards the body, with varying error levels.

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.

Exiting an llVolumeDetect object by teleporting to a landmark fails to generate a collision_end event and prevent collision_start events on re-entry by teleport or even walking into the object. Exiting by sitting on an external target fails to generate the collision_end but does not prevent re-entry from generating collision_start events. Exiting the volume by teleporting to a map target (or SLURL) generates the collision_end as expected.

llAdjustSoundVolume (and llLinkAdjustSoundVolume) silently fails to adjust volume to 0 if the volume of a given llPlaySound has not already been adjusted to another number first. This seems to only affect llPlaySound, and llLoopSound seems to work if set to 0 immediately. As a workaround, using llAdjustSoundVolume on the intended volume directly after llPlaySound is called functions to later allow the volume to be set to 0.

I have a gadget showing SL daytime and description of cycle within the day (morning, afternoon etc). Noticed that whilst I was sitting down (tried AVsitter and nPose scripted furniture), it suddenly ran 30 minutes fast at this location: Second Life Release 7.1.12.13550888671 (64bit) You are at 146.4, 145.0, 34.4 in Darkover located at simhost-090715bfd81f9bf4e.agni SLURL: http://maps.secondlife.com/secondlife/Darkover/146/145/34 (global coordinates 257,426.0, 230,289.0, 34.4) Second Life Server 2025-03-14.13862207703 but not at this location: Second Life Release 7.1.12.13550888671 (64bit) Release Notes You are at 107.9, 124.2, 1,001.0 in Moonbow located at simhost-0baa562fa277f8a2d.agni SLURL: http://maps.secondlife.com/secondlife/Moonbow/108/124/1001 (global coordinates 180,076.0, 287,356.0, 1,001.0) Second Life Server 2025-03-14.13862207703 Release Notes It reverts to the correct time on "unsitting". Same result with Genesis viewer (latest release version) AND the current SL viewer.

Detecting a texture change is sometimes crucial for a scripted object, for example when a script needs to re-assert it's texture for a status display, or just to 'fix' changes. If a script in another prim in the linkset, or a another script in the same prim triggered a texture change, it can be downright useful for a secondary script to be able to detect that change, if only to 'act in unison' with that texture change. I ran into this issue while working on a modding project, where I don't have access to modify the original script. I have a scripted object that operates by changing the texture of a "TV screen", and running animated textures on the face of it. It also sets a PRIM_POINT_LIGHT on that prim. I'd like to disable that light, but there is no way to detect when a light is being enabled. We are supposed to have a way to detect changed textures, but this function seems to be broken for detecting scripted texture changes dating back to at least the Jira, and SVC-914. http://jira.secondlife.com/browse/SVC-914 The unfortunate alternative is that I must now run a timer, constantly checking for the presence of a light on the child prim, in order to disable it when present. Creating additional overhead that could have been avoided if there was a way to simply trigger on the event of the texture being changed by the other script, or the light turning on/off.

## Minimal Repro Create an object to act as the rezzer. Put an object named 'object' inside the rezzer. In the rezzer, place this script. default { touch_start(integer total_number) { key rezzed_object = llRezObjectWithParams("object", []); llOwnerSay(rezzed_object); } } Place the rezzer in a parcel where build rights is set group only. Be in the rez group but don't have the group active. Make sure the object has no group set. Touch the rezzer. ## Expected Behaviour The documentation states: On failure, returns (key)"" (in LSL), or NULL_KEY (in Lua). So, I would expect to get an empty string or NULL_KEY. ## Actual Behaviour I get a valid key like cfba8a35-1982-6941-f28a-2f53ebac8e8c But no object rezzes, and I get an error in my console like ` Can't rez object 'object' at { ... } on parcel 'Somewhere' in region ... because the owner of this land does not allow it. Use the land tool to see land ownership. `

When actively updating PRIM_OMEGA (like the wheels of a car) crossing into another sim causes them to not behave as intended and start stuttering or twitching their rotation instead of smoothly rotating. This is the same issue as outlined in BUG-232844 from the old Jira with the exact same steps to reproduce, it has returned.

I was part of some RP sim a while ago and left but was still getting notifications from them. So I blocked the object. Only to realize months later it was still sending me emails and possibly affecting my offline message cap. I am not entirely sure, but maybe someone can take a quick look?