Scripting Bugs

Using llRezObjectWithParams with REZ_POS and the Relative parameter set TRUE results in the Rezzee being placed relative to the rezzer in the region reference frame rather than in the the rezzer's local reference frame.

default { state_entry() { string json_array = llList2Json(JSON_ARRAY, ["\"", "]"]); string json_object = llList2Json(JSON_OBJECT,[ "string", "Hello, world!", "json_array", json_array, "double quote", "\"" ]); llSay(0, json_object); string extracted_string = llJsonGetValue(json_object, ["string"]); string extracted_array = llJsonGetValue(json_object, ["json_array"]); llSay(0, "extracted_string:" + extracted_string); // Says "Hello, world!" llSay(0, "extracted_array:" + extracted_array); // Empty string? } } There seems to be an issue with the way llJsonGetValue extracts json arrays. This minimal repro script gives an empty string for the extracted array, instead of the given array. Note that the created json object seems fine, it just can't extract from it.

There's an issue with llSitOnLink that can cause an object to enter an unrecoverable state that has been plaguing my region on and off for a good while. An avatar can become 'ghosted' to the sit target, and further calls to llSitOnLink fail. Resetting the script will not work. key agent_sitting = llAvatarOnSitTarget(); llOwnerSay("Agent: " + agent_sitting); Will return a valid key of an avatar that is no longer in the region. This ghost agent will prevent calls to llSitOnLink from working forever more because the object thinks someone is already sitting on it. I am not sure what set of conditions result in the ghost agent. But perhaps llSitOnLink could be internally modified to sanity check that the agent key registered to the sit target is one that is currently in the region the object is in, and remove the key if the agent isn't in the region? I have not found any workarounds to fix this issue. It only goes away after a region restart, which can make it very annoying in the mean time when your sim relies on this functionality for teleporters etc.

A script that has 3 calls to llSetText goes from taking 5 seconds to fully execute to idle without llSetText to taking 8-9 seconds. The wiki says this is rendering overhead but this shouldn't be the case in 2025 and if its render overhead it shouldn't effect script execution times

If a PBR material is set by editing the object & manually selecting a texture per slot, OR set via PRIM_GLTF_BASE_COLOR or other GLTF Overrides, anyone can read the UUID using llGetPrimitiveParams even if they do not have full permissions on the object. This severely limits ones ability to utilize the GLTF features w/o needing an entire material set. It becomes a security risk if you want to customize an individual material via script without changing all other materials. EDIT - If you "edit PBR material" on a non-full perm object & open any of the textures as if you were going to change them (it obviously does not exist in your inventory), and simply hit "OK", you can then read that textures UUID from llGetPrimitiveParams as well.

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.

Bare bones repro script: default { state_entry() { if (TRUE) { @blah; } @blah; } } Does not repro with LSO compiles. I ran into this with a much larger script and had to delete scopes to find it. It would help if this script bug would cause a syntax error message and location to appear in the compile status window instead. It feels like I've seen this reported before, but I cannot find the bug report. Please link the issue if it already exists. Thanks.

So in a previous feedback it was outlined that camera decoupled requires the steer or bank flags as well to work ( https://feedback.secondlife.com/scripting-bugs/p/llsetvehicleflags-vehicle-flag-camera-decoupled-does-not-work ) It was also mentioned that camera decoupled is sent in an object update message to the client. However there is a bug that llSetVehicleFlags does not trigger a full object update message. So, if you have an efficient script that minimises what it needs to set without triggering an object update and the client still thinks the object doesn't have camera decoupling enabled then the camera decoupling doesn't work! The current hacky workaround is to use something that can force a full update, such as setting hover text. The real issue is that setting or removing the camera decoupling flag should trigger the relevant network update to pass the information to the client. I was frequently reproducing this issue on a vehicle I was working on trying to figure out what the issue was but it became reproducible once I knew the trick was related to triggering a full object update.

LSL doesn't seem able to read avatars' rotations with any degree of accuracy unless they're seated or in mouselook. Allowing scripts to read avatars' rotations under all circumstances would make it possible accurately to rez objects using the avatar's frame of rotational reference and to track their direction of travel. It would also make llCastRay useful in many more circumstances.

vector v = (vector)"<1, 1, 1>"; llOwnerSay((string)v); RESULT: <1.00000, 1.00000, 1.00000> vector v = (vector)"<1 , 1 , 1>"; // note the extra space llOwnerSay((string)v); RESULT: <0.00000, 0.00000, 0.00000> EXPECT: <1.00000, 1.00000, 1.00000> NOTE: Similar results with " <1, 2, 3>" (leading space); however, "<1, 2, 3> " (trailing space), "< 1, 2, 3>" and "<1, 2, 3 >" work as expected. Same thing happens typecasting rotations with whitespace before a comma. I can't think of any reason that whitespace character would be significant and invalidate conversion of the initial string to a vector or rotation. One would think the typecast would be fairly liberal about accepting text representations of vectors and rotations.