Scripting Bugs

  • Search existing bugs before submitting
  • Use support.secondlife.com for customer support issues
  • Keep posts on-topic
Bug Report: Residual Script Effects Preventing Object Movement in Mesh Prims
Description: When placing a scripted object inside a mesh prim, even after disabling all other scripts, the object refuses to move despite having full permissions (including "take control"). The same script works perfectly when placed inside a regular prim (box). This behavior strongly suggests that residual effects from previously running scripts (such as lingering llSitTarget or similar calls) persist within the mesh prim and prevent proper control, even if those scripts are disabled or removed. Steps to Reproduce: Place the scripted object inside a mesh prim. Disable or remove all other scripts in the prim except the movement control script. Attempt to move or control the object — it fails to respond despite correct permissions and input. Replace the mesh root prim or rezz a new prim and the same script works correctly. The issue does not occur if the object is placed in a regular prim (box). Debug confirms physical presence, permissions, and input detection are correct; however, the object does not move. Expected Behavior: Disabling or removing scripts should fully stop any lingering script effects such as llSitTarget or control overrides, allowing the object to move normally under script control. Actual Behavior: Residual script effects remain active even after disabling/removing scripts, causing the object to become immobile inside mesh prims unless the root prim is replaced or a new prim is rezzed. Impact: This is a critical bug affecting scripted object control and physics within mesh prims, disrupting expected behavior and causing significant development and usage issues. Additional Notes: The bug seems specific to mesh prims and does not appear in regular prims. Replacing the mesh root prim clears the issue temporarily, indicating state persistence at the prim level. Suspected causes include improper cleanup of llSitTarget or similar functions.
4
·

needs info

llRezObjectWithParams flag REZ_FLAG_NO_COLLIDE_FAMILY causes first instance of rezzed object to receive no collision_start events at all
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.
6
·

tracked

Load More