Scripting Bugs

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.

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

When actively updating PRIM_OMEGA (like the wheels of a car) crossing into another sim causes them to not behave as intended and start stuttering or twitching their rotation instead of smoothly rotating. This is the same issue as outlined in BUG-232844 from the old Jira with the exact same steps to reproduce, it has returned.

Bare bones repro script: default { state_entry() { if (TRUE) { @blah; } @blah; } } Does not repro with LSO compiles. I ran into this with a much larger script and had to delete scopes to find it. It would help if this script bug would cause a syntax error message and location to appear in the compile status window instead. It feels like I've seen this reported before, but I cannot find the bug report. Please link the issue if it already exists. Thanks.

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.

The rezzed object doesn't seem to get accelerated. The wiki page has omitted information about what 'force' actually means and, for example, doesn't say how a force that would accelerate the object by N meters per second would need to be calculated.

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.

I was testing a rezzer and noticed that when I rez an object with REZ_DAMAGE set it makes the object temp, even when the temp flag is not active. I was told I should post this. default { state_entry() { // llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { string s = llGetInventoryName(INVENTORY_OBJECT,0); llRezObjectWithParams(s, [ REZ_POS, llGetPos()+<0,0,1>, FALSE, FALSE, // Relative offset 2 meters forward REZ_ROT, ZERO_ROTATION, TRUE, // Relative rotation REZ_VEL, <0,0,0>, TRUE, FALSE, // Relative velocity 100m/s forward REZ_DAMAGE, 100.0, REZ_PARAM_STRING,"TEST", REZ_LOCK_AXES, <0,0,0>, // 1,1,1 Disable all rotation REZ_FLAGS, 0 | REZ_FLAG_BLOCK_GRAB_OBJECT ]); } }

SIT_FLAG_NO_COLLIDE (applied with llSetLinkSitFlags()) disables collision shapes on seated avatars but avatar mass is still contributed to the object. This shifts the physical object's center of mass and interferes with the function of particularly small vehicles. Avatar mass contributions should be simply be disabled entirely when SIT_FLAG_NO_COLLIDE is applied to match the behavior of linked objects not contributing to a linkset's mass when PRIM_PHYSICS_SHAPE_TYPE is set to PRIM_PHYSICS_SHAPE_NONE with llSetLinkPrimitiveParams(). Alternatively, a sit flag, e.g. 'SIT_FLAGS_NO_MASS', that disables mass contribution from seated avatars is proposed.

Using various REZ_FLAG's (and other parameters) in the llRezObjectWithParams-function let's you rez objects without modify-permissions, changing some of their properties in the process. Despite rezzing no mod objects, you can: • make them temporary (REZ_FLAG_TEMP) • make them physical (REZ_FLAG_PHYSICAL) • make them phantom (REZ_FLAG_PHANTOM) • have them deleted upon collision (REZ_FLAG_DIE_ON_COLLIDE) Further changes are possible with some of the other parameters (e. g. REZ_SOUND_COLLIDE). These flags should silently fail and maybe also give an error message on the debug channel since it allows changes of no mod objects that are not otherwise possible.