Scripting Bugs

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.

When you unlink items with script, using llBreakLink(), the unlinked item will often flicker, dissapear or is only visible from a certain angle, and the item cannot be interacted with until you cam away far enough and back or TP away and back, or you wait long enough till the sim sends an update to viewer. Also area search is failing to find the items if its more then one. it will only find one. When you unlink items manually it works fine. I tested it on several viewers, as well as the latest LL viewer, I tried different sims and asked many peopel if they see the same as I do . The script can still see and find the items fine, so it looks like it was simply forgotten to update the viewer after the operation, like what does happen when you unlink manually or rez items.

LSL doesn't seem able to read avatars' rotations with any degree of accuracy unless they're seated or in mouselook. Allowing scripts to read avatars' rotations under all circumstances would make it possible accurately to rez objects using the avatar's frame of rotational reference and to track their direction of travel. It would also make llCastRay useful in many more circumstances.

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!

llStringLength delivers number of extended characters which is consistant with its Wiki docs. llDialog limits are based on the actual number of bytes in the string which can of course be 4x that. Recommendation: Update the Wiki to warn scripters against using UTF-8 or UTF-16 characters in llDialog messages or at least explain that its not the number of characters but the number of bytes.

default { state_entry() { string json_array = llList2Json(JSON_ARRAY, ["\"", "]"]); string json_object = llList2Json(JSON_OBJECT,[ "string", "Hello, world!", "json_array", json_array, "double quote", "\"" ]); llSay(0, json_object); string extracted_string = llJsonGetValue(json_object, ["string"]); string extracted_array = llJsonGetValue(json_object, ["json_array"]); llSay(0, "extracted_string:" + extracted_string); // Says "Hello, world!" llSay(0, "extracted_array:" + extracted_array); // Empty string? } } There seems to be an issue with the way llJsonGetValue extracts json arrays. This minimal repro script gives an empty string for the extracted array, instead of the given array. Note that the created json object seems fine, it just can't extract from it.

[\x00-\x7f] or [\x00-\x7F] doen't work. \x##, where # is a hex value, does. [\x00-\x7f] is legal in regex outside of SL.

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

Doesn't seem to apply overrides when they are sent all at once right after PRIM_RENDER_MATERIAL . So this won't work: llSetLinkPrimitiveParamsFast(LINK_THIS, [49,0,"aa904b20-3a56-29c6-03c5-cd53c9ce3484",48,0,"",<1.000000, 1.000000, 0.000000>,<0.000000, 0.000000, 0.000000>,0.000000,<1.000000, 0.452452, 0.452452>,0.800000,0,"","",45,0,"",<1.000000, 1.000000, 0.000000>,<0.000000, 0.000000, 0.000000>,1.570800,47,0,"",<1.000000, 1.000000, 0.000000>,<0.000000, 0.000000, 0.000000>,1.570800,1.000000,0.000000,46,0,"",<1.000000, 1.000000, 0.000000>,<0.000000, 0.000000, 0.000000>,1.570800,""]); Split into two will work: llSetLinkPrimitiveParamsFast(LINK_THIS, [49,0,"aa904b20-3a56-29c6-03c5-cd53c9ce3484"]); llSetLinkPrimitiveParamsFast(LINK_THIS,[48,0,"",<1.000000, 1.000000, 0.000000>,<0.000000, 0.000000, 0.000000>,0.000000,<1.000000, 0.452452, 0.452452>,0.800000,0,"","",45,0,"",<1.000000, 1.000000, 0.000000>,<0.000000, 0.000000, 0.000000>,1.570800,47,0,"",<1.000000, 1.000000, 0.000000>,<0.000000, 0.000000, 0.000000>,1.570800,1.000000,0.000000,46,0,"",<1.000000, 1.000000, 0.000000>,<0.000000, 0.000000, 0.000000>,1.570800,""]);

Using llRezObjectWithParams with REZ_POS and the Relative parameter set TRUE results in the Rezzee being placed relative to the rezzer in the region reference frame rather than in the the rezzer's local reference frame.