📃 Lua Alpha

Texture alpha is treated as boolean by many scripts, and this worked in lsl: llSetAlpha(TRUE, ALL_SIDES); The equivilant does not work in lua: ll.SetAlpha(true, ALL_SIDES) In LSL the best way to toggle alpha was: llSetAlpha(!llGetAlpha(face), face); In Lua, the equivilant code is quite ugly: ll.SetAlpha(if ll.GetAlpha(face) ~= 0 then 0 else 1, face) The following almost works, and is less horrible, but it breaks if alpha gets accidentally set to some value other than 0 or 1: ll.SetAlpha(1 - ll.GetAlpha(face), face) If boolean alpha was implemented, it would become the pretty elegant: ll.SetAlpha(ll.GetAlpha(face) == 0, face) Inconsistenly, the following does work in Lua: ll.SetLinkPrimitiveParamsFast(LINK_THIS, {PRIM_COLOR, ALL_SIDES, vector.one, true}) Boolean alpha would require changing the following functions: ll.SetAlpha() ll.SetLinkAlpha() PrimParamsSetter.color() PrimParamsSetter.gltfBaseColor() Debatably, it would also affect particle and hovertext alpha, but I have no use case for that: ll.SetText() PrimParamsSetter.text() ParticleParams.alpha_begin ParticleParams.alpha_end

some ideas on how it could work: Required scripts are saved as a different type of script: modules, with a new compiler option: compile to "SLua scriopt" or to "Slua module". Modules are executed when required and return a value, with a return statement, for instance a table with functions and constants. Scripts call modules as myModule = require("Module name") , the returned value is assigned to the variable myModule , using the script's memory space. The module must be in the object contents with the script that requires it. If the module is not in the object, its running state is disabled, or it doesn't return a value, require() will return nil. Once it returns, the module is removed from memory and its variables are garbage-collected. Modules are executed synchronously, the main script is paused until the module returns. Modules don't receive events, any events that arrive while the module is executing are queued in the main script. Modules can't require other modules, only scripts can use require() .

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

This menu has 2 items for recompiling LSL scripts under the 2 old VM's. It should also have the new VM: Recompile Scripts (LSL) Recompile Scripts (Mono) Recompile Scripts (Lua) Currently, I need to open every script and change it's vm, press save, close --- Also, I noticed 3 bugs with Recompile scripts: It sets not-running scripts to running (I had them not running for a reason) Scripts recompiled to LSO2 this way do not show the correct vm when you open the script. Most of them say "LSL: Mono". This one said "SLua": default { state_entry() { llOwnerSay(llGetScriptName() + " " + (string)llGetMemoryLimit()); }} Lua (the language) scripts are skipped and not recompiled. The new "Recompile Lua" menu item should not skip those

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

Something like table.slice(src: {...}, from: number, to: number) -> {...} Or maybe table.slice(src: {...}, start: number, amount: number?) -> {...} where amount is optional and works like string.sub(...)

it would be nice if the uuid table had a generate function, similar to ll.GenerateKey . Mostly I've wanted it when I'm running slua offline, and don't have any uuid's available like ll.GetOwner Though, I could just use NULL_KEY and IMG_USE_BAKED_AUX1 and such there for testing, so, maybe this isn't a compelling reason

There are a few function that would be good to have through the viewer web socket for smoother integration with external editors. Requests - web socket endpoints List Open script editors with editor id 's (This is sort of done, but only open scripts that are also currently externally edited it might be nice to list all open ones) Get currently selected object id List content asset id, asset type, name of an object id to allow for opening scripts Open script editor by asset id to open a script from an object return editor id Get contents of open script editor by editor id Get object id, asset for an open script editor by editor id Send contents to and open editor by editor id to save Events - Things the socket can announce to subscribers New object selected - object id, inventory content New script editor opened - editor id, object id, asset, text content General Add config to allow the websocket to be opened when editing even if there are no scripts open yet, to allow for external tools to sync to viewer when it starts editing, and stay open if there are still subscriptions after, as it currently does. Given these endpoints it should be possible to make a fairly integrated setup in any editor, that would allow you to open related scripts and edit them seamlessly, and would also allow bypass the fiddly aspect of dealing with the current temp file system. For instance the current vs code plugin could list a virtual workspace that represents the sl viewer, and show a tree view of object content for the user to open and edit.

While I suspect allot of this is "to come" with the improved debugging features that have been "implied/promised" It would also be nice for scripts to be able to access some meta information about themselves. This in part came up during discussion of the new event system ( RFC ) on possible issues with os.clock() and ll.GetTIme() So I proposed a table with functions and or values for getting info about the script itself e.g type llscriptmeta = { compile : { time: number, -- Unix timestamp of script compile by: uuid, -- Who saved the script with: string -- Some version string of the compiler }, startTime: number, -- Unix Timestamp of script start (resets with ll.ResetScript) getUpTime: () -> number. -- Like ll.GetTime but with no luau caveats(resets with ll.ResetScript) bytecodeSize: number, --- Size of the bytecode in bytes ... }

The utf8 library really should be full featured with equivalent methods as found in the string library, even if that method works with utf8 strings already. The point being that as a scripter you can trust these methods work fine with utf8 strings without having to tip toe around the reference docs to make sure what might or might not or have certain caveats such as the string position index being based on bytes. The first implementation would be the easy low hanging fruit: bytecode equivalents. Methods in string library that work with utf8 strings fine already and just simply generate the same bytecode. Second would be looking at existing ll* functions and copying the code to work with the slua bindings. For example llToLower / llToUpper. Third would be writing brand new methods. The big question(s) might be whether this should be a bigger effort/coordination upstream in Luau given that Roblox has all the same problems. This also means whether these might be added even further upstream in Lua 5.6+ in the future or if Luau and even SLua continue to further diverge. There are often threads in Roblox around utf8 compatibility issues due to user input such as names and chat. SL has a big international presence, official language support and existing legacies of unicode scripting support which significantly exacerbates how critical this problem is for SLua.