Scripting Bugs

Since this last server release sensor calls for objects are behaving inconsistently, can break numerous scripted systems. This issue appears to have been introduced in the most recent server rollout. Sensor calls for SCRIPTED and PASSIVE have had their behaviour change or are failing to register objects, with no apparent consistency. One object doing a sensor call will report objects properly, another of the same object an arbitrary distance away will fail to pick up the same objects when they are moved into range. See https://youtu.be/3rka4sPOsMc Rez a cube, put this script in it, make multiple. Drag a scripted object or use a scripted vehicle and move into range of the various sensor boxes. Results are very inconsistent. In one instance, a cube located at <114.43994, 61.48804, 151.37827> reported results correctly, only to then fail when moved to <114.43994, 62.48804, 151.37827>, just a single meter of difference. "integer step=0; default { state_entry() { llLinkParticleSystem(-1,[]); } touch_start(integer n) { if(llDetectedKey(0)==llGetOwner()) { step=0; llOwnerSay("Calling at "+(string)llGetPos()); llSensor("","",AGENT,14,TWO_PI); } } sensor(integer n) { llOwnerSay("Sensor step "+(string)step); key tgt; while(n--) { if(llDetectedType(n)&0x1) { llOwnerSay("avatar "+llDetectedName(n)); } else { llOwnerSay("object "+llDetectedName(n)); } } if(step==0)llSensor("","",SCRIPTED,14,TWO_PI); if(step==1)llSensor("","",PASSIVE,14,TWO_PI); if(step==2) { llSleep(1); //llDie(); } ++step; } no_sensor() { llOwnerSay("No_sensor step "+(string)step); if(step==0)llSensor("","",SCRIPTED,14,TWO_PI); if(step==1)llSensor("","",PASSIVE,14,TWO_PI); if(step==2) { llSleep(1); //llDie(); } ++step; } }" "[11:49:01] Object detector click 1: Calling at <114.43994, 61.00000, 151.37827> [11:49:02] Object detector click 1: Sensor step 0 [11:49:02] Object detector click 1: avatar Dread Hudson [11:49:02] Object detector click 1: Sensor step 1 [11:49:02] Object detector click 1: object [Chaos] Hellblade Base [11:49:02] Object detector click 1: No_sensor step 2 [11:49:06] Object detector click 1: Calling at <114.43994, 62.00000, 151.37827> [11:49:06] Object detector click 1: Sensor step 0 [11:49:06] Object detector click 1: avatar Dread Hudson [11:49:06] Object detector click 1: No_sensor step 1 [11:49:06] Object detector click 1: No_sensor step 2"

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.

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.

Summary: When editing a vehicle owned by another resident, replacing the script responsible for setting vehicle physics parameters can leave the object in a broken physical state. The object no longer behaves as a vehicle and instead falls/flops as if llSetVehicleType() / vehicle parameters were not applied. This appears to happen specifically (and consistently) when a non-owner with edit rights deletes the existing vehicle motor script and inserts a new version into the object. Resetting scripts does not help to recover from this bad state. The only workaround is for the owner to take the vehicle back into inventory and rez it again. Only then, will the vehicle physics start working correctly. Steps to Reproduce: Have Resident A own a physical vehicle object. Resident B has permission to edit the vehicle. Resident B deletes the existing script responsible for setting the vehicle motor / vehicle physics parameters. Resident B inserts a new version of that script into the vehicle. Reset the script or reset all scripts. Attempt to use the vehicle. Expected: After the script is inserted and reset, the object should become a vehicle again. The vehicle script should be able to initialize the vehicle normally by setting the vehicle type and vehicle parameters, regardless of whether the script was inserted by the object owner or by another resident with edit rights. Actual Result: The object fails to become a vehicle. It behaves like a normal physical object with no vehicle physics applied. It flops/falls instead of responding as a vehicle. Resetting the vehicle script or resetting all scripts does not fix the issue. Other Observations: This only happens when a non-owner editor deletes and inserts the replacement vehicle script. If the object is owned by me, I cannot reproduce the issue. If I give the updated script to the owner and they insert it themselves, the issue does not occur. Once the bad state happens, script resets do not recover it. Re-rezzing the vehicle from inventory restores correct behavior.

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

I found a bug that causes false clicks on the avatar when there is a passenger seat with control permissions. In other words, the avatar sitting on the root prim has a script to allow controls and the avatar sitting on the prim child has another script on the prim child that also allows controls. This error can only be caught if the script depends on correctly reading button presses. When both avatars are sitting, and the root avatar holds down a key, it will fire even when it is just pressed. It takes 10 to 20 seconds for this bug to start, and if there is more load on the script it can trigger very quickly. The click receiver is defined as a "first touch" limiter, but the avatar will hold the key in the "controls section": integer start = level & edge; if(start & CONTROL_FWD) This shouldn't let any command pass without the avatar releasing the key and pressing it again, but in this bug it triggers false clicks with the key held down. I wrote a script to demonstrate this bug in practice. There are two scripts, one for root and one for child prim: Connect 2 prims for seat. Each Prim receives the respective scripts below that request control permission. Sit with both avatars. Use the main avatar in root prim: press forward, hold for up to 20 seconds and see false clicks being generated: Scripts that catch the bug: ------------------------------------------------------------ //Root Prim: integer i; default { state_entry() { llSetTimerEvent(0.2); } changed(integer change) { if(change & CHANGED_LINK) { key avatar = llAvatarOnSitTarget(); if(avatar != NULL_KEY) { llRequestPermissions(avatar, PERMISSION_TAKE_CONTROLS); } else { llReleaseControls(); llResetScript(); } } } run_time_permissions(integer perm) { if(PERMISSION_TAKE_CONTROLS & perm) { llTakeControls(CONTROL_RIGHT | CONTROL_LEFT | CONTROL_BACK | CONTROL_FWD, TRUE, 0); } } control(key id, integer level, integer edge) { integer start = level & edge; if(start & CONTROL_FWD)//Only one click at a time { i++; llSay(0,"Click = "+(string)i); } } timer() { //just to increase the use of the script in this bug test. integer read_timer; read_timer++; } } //End script 1 ------------------------------------------------------------------------ ------------------------------------------------------------------------- //Child Prim: default { changed(integer change) { if(change & CHANGED_LINK) { key avatar = llAvatarOnSitTarget(); if(avatar != NULL_KEY) { llRequestPermissions(avatar, PERMISSION_TAKE_CONTROLS); } else { llReleaseControls(); llResetScript(); } } } run_time_permissions(integer perm) { if(PERMISSION_TAKE_CONTROLS & perm) { llTakeControls(CONTROL_RIGHT | CONTROL_LEFT | CONTROL_BACK | CONTROL_FWD, TRUE, 0); } } control(key id, integer level, integer edge) { //Passenger. Nothing defined in this test. Permission only. } } //End Script 2 ------------------------------------------------------------------------- This is a translator. I would like someone from the native language to send this for greater clarity, but unfortunately the error happened to me. I hope that Linden resolves this very calmly and cautiously, as I know that fixing a bug can generate other bugs. I'm not in a hurry or urgent. At the moment I could deviate from this type of script, but I would like this to be listed as bugs to be fixed. Thanks!

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?

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.

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.