📃 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 }}

Not much more to it. llGetFreeMemory report 16000s bytes free at all times, llGetSPMaxMemory reports 16384 whether profiling is on or off. Same applies to pure Luau scripts, neither function returns meaningful values. ~~llGetUsedMemory and ll.GetUsedMemory appear to be ok.~~ <- Edit: redacted, they do not count memory used by tables or strings at all. A table with 10000 random numbers in it is reported as not using any memory, as well as a string with 256k(! that can't be right either) characters. Same applies to lists when compiled as LSL-Luau.

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

Please add a function that converts a float64 to a signed 32-bit integer, compatable with lsl. It would be equivilant to in luau: function bit32.s32(n: number) return (math.modf(n) + 0x8000_0000) % 0x1_0000_0000 - 0x8000_0000 end in c: double s32(double n) { return (double)(s32)n; } Code that dealt with integers >= 0x8000_0000 behave differently in lsl and luau, due to s32 wrapping. I imagine there's already a function like this for the lsl compiler, but exposing it to slua scripters would be helpful for converting old scripts

In the script editor, the dropdown gives 3 options for compiling LSL, and 1 for SLua. I think they would be better named: SLua LSL-128 (on SLua) LSL-64 (on Mono) LSL-16 (on LSO) "LSL-128" is clear, compact, and and easily distinguishable from both "Mono" and "SLua", which already have colloquial names. I also reversed the list to put them in order of most to least recommended Edited with input from Nexii Malthus, Suzanna Linn, and Kristy Aurelia

I wrote a inventory wrapper similar to DetectedEvent . Maybe something like it should be a builtin: https://gist.github.com/tapple/81c509f4a876e7364989607f507bc947 It wraps all the generic inventory functions. It does inventory iteration, both forward and backward (required if removing inventory during iteration) It does not wrap the multiple inventory functions: ll.GiveInventoryList ll.GiveAgentInventory It does not wrap the functions specific to an asset type: the 28 functions marked asset-semantics in https://github.com/secondlife/lsl-definitions/blob/main/lsl_definitions.yaml ll.StartAnimation ll.StartObjectAnimation It does not wrap the rumored upcoming llGetLinkInventory because they don't exist yet