Scripting Bugs

An object rezzed with llRezObjectWithParams that has the flag REZ_FLAG_DIE_ON_COLLIDE set on it does not obey any filter applied by llCollisionFilter. That is, if an object has a script in it that sets a filter to ignore collision with some object, it will still die on collision with that object if the DIE_ON_COLLIDE setting was used. This obviously breaks legacy behavior and makes the new rez method less flexible than the old method. I posted a feature request in the combat2 section before I realized there's actually a bug here as well. This post covers the actual bug between llRezObjectWithParams and llCollisionFilter. You can see my suggestion here: https://feedback.secondlife.com/combat-20/p/add-rez-collision-filter-parameter-to-llrezobjectwithparams To reproduce: Create an object called "ObjectA" with gravity set to 0 and this script in it default { state_entry() { llCollisionFilter("ObjectB", NULL_KEY, FALSE); } } Create a rezzing object with ObjectA in it and this script default { touch_start(integer total_number) { list rez_params = [REZ_FLAGS, REZ_FLAG_PHYSICAL | REZ_FLAG_DIE_ON_COLLIDE, REZ_POS, llGetPos()+<0.0, 0.0, 1.5>, FALSE, FALSE]; llRezObjectWithParams("ObjectA", rez_params); } } Now place an object called "ObjectB". Touch the rezzing object, then drag ObjectA that appears until it collides with ObjectB. You will observe that ObjectA dies despite the fact that collisions with ObjectB are suppressed by llCollisionFilter. You could argue that this is "working as designed" and that it's correct for REZ_FLAG_DIE_ON_COLLIDE not to be influenced by llCollisionFilter. However, back before llRezObjectsWithParams came along and an object had to have its own script to destroy itself on collision, it was useful to filter out some object by name from this behavior. There is no such capability of filtering collisions by object name with llRezObjectWithParams, so the only solution is to do things the old way, giving up the improvements made possible by this new rez API. It would be better overall for LSL development to maintain this filtered collision behavior in the new method.

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.

What it says on the tin. After logging in or crossing to a new region, llGetCameraFOV returns 1.047198 (60 degrees) until the user changes their FOV on that region, after which it will report the correct value. This causes problems as projections will be wrong after crossing any borders with a non-default FOV, and immediately on login if the viewer's default is not 60 degrees.

We're using the folling routine to generate a random number for chat-channel to use, and storing it encrypted for other valid objects to communicate on. Unfortunately as of today, it is reporting the exact same number for most of our customers, resulting in the same encrypted code generated, and our customers are now experiencing chat throttling on their pets as a result. This really shouldnt be happening. the routing we're using to generate the number is as follows: integer rand(integer min, integer max) { return min + (integer)llFrand(max - min + 1); }

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.

The wiki page for llIsFriend says that the function fails if "If neither the owner, nor the target agent are in the region." I am not an English native speaker, but I asked two native speakers and both agreed with my interpretation that the functions fails if both , owner and target, are not present. However it should not fail if either the owner or the target are present. Test, however, show that solely the owner has to be present for the function to work. Test script key friend = "99d8181a-4395-4c7f-9784-e67d774834b4"; integer i = 0; default { state_entry() { while (i < 50) { llOwnerSay((string) llIsFriend(friend)); llSleep(1); i++; } } } Observed behavior Given are region A and region B. The object with the test script is on region A. During the duration of the test, owner and friend move to an adjacent region and back several times. owner on A, friend on A: pass owner on A, friend on B: pass owner on B, friend on A: fail owner on B, friend on B: fail Expected behavior owner on A, friend on A: pass owner on A, friend on B: pass owner on B, friend on A: pass owner on B, friend on B: fail I sincerely hope this is an actual bug, and not the intended behavior paired with an ambiguous description on the wiki. The functionality would be severely limited if this would be the intended behavior.

Description: I've encountered an issue where llGroundRepel() applied to an avatar loses its effect upon crossing regions, unlike llSetHoverHeight(), which maintains its hover effect consistently. This behavior isn't documented in the LSL wiki. https://wiki.secondlife.com/wiki/llGroundRepel https://wiki.secondlife.com/wiki/llSetHoverHeight Expected Behavior: llGroundRepel() should consistently maintain the avatar's hover height above ground and water, even after crossing regions, similar to llSetHoverHeight(). Actual Behavior: When using llGroundRepel(), the avatar's hover effect diminishes after a region crossing, whereas llSetHoverHeight() maintains the hover effect without issue. Following is a sample test HUD script to recreate this behavior. --- integer on; default { touch_start(integer n) { on = !on; if(on) llGroundRepel(2, TRUE, 1); // llSetHoverHeight(2, TRUE, 1); else llGroundRepel(0, TRUE, 1); // llStopHover() } } --- Here is a short video to show the difference. https://gyazo.com/9a6c691ed51985d23143e5e253685ea5

vector v = (vector)"<1, 1, 1>"; llOwnerSay((string)v); RESULT: <1.00000, 1.00000, 1.00000> vector v = (vector)"<1 , 1 , 1>"; // note the extra space llOwnerSay((string)v); RESULT: <0.00000, 0.00000, 0.00000> EXPECT: <1.00000, 1.00000, 1.00000> NOTE: Similar results with " <1, 2, 3>" (leading space); however, "<1, 2, 3> " (trailing space), "< 1, 2, 3>" and "<1, 2, 3 >" work as expected. Same thing happens typecasting rotations with whitespace before a comma. I can't think of any reason that whitespace character would be significant and invalidate conversion of the initial string to a vector or rotation. One would think the typecast would be fairly liberal about accepting text representations of vectors and rotations.

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