Scripting Bugs

In testing out llGetGroundTexture, it's setting the Southeast values in the Region/Estate terrain menu to the values set with TERRAIN_HEIGHT_RANGE_NW, and setting the Northwest values with the values set with TERRAIN_HEIGHT_RANGE_SE Originally found in Firestorm, verified identical activity in official viewer.

TargetOmega rotation script stops working randomly when linked to a scripted child prim. Use a prim with basic rotation script from inventory library and attach a scripted prim with an alternating texture face changing animation script as used for flapping bird wings. Check it for a day or two. I can send it to you, if necessary.

I use the following piece of code to check my elevator on sit on prim that i compare to the sit target and it delivers a wrong value if i sit on a prim with an animated texture. vector checked_prim_landing = llList2Vector( llGetObjectDetails( llGetLinkKey(checked_prim), [OBJECT_POS] ),0 ); Prims with no animated texture report the correct value.

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]);

llMapBeacon does not open on listen events, even for owner.

https://wiki.secondlife.com/wiki/LlListFindListNext llListFindListNext(haystack, needle, instance); Returns the index for the Nth instance of needle . instance is zero-based. Returns -1 when there aren't enough instances. Error: Returns last index + 1 when needle is the last element of the list. integer index; list haystack = ["A", "B", "C"]; index = llListFindListNext(haystack, ["C"], 0); // OK llSay(PUBLIC_CHANNEL, "Expect 2: " + (string)index); index = llListFindListNext(haystack, ["B"], 1); // OK llSay(PUBLIC_CHANNEL, "Expect -1: " + (string)index); index = llListFindListNext(haystack, ["C"], 1); llSay(PUBLIC_CHANNEL, "Expect -1: " + (string)index); index = llListFindListNext(haystack, ["C"], 23); llSay(PUBLIC_CHANNEL, "Expect -1: " + (string)index);

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.

I have a gadget showing SL daytime and description of cycle within the day (morning, afternoon etc). Noticed that whilst I was sitting down (tried AVsitter and nPose scripted furniture), it suddenly ran 30 minutes fast at this location: Second Life Release 7.1.12.13550888671 (64bit) You are at 146.4, 145.0, 34.4 in Darkover located at simhost-090715bfd81f9bf4e.agni SLURL: http://maps.secondlife.com/secondlife/Darkover/146/145/34 (global coordinates 257,426.0, 230,289.0, 34.4) Second Life Server 2025-03-14.13862207703 but not at this location: Second Life Release 7.1.12.13550888671 (64bit) Release Notes You are at 107.9, 124.2, 1,001.0 in Moonbow located at simhost-0baa562fa277f8a2d.agni SLURL: http://maps.secondlife.com/secondlife/Moonbow/108/124/1001 (global coordinates 180,076.0, 287,356.0, 1,001.0) Second Life Server 2025-03-14.13862207703 Release Notes It reverts to the correct time on "unsitting". Same result with Genesis viewer (latest release version) AND the current SL viewer.

It is expected that this function can be used to transfer ownership of a rezzed object in-place. That is, without requiring the recipient to rez it from inventory. Setting the transfer flag to 0 (no flag) transfers ownership of the object in-place. However any items in the object's inventory that do not have NEXT owner transfer permissions do not transfer with the object, notwithstanding that the items have current owner transfer permissions prior to transferring. Neither the TRANSFER_COPY or TRANSFER_TAKE flags allow transferring in -place. This makes it imposslbe to transfer in-place an object that you want to prevent the recipient from having transfer permissions.

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.