📃 SLua Alpha

In 1-prim objects, root prim has link number 0. In other prims, root prim has link number 1 ( =LINK_ROOT ). This behavior should change: It's a pain to make scripts work with both types of objects Link numbers are so close to already using 1-based indexing, like everything else in SLua has been already changed to. This change would complete that transition For functions that accept a link number: 0 and 1 should both be treated equally as the root prim number, regardless of prim count This change should be made in SLua at least, but possibly in LSL and Mono as well. (it's probably easier to change both) I can't think of a reason this would break existing LSL content, as it only makes the functions do something useful where they previously did nothing (Suzanna thought of a theoretical reason it could break code below) For functions that return a link number: In LSL, they must be left alone, as this check is somewhat common to test for 1-prim vs multi-prim: if (llGetLinkNumber()) In SLua, they should be changed to always return 1 ( =LINK_ROOT ). This makes them more consistent, and SLua has no backwards compatibility concerns yet (This is the main reason this proposal is in SLua-Alpha and not Scripting Bugs) These functions accept link numbers, and return a prim property: ll.AvatarOnLinkSitTarget ll.GetLinkKey ll.GetLinkMedia ll.GetLinkName ll.GetLinkNumberOfSides ll.GetLinkPrimitiveParams ll.GetLinkSitFlags ll.GetObjectLinkKey ll.IsLinkGLTFMaterial These functions accept link numbers, and modify them: ll.BreakLink ll.ClearLinkMedia ll.LinkAdjustSoundVolume ll.LinkParticleSystem ll.LinkPlaySound ll.LinkSetSoundQueueing ll.LinkSetSoundRadius ll.LinkSitTarget ll.LinkSetSoundRadius ll.MessageLinked ll.SetLinkAlpha ll.SetLinkCamera ll.SetLinkColor ll.SetLinkGLTFOverrides ll.SetLinkMedia ll.SetLinkPrimitiveParams ll.SetLinkPrimitiveParams({PRIM_LINK_TARGET}) ll.SetLinkPrimitiveParamsFast ll.SetLinkPrimitiveParamsFast({PRIM_LINK_TARGET}) ll.SetLinkRenderMaterial ll.SetLinkSitFlags ll.SetLinkTexture ll.SetLinkTextureAnim ll.SetPrimitiveParams({PRIM_LINK_TARGET}) ll.SitOnLink These functions return a link number: LLEvents.link_message ll.CastRay ll.DetectedLinkNumber DetectedEvent.getLinkNumber ll.GetLinkNumber ll.GetObjectDetails({OBJECT_LINK_NUMBER})

in slua: local t = {"a", "b", "c", "d"} local u = ll.ListReplaceList(t, {"x"}, 2, 2) print("t", lljson.encode(t)) -- t ["a","b","c","d"] print("u", lljson.encode(u)) -- u ["a","x","b","d"] -- expected ["a","x","c","d"] lsl is fine: default { state_entry() { list t = ["a", "b", "c", "d"]; list u = llListReplaceList(t, ["x"], 1, 1); llOwnerSay("t: " + llList2Json(JSON_ARRAY, t)); // t: ["a","b","c", "d"] llOwnerSay("u: " + llList2Json(JSON_ARRAY, u)); // u: ["a","x","c", "d"] // correct }} llcompat is fine: local t = {"a", "b", "c", "d"} local u = llcompat.ListReplaceList(t, {"x"}, 1, 1) print("t", lljson.encode(t)) -- t ["a","b","c", "d"] print("u", lljson.encode(u)) -- u ["a","x","c", "d"]

I would think these would always be equal in SLua: print(ll.GetMemoryLimit()) -- 130920 print(2^17) -- 131072 That's what it does in LSO; just returns a constant 2^14 default { state_entry() { llOwnerSay((string)llGetMemoryLimit()); // 16384 llOwnerSay((string)llPow(2, 14)); // 16384 }}

local tab1, tab2 = {}, {} local weak = setmetatable({}, { __mode = "kv" }) for i = 1, 5000 do tab1[i] = i end weak[1] = tab1 print(ll.GetUsedMemory()) -- > 83706 tab1 = nil print(ll.GetUsedMemory()) -- > 83706 for i = 1, 5000 do tab2[i] = i end -- > Script run-time error not enough memory sleeping doesn't work: local tab1, tab2 = {}, {} local weak = setmetatable({}, { __mode = "kv" }) for i = 1, 5000 do tab1[i] = i end weak[1] = tab1 print(ll.GetUsedMemory()) -- > 83741 tab1 = nil ll.Sleep(3) print(ll.GetUsedMemory()) -- > 83741 for i = 1, 5000 do tab2[i] = i end -- > Script run-time error not enough memory we need to move to another event, this works: local tab1, tab2 = {}, {} local weak = setmetatable({}, { __mode = "kv" }) for i = 1, 5000 do tab1[i] = i end weak[1] = tab1 print(ll.GetUsedMemory()) -- > 83845 tab1 = nil LLTimers:once(0, function() print(ll.GetUsedMemory()) -- > 2190 for i = 1, 5000 do tab2[i] = i end print("ok") end) -- > ok

Using a notecard "test" with a line: Time flies like an arrow; fruit flies like a banana. -- one "Time": print(ll.FindNotecardTextSync("test","Time",0,0,{})[3]) -- 4 -- one "banana": print(ll.FindNotecardTextSync("test","banana",0,0,{})[3]) -- 6 -- two "like": print(ll.FindNotecardTextSync("test","like",0,0,{})[3]) -- 5 print(ll.FindNotecardTextSync("test","like",0,0,{})[6]) -- 5 -- two "flies": print(ll.FindNotecardTextSync("test","flies",0,0,{})[3]) -- 6 print(ll.FindNotecardTextSync("test","flies",0,0,{})[6]) -- 6 Could be related to this: https://feedback.secondlife.com/slua-alpha/p/the-length-returned-by-llfindnotecardtextsync-has-been-1-based previously to that canny all lengths were returned +1.

Unsure how important this is, but putting it out there: scalar doesn't work: > t = nil > print(t) nil > t = lljson.sldecode(lljson.slencode(t)) > print(t) lljson_constant: 0x0000000000000003 array doesn't work: > t = {nil, 2, nil, 4} > for i, v in t do print(i, v) end 2 2 4 4 > t = lljson.sldecode(lljson.slencode(t)) > for i, v in t do print(i, v) end 1 lljson_constant: 0x0000000000000003 2 2 3 lljson_constant: 0x0000000000000003 4 4 dict works: > t = {a=2, b=nil} > for i, v in t do print(i, v) end a 2 > t = lljson.sldecode(lljson.slencode(t)) > for i, v in t do print(i, v) end a 2 I don't anticipate running into this the way I plan to use slencode with LinksetData. There, I'll convert scalar nil to/from "" and never include nil in arrays. But, maybe someone else can think of a reason to do something different with one or more of these usecases

The syntax highlighter indicates that math.isnan should exist. However an attempt to use it results in an Attempt To Call A Nil Value error. Image showing error and highlighting compared to both valid and invalid math.xx expressions: https://imgur.com/3xX9lNe I lean toward fixing this by implementing math.isnan on principle of luau compatibility, but I don't have strong feelings about it either way. The number of likely users of math.isnan is incredibly small ( laughs one?) and I'm perfectly comfortable with using v~=v. (It's more succinct!)

lljson has inconsistent behavior. I think these should all produce an error: print(pcall(lljson.sldecode, '"!vOops"')) print(pcall(lljson.sldecode, '"!qOops"')) print(pcall(lljson.sldecode, '"!uOops"')) The first 2 produce an error: malformed tagged vector: !vOops malformed tagged quaternion: !qOops But the last one produces an uncompressed uuid: local _, u = pcall(lljson.sldecode, '"!uOops"') print(u, typeof(u), u.bytes) -- Oops uuid nil This uuid cannot be re-encoded: print(pcall(lljson.slencode, u)) invalid UUID format for JSON encoding Instead, sldecode should produce an error: malformed tagged uuid: !uOops And uncompressed uuid's should be removed from slua, it's documentation, and typechecker: https://github.com/secondlife/lsl-definitions/blob/23d46484888c1908545dc92db119613bb553af11/slua_definitions.yaml#L70 - name: bytes comment: Returns the raw 16-byte binary string of the UUID, or nil if the UUID is not in a compressed state type: string?

Making this a Canny at Harold's request. The name "listeners" in this context is confusing because we already have "listen" events. "handlers" is a more accurate term that is unambiguous and already in general use when discussing the subject. I suppose that "listeners" could potentially be kept as an alias for backward compatibility, if deemed necessary, but I feel that its use should be deprecated to avoid future ambiguity. (Not sure of the appropriate category for things like this. Calling it a Bug since it entails a change in the source code.)

Possibly related to [ https://feedback.secondlife.com/scripting-bugs/p/script-suddently-losing-connetion-with-the-server-on-save ] A few times I've gotten the above error. Fixing the syntax error does not eliminate the message — it's as if the script inventory instance is permanently disabled. My workaround has been to copy the script text to a new inventory instance. I was able to reproduce this on SLua Tombolo. 1) Create a block and add a new SLua script to it. 2) Change line 1 to: `` xxx ll.Say(0, "Hello, Avatar!") `` 3) Save. See an expected, normal error message. 4) Clone the object. Edit the script in the clone. 5) Notice the cloned script is marked not-running. 6) Use the external editor button to edit the cloned script. See the dreaded (0,0) error. (I am using BBEdit as my external editor: /usr/bin/open -a bbedit "%s" ) --- Second Life Project lua editor 7.1.12.13973830462 (64bit) Release Notes You are at 194.7, 250.2, 23.1 in SLua Tombolo located at simhost-0766603a88e3665d6.aditi SLURL: secondlife://Aditi/secondlife/SLua%20Tombolo/195/250/23 (global coordinates 41154.7, 23802.2, 23.1) Luau 2025-03-27.14115520293 Release Notes CPU: Apple M2 Max (2400 MHz) Memory: 32768 MB OS Version: macOS 15.3.2 Darwin 24.3.0 Darwin Kernel Version 24.3.0: Thu Jan 2 20:24:23 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6020 x86_64 Graphics Card Vendor: Apple Graphics Card: Apple M2 Max OpenGL Version: 4.1 Metal - 89.3 Window size: 2602x2102 Font Size Adjustment: 96pt UI Scaling: 1 Draw distance: 512m Bandwidth: 3000kbit/s LOD factor: 1.25 Render quality: 2 Texture memory: 21845MB Disk cache: Max size 1638.4 MB (99.9% used) HiDPI display mode: true J2C Decoder Version: KDU v7.10.4 Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.23.1 / OpenAL Community / OpenAL Soft: OpenAL Soft Dullahan: 1.14.0.202408091638 CEF: 118.4.1+g3dd6078+chromium-118.0.5993.54 Chromium: 118.0.5993.54 LibVLC Version: 3.0.21 Voice Server Version: Not Connected Packets Lost: 13/10384 (0.1%) March 30 2025 06:20:01