Scripting Bugs

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.

[\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,""]);

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.

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.

Any time I sit or use a couples hud my hover height is wrong. When I sit I end up in the floor or beneath it and when I try to use a couples hud I end up in the air. This is happening across multiple platforms.

When the root prim of a linkset is more than 20m from a child prim containing a script that calls llDialog, llListen, and contains the listen event handler (such as the test script below) it will not be able to receive any inputs given to the dialog by a user. This is working in a contradictory manner to the caveats section of the documentation for llDialog at https://wiki.secondlife.com/wiki/LlDialog which contains a caveat stating the following: "If the listener resides in the same script that created the dialog, then the dialog button is heard sim-wide." While those of us that create items and scripts understand that things can and do change, it should be noted that the residents who use and purchase that content expect their items to work as intended and creators expect that scripted items we create and observe to be working will not be broken without some sort of indication of change in the documentation. With the behavior not being what is stated in the documentation any scripts residing in a child prim of a linkset that are set up in a manner similar to that of the Test Script below will fail to work properly when that child prim is positioned more than 20m from the position of the root prim. This behavior is not intuitive and will likely result in unnecessary frustration for many users who either create content with larger linksets or who have content with larger linksets that is effected by this current behavior. I cannot think of any reason that the behavior indicated in the above quoted caveat should have been altered, and would like to see that behavior restored. To put it simply, the currently documented behavior, including whatever is in the caveats section, is the behavior residents should, and do, expect to observe. Test Script: default { on_rez(integer start_params) { llResetScript(); } state_entry() { llSetTimerEvent(0); llListen(-8888, "", llGetOwner(), "TEST"); } touch_start(integer total_number) { if(llDetectedKey(0) == llGetOwner() && llGetAgentSize(llGetOwner()) != ZERO_VECTOR) {// Check to see if the owner touched the prim and is on the same region. llDialog(llGetOwner(), "Click the TEST button to test llDialog function within a linkset.", ["TEST"], -8888); llSetTimerEvent(30); } } listen(integer channel, string name, key id, string message) { llSetTimerEvent(0); if(llGetAgentSize(llGetOwner()) != ZERO_VECTOR) {// Check to see if the owner is on the region before sending a message to them. llRegionSayTo(llGetOwner(), 0, "You clicked the TEST button."); } } timer() { llSetTimerEvent(0); if(llGetAgentSize(llGetOwner()) != ZERO_VECTOR) {// Check to see if the owner is on the region before sending a message to them. llRegionSayTo(llGetOwner(), 0, "Object clicked but no dialog input received in 30 seconds."); } } changed(integer change) { if(change & CHANGED_OWNER) { llResetScript(); } } } Steps to reproduce observed issue: Create a new script containing only the code from the Test Script above. Create two prims of sufficient size to allow linking them with their centers more than 20m away from each other. Put the script you created in step 1 into the child prim. Stand on the same region with the test object. Click the child prim. Click the button labeled TEST on the resulting dialog within 30 seconds. Wait for the output. Re-position the prims in your linkset to be within 20m of each other. Repeat steps 4 through 7. Observed Behavior: When the two prims are over 20m apart the script will not receive the dialog input from the TEST button. Instead it will wait for the entire 30 seconds after the child prim was clicked before shutting off the timer and giving the message "Object clicked but no dialog input received in 30 seconds." that is in the timer event. When the two prims are within 20m of each other the script will receive the input from the TEST button and will shut off the timer and then give the message "You clicked the TEST button." that is in the listen event. Expected Behavior: Given the current documentation and the fact that the test script has llListen, the listen event, and llDialog reside in the same script The script should give the message "You clicked the TEST button." that is in the listen event regardless of the distance between the root and child prims as per the caveat in the wiki. Why is this important: The current behavior observed is not intuitive, is counter to what is documented, and will have resulted in content that has ceased to function as intended. Additionally, when writing scripts creators rely on the documentation provided in the wiki and expect that content we create today will work so long as we follow said documentation. Scripted objects that work should not be rendered broken without a good reason and some accompanying changes to the documentation in the wiki. Preferably, any such changes to the documentation would also contain some explanation of (and for) any changes in behavior that we might see.

Rez a box, place this script inside of it: default { state_entry() { llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { list env = llGetEnvironment(llGetPos(),[SKY_LIGHT,SKY_SUN,SKY_MOON]); vector spDir = llGetSunDirection(); vector rpDir = llGetRegionSunDirection(); vector envDir = llList2Vector(env,0); quaternion rot; rot = llRotBetween(llRot2Up(ZERO_ROTATION),envDir); //rot = llAxisAngle2Rot(<0,1,0>,90 DEG_TO_RAD) llGetSunRotation(); llSetRot(rot); llSay(0, "sunDir: " + (string)spDir + "\nenvDir: " + (string)envDir + "\nrpSunDir: " + (string)rpDir); } } Click the box. Observe that the prim will rotate towards the celestial body, however it does not point directly towards the body, with varying error levels.

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.