Scripting Bugs

The changed() event and CHANGED_OWNER is not triggered with transfers via llTransferOwnership() using flags 0x2 or 0x4. It does not occur before the object goes to the new owner's inventory nor when the new owner rezzes it. The changed() event and CHANGED_OWNER do trigger with flag 0x0. Due to how this feature works, I suspect it won't be easy to address this, but I'm filing it nonetheless.

llTransferOwnership() returns -6 when flag 0x4 is used inside a full-perm-for-owner object. Returns 0 when flags 0x0 or 0x2 are used. This seems to be a change from the last region version code.

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.

llTransferOwnership() allows no-copy inventory duplication.

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.

Using various REZ_FLAG's (and other parameters) in the llRezObjectWithParams-function let's you rez objects without modify-permissions, changing some of their properties in the process. Despite rezzing no mod objects, you can: • make them temporary (REZ_FLAG_TEMP) • make them physical (REZ_FLAG_PHYSICAL) • make them phantom (REZ_FLAG_PHANTOM) • have them deleted upon collision (REZ_FLAG_DIE_ON_COLLIDE) Further changes are possible with some of the other parameters (e. g. REZ_SOUND_COLLIDE). These flags should silently fail and maybe also give an error message on the debug channel since it allows changes of no mod objects that are not otherwise possible.

Regions attempt to process LLCS damage against objects with this flag enabled, leading to unexpected interactions.

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.

Using the following values: x = 2386073 n = 2 p = 2147483647 The expected value of xⁿ mod p is 365213132: 2386073 x 2386073 = 5693344361329 ⌊ 5693344361329 ÷ 2147483647 ⌋ = 2651 2651 x 2147483647 = 5692979148197 5693344361329 - 5692979148197 = 365213132 however llModPow is incorrectly returning 365210482 Using https://www.emathcalculator.com/en/calculators/algebra/powerMod.php confirmed my long-hand calculation gave the correct result. These are not the only values that give incorrect results (e.g. x=149120, with same n and p should return 761937930 but llModPow returns 761937910). It does seem in my limited testing that llModPow gives wrong results when x² is larger than a 32bit integer. You can check llModPow with the following script: default { state_entry() { integer x = 2386073; integer n = 2; integer p = 2147483647; integer expected = 365213132; integer result = llModPow(x, n, p); llSay(0, llList2CSV([ "x", x, "n", n, "p", p ])); llSay(0, llList2CSV([ "expected", expected, "actual", result ])); } } Change x, n, p and expected as appropriate. ETA: Above details were posted in non-public fields, oops.

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.