Scripting Bugs

This is a super old bug that I want to bring back to light, I could not find a canny on this. This bug alone, is responsible for several vehicle woes, often requiring vehicles to be re-rezzed. Old archived posts referencing this issue: https://forums-archive.secondlife.com/54/11/317331/1.html https://github.com/secondlife/jira-archive/issues/8363 Summary: In short, when an agent crashes and disconnects uncleanly, the sit target remains occupied. Other viewers will still show the (now gone) avatar on the seat, scripts who call llAvatarOnSitTarget or related functions will be told that the sit target is occupied by the avatar who got disconnected. What makes this particularly evil for scripts? This stale state survives script resets, since it's a simulator state issue. The stale sit target survives sim crossings Even worse, you can unlink and relink the link with the sit target, and the simulator will still report that the disconnected avatar is sitting on that sit target once you relink. If the disconnected avatar relogs to a different region, and teleports back to the region the vehicle is in, when they resit, the avatar will now occupy two sit targets. Side note: If a linden wants help reproducing this bug, I'm happy to help. It can be reproduced easily if we stress test and try to crash on purpose; by having a multi-avatar vehicle with several avatars running several scripts.. we can make ourselves crash onto sim corners.

Reproduction steps: Rezz a box Put this script into it: integer AlphaState = 1; default { state_entry() { llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_RENDER_MATERIAL, ALL_SIDES, "2d45cf07-04ac-64a1-daa7-83f4992f759b"]); } touch_end(integer num_detected) { list faceData = llGetLinkPrimitiveParams(0, [PRIM_GLTF_BASE_COLOR, 0]); llOwnerSay("Colour Received: \"" + llList2String(faceData, 4) + "\""); if (AlphaState == 1) { faceData = llListReplaceList(faceData, [0.0, PRIM_GLTF_ALPHA_MODE_BLEND], 5, 6); AlphaState = 0; } else { faceData = llListReplaceList(faceData, [1.0], 5, 5); AlphaState = 1; } llSetLinkPrimitiveParamsFast(0, [PRIM_GLTF_BASE_COLOR, ALL_SIDES] + faceData); } } The script will turn this box golden Touch the box once, observe received colour value being "" and the box vanishing Touch the box again, observe received value being "<1.000000, 1.000000, 1.000000>" and the box being silver Expectation: One of the following should happen: Box should remain gold, and colour value remain "" Colour value should always be <1.0, 0.89, 0.616> and not "" Environment SL Main grid sim with: Second Life Server 2024-01-19.7590161929

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.

SIT_FLAG_NO_COLLIDE (applied with llSetLinkSitFlags()) disables collision shapes on seated avatars but avatar mass is still contributed to the object. This shifts the physical object's center of mass and interferes with the function of particularly small vehicles. Avatar mass contributions should be simply be disabled entirely when SIT_FLAG_NO_COLLIDE is applied to match the behavior of linked objects not contributing to a linkset's mass when PRIM_PHYSICS_SHAPE_TYPE is set to PRIM_PHYSICS_SHAPE_NONE with llSetLinkPrimitiveParams(). Alternatively, a sit flag, e.g. 'SIT_FLAGS_NO_MASS', that disables mass contribution from seated avatars is proposed.

Please see https://i.gyazo.com/9458091243cd7f38b5bd858165a59508.mp4 to see what's happening. The script is put inside a root link that is the swivel bar, the mesh door is the second link in the linkset. The function is called as: llSetKeyframedMotion(lKeyFramesOpening, [ KFM_DATA, KFM_ROTATION, KFM_MODE, KFM_FORWARD ]); Where lKeyFramesOpening is a list generated like so: // Rotation for most keyframes rotation rRotation = llEuler2Rot(<0.0, 0.0, 15.0> * DEG_TO_RAD); // First keyframe lKeyFramesOpening += [ llEuler2Rot(<0.0, 0.0, 15.0> * DEG_TO_RAD), 3.0 ]; // Generating in-between keyframes integer i = 1; for(; i < 5; i++) { lKeyFramesOpening += [ rRotation, i * .2 ]; } // Ending keyframe lKeyFramesOpening += [ llEuler2Rot(<0.0, 0.0, 15.0> * DEG_TO_RAD), 0.6 ]; Object and full script can be sent upon request. See comments in the thread here for more info.

The use cases for detecting reflection probes in llCastRay are very limited. I would argue that a raycast detecting a reflection probe is more than likely unwanted interference the vast majority of the time. Existing creations that use llCastRay were built before reflection probes were a thing are likely to break in subtle ways as users begin to place reflection probes everywhere. I propose adding a new flag, RC_DETECT_PROBES, which defaults to FALSE, only if the creator manually sets this to TRUE shall raycasts pick up probe volumes.

Using the flag REZ_FLAG_NO_COLLIDE_FAMILY with llRezObjectWithParams() causes the first object rezzed not to receive any collision_start events at all no matter how many collisions it has. All subsequent rezzes of the same object do receive collision_start events as expected. This problem seems to be subject to a "caching effect" such that it only happens the first time the object is rezzed on a given sim. It has been difficult to characterize the behavior exactly since it only happens once per sim per some very long time (sim seems to "remember" the object and not have the issue for some number of hours). However, it does seem like the "memory" works across different owners' instances of the same rezzed object, e.g. agent A uses laucher to rez projectile, which exhibits the failure, then agent B uses same launcher the same way and does not experience the issue. I also did not attempt to investigate collision and collision_end events, but I strongly suspect these have the same issue. I have created a minimal example to replicate the issue. You can use these scripts to reproduce it, or contact me in world and I will give you my example object. Launcher script default { touch_start(integer num_detected) { rotation my_rot = llGetRot(); vector rez_pos = llGetPos() + <5.0, 0.0, 0.0> * my_rot; vector velocity = llRot2Fwd(my_rot) * 200.0; list params = [ REZ_FLAGS, REZ_FLAG_TEMP | REZ_FLAG_PHYSICAL | REZ_FLAG_NO_COLLIDE_FAMILY, REZ_LOCK_AXES, <1.0, 1.0, 1.0>, REZ_POS, rez_pos, FALSE, FALSE, REZ_ROT, my_rot, FALSE, REZ_VEL, velocity, FALSE, FALSE ]; llRezObjectWithParams("projectile", params); } } Projectile script default { on_rez(integer param) { llOwnerSay("on_rez param="+(string)param); } collision_start(integer num_detected) { llOwnerSay("Collided with: "+llDetectedName(0)); llSetTimerEvent(4.0); } timer() { llDie(); } } You can see a video of the behavior here: https://gyazo.com/41bf8753ec3d82243109df5db86a8acc Notice in the lower left chat text how the first projectile reports only its on_rez event, then the second one reports on_rez and collision_start. In fact, if you look closely you can see both projectiles bounce back and forth a few times hitting an object out of frame to the left. The first one gets none of the collision_start events while the second gets them all.

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.

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.

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.