Scripting Bugs

Pretty sure I've never before called llAddToLandBanList() on purpose, but now I realize that the banned agent gets a system notification: "You are no longer allowed here and have 15 seconds to leave." But they don't get 15 seconds, they get ejected immediately, which seems like something that could create drama (not that it has much practical significance). I'd be fine if they actually got 15 seconds (or longer), vaguely akin to Philip's feature suggestion ( https://feedback.secondlife.com/scripting-features/p/always-wait-a-few-seconds-before-ejecting-an-avatar-from-a-parcel ), or I'd also be fine if they weren't promised the 15 seconds at all. In a forums thread, Rolig suggested that @Kyle Linden may have insight.

Hello, I wanted to find a way to give an object to a new owner from a script, the object being no-copy I used the flag "TRANSFER_FLAG_TAKE" but after receiving said object, the new owner has a "Locked" version of the object. It wasn't locked before. So if they rez it, they are unable to take it back as it's also no-mod.

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

I now know of (at least) two categories of Objects in the Library: those that return the same key to llRezObjectWithParams() as object_rez() obtains with the item rezzes, and those for which the function returns a different key than accompanies the event.

https://wiki.secondlife.com/wiki/LlListFindListNext llListFindListNext(haystack, needle, instance); Returns the index for the Nth instance of needle . instance is zero-based. Returns -1 when there aren't enough instances. Error: Returns last index + 1 when needle is the last element of the list. integer index; list haystack = ["A", "B", "C"]; index = llListFindListNext(haystack, ["C"], 0); // OK llSay(PUBLIC_CHANNEL, "Expect 2: " + (string)index); index = llListFindListNext(haystack, ["B"], 1); // OK llSay(PUBLIC_CHANNEL, "Expect -1: " + (string)index); index = llListFindListNext(haystack, ["C"], 1); llSay(PUBLIC_CHANNEL, "Expect -1: " + (string)index); index = llListFindListNext(haystack, ["C"], 23); llSay(PUBLIC_CHANNEL, "Expect -1: " + (string)index);

It is expected that this function can be used to transfer ownership of a rezzed object in-place. That is, without requiring the recipient to rez it from inventory. Setting the transfer flag to 0 (no flag) transfers ownership of the object in-place. However any items in the object's inventory that do not have NEXT owner transfer permissions do not transfer with the object, notwithstanding that the items have current owner transfer permissions prior to transferring. Neither the TRANSFER_COPY or TRANSFER_TAKE flags allow transferring in -place. This makes it imposslbe to transfer in-place an object that you want to prevent the recipient from having transfer permissions.

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.

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.

IF you set PRIM_DAMAGE via llSetPrimitiveParams, and subsequently retrieve the same info via llGetPrimitiveParams you get identical damage values, but damage type is wildly different. sample Output: [10:06] BOB: llGetPrimitiveParams: 0.000000, -2147483648 [10:06] BOB: llGetObjectDetails: 0.000000, -822083584

The PRIM_PROJECTOR flag in llGetPrimitiveParams() returns the following script error: llGetPrimitiveParams error: Param 1 error, unknown parameter. The Wiki indicates this is to protect the UUID of the returned texture parameter from bypassing object permissions. However, by turning this entire function off we can not request other useful parameters such as FOV, Focus, and Ambiance. These have become more important with PBR. Please just have the flag return NULL_KEY for texture so we can at least get the other settings?