Scripting Bugs

Exiting an llVolumeDetect object by teleporting to a landmark fails to generate a collision_end event and prevent collision_start events on re-entry by teleport or even walking into the object. Exiting by sitting on an external target fails to generate the collision_end but does not prevent re-entry from generating collision_start events. Exiting the volume by teleporting to a map target (or SLURL) generates the collision_end as expected.

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?

I'm trying to send an API post to the pastebin endpoint. When I send via LSL and use a proper MIMETYPE, I get an HTTP Error 415, Response: Unsupported or unknown Content-Type When I send with no MIMETYPE and instead send with HTTP_CUSTOM_HEADER, I get this debug window error: "HTTP_CUSTOM_HEADER value is an invalid header". I presume that this second problem is due to the caveat "Note that certain headers, such as the default headers, are blocked for security reasons." The content type I wish to use is application/x-www-form-urlencoded When I send a request to pasetbin using that content type outside of LSL (Python), everything works great. From SL, no good. Edit: Moving an important detail from the hidden details field up here, too: As a side-note, another bug!!! The wiki ( https://wiki.secondlife.com/wiki/LlHTTPRequest ) says that one accept parameter we can use is "text/plain;charset=utf-8" Using that string yields an error also!

Nonsensical inclusion of a void-valued function call (e.g., llDialog) in list initialization generates "Internal server compile error" (with cursor at top of script source) when Mono-compiled, whereas non-Mono compiles but gets heap error at runtime.

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!

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.

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

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.

I tried creating a script using llMapBeacon() but even when explicitly asked to NOT open the map, the viewer still opens the map. Try this: llMapBeacon(llGetRegionName(), <128, 128, 128>, [1, FALSE, FALSE]);

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.