Scripting Bugs

Excessive inventory lags users, regions and all of platform. Many users that are long time residents often have excessive inventories that lag the system down. Culling the old, throwing away something from 10 years ago is an option but why should a user throw any money away? My suggestion: for an annual fee of @$20/year a user can buy an ALT to their account (Example: Monger Lionheart would get Monger Lionheart.alt). Since the same user name the user can transfer to inventory to their ALT. The ALT is a stationary item like a DESK/DRESSER/WARDROBE that they can rez and transfer their inventory to/from? Benefits: Users in SL would be lower in inventory and more efficient for the entire system. Small added FEE would cover additional memory required for Linden Labs BUT a much better user experience for all. Im sure the Number 1 reason people leave is poor performance? Since the ALT account would in essence be a system Folder, the user should be able to move items to/from and make everyone's experience more pleasant. Reasoning: My SL partner (Premium Plus, me also) lives in Australia (massive ping) and also a landscaper in SL with an inventory in excess of 414K items. I am constantly trying to come up with ideas to cull her inventory, update her system (including upgrading her pc and best possible net connection) and any maintenance utilities. BUT after nearly 20 years she is about to leave Second Life as the issues are overwhelming. This suggestion is for the many users in her situation and also a win win for Linden Labs. Thank for your time and I hope this spurs a way to accomplish this task while still keeping inventory non transfer?

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.

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.

Applying damage via rez param causes object to ALWAYS despawn on collision (Okay, so it looks like the text editor ate my entire post.) Applying REZ_PARAM_DAMAGE to an object will force it to immediately despawn regardless of whether or not damage is actually applied to the collision source. This behavior also triggers in non-damage areas and parcels. The following code was used and tested: list rezparams=[ REZ_PARAM,1,//Rez param REZ_FLAGS,REZ_FLAG_DIE_ON_NOENTRY|REZ_FLAG_NO_COLLIDE_OWNER|REZ_FLAG_NO_COLLIDE_FAMILY|REZ_FLAG_PHYSICAL|REZ_FLAG_TEMP,//Flags REZ_POS,llGetCameraPos(),0,1,//Object rez Pos REZ_ROT,llGetCameraRot(),0,//Object Rot on rez REZ_VEL,<150.0,0.0,0.0>,1,0, //Velocity REZ_LOCK_AXES,<1.0,1.0,1.0>,//Axis Locks //REZ_SOUND,sound,1.0,1,//Loop sound REZ_SOUND_COLLIDE,"",1.0//Collision sound //REZ_DAMAGE,200.0,REZ_DAMAGE_TYPE,0//Damage Params ]; llRezObjectWithParams(bullet,rezparams); The project spawned via this method will die without executing any collision event or functions queued after the initial collision regardless of source or location.

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

There is a problem when the encoding is not set correct on a Server I made tests with a simple php file: <?php echo "Hällo Wörld" ?> A HTTPRequest gives me > Hällo Wörld <?php header("content-type: text/plain; charset=utf-8"); echo "Hällo Wörld"; ?> Here the response is correct > Hällo Wörld It seems that when no encoding is set, UTF-8 is not used as default. That's a problem for some translater APIs for example. I don't know if it is possible to set utf-8 as fallback encoding or if a change could produce other issues. Maybe take a look on it

If one person takes a copy of another person's object, the object left in-world loses PERMISSION_DEBIT . I didn't test other permissions Rez an object and insert this script: default { state_entry() { llRequestPermissions(llGetOwner(), PERMISSION_DEBIT); } touch_start(integer count) { llOwnerSay("Permissions: " + (string)llGetPermissionsKey() + ": " + (string)llGetPermissions()); } } Grant debit permission Click to make sure it has permission Sign onto an alt that has object edit permissions On the Alt, right click > Take Copy Click the object still rezzed in world. It no longer has debit permission

According to https://wiki.secondlife.com/wiki/LlSetLinkGLTFOverrides , "Passing an empty string ("") as the override value will clear that override." This is true as far as I have tested except for OVERRIDE_GLTF_BASE_ALPHA, where setting to "" seems to simply do nothing. To Reproduce: Rez a prim, add a PBR material to it, and put the following script into it: default { touch_start(integer total_number) { toggle=!toggle; if(toggle) llSetLinkGLTFOverrides(LINK_THIS,ALL_SIDES,[OVERRIDE_GLTF_BASE_ALPHA_MODE,PRIM_GLTF_ALPHA_MODE_BLEND,OVERRIDE_GLTF_BASE_ALPHA,0]); else llSetLinkGLTFOverrides(LINK_THIS,ALL_SIDES,[OVERRIDE_GLTF_BASE_ALPHA_MODE,"",OVERRIDE_GLTF_BASE_ALPHA,""]); } } You will see that the alpha will set to 0 on the first click, but will not return to its previous value on the second click. The alpha mode WILL revert as intended if you use a PBR material which is not in blend mode, but the prim remains invisible if the material is not opaque. The wiki page provides a toggle alpha on/off function, but this simply toggles the alpha value between 0 and 1 rather than setting and then removing an override. Where the base alpha value of a material is not 1, this will fail as it will set the alpha to 1 rather than the correct value.

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.

If you rez a new prim (like the default cube) and try to call llSetKeyframedMotion on it, you'll get the following error: Error, failed to play animation. Does your linkset exceed the complexity limit for keyframing? This error is very vague and misleading. There should be more internal checks so a more specific errors can be given, or in this specific example the sim should update the object as I'm about to explain. In this case the error happens because the fresh prim is under the old Prim Equivalency system. The current workaround is to make some change to the prim to bring it under the new PE system. For example, adding a specular texture to the prim will fix the error. Changing the prim's physics shape to Convex Hull will also fix the error. I imagine the sim might be able to update the object's physics shape type when llSetKeyframedMotion is called, but I don't know all the possible side-effects.