📃 SLua Alpha

Rather than having in built "freezes" in certain functions like object rez / ll email etc, which are trivially circumventable by "LINK_MESSAGE"ing another script in the same prim and having that other script swallow the delay (providing a 'burstable' limit on these calls) these could be better handled in slua by reworking how these delays are implemented - perhaps on a per prim or per script setting where these calls can be made at "no cost" up to some specific rate after which they stall or fail (for example the way HTTP requests can be performed - there is no function delay here but there is still an overall limit on HTTP requests) The work around of having often multiple 'worker' scripts that just listen for a link message then execute the call to llEmail / etc has always been a bodge, but also rather necessary one if you don't want your main server script to become unresponsive regularly, which is quite important for a simultaneous multi user server style script (e.g. providing a region wide service to all players, the main script here can not be stalled without noticable impact to the players and yet some of these functions with delays in are needed for operation). Made a longer post here https://community.secondlife.com/forums/topic/530018-of-functions-with-delays/ Since so much is changing in the lua implemented stuff we could use this opportunity to redefine or rework how these function delays work, /only/ for pure lua scripts compiled using the new lua mode, while legacy LSL to lua / LSL mono / LSL classic scripts can maintain their previous behaviour regarding delays. This would be great to avoid what is essentially a "gotcha" that new scripters sort of 'need to know' how to work around to have a performant system that needs to use these delayed calls, as well as avoiding the wasted overhead of multiple worker scripts with their overheads and the time wasted in link messaging (especially since all the worker scripts receive all link messages even though only one of them will take up the work) Would just be a great and rare opportunity to revisit a rather archaic piece of the scripting languages implementation that just doesn't really work as advertised anyway once you know of the bypass by offloading to worker scripts, not often breaking changes can be brought in to a new language checkpoint. If this isn't clear enough please let me know and I'll give some better examples or something but I assume this fairly trick is widely known.

I have just begun tinkering with SLua and I love the potential. However, one weak point of scripting in SL (both both LSL and SLua) is the ability of scripts to interface with another. As far as I know, we still mainly use LLEvents.link _message and ll.MessageLinked. One issue I have with that is that all the parameters are strongly typed. If we could pass (at least one) dynamically typed parameter, we could pass object instances along, which would make it much more powerful. To name one simple use case: let's say we have various scripts that all need to show a menu with ll.Dialog. We could have a single script that can instantiate a "Menu" object and pass it back to the calling script, which can then implement it for that script's situation and run the predefined Menu:Show. Another use case might be that when clicked, a script creates an "Avatar" object and then passes that to one or more handler scripts (based on whatever criteria prevail) that can use that object in their own logic. Perhaps there is another way in SLua but I have not yet found it in the docs, but I am of course happy to be educated further. Something like this would enable us to make much more loosely coupled and dynamic and reusable systems in SL scripting.

A way to add two or more array tables without requiring extra temporary memory. table.extend(t1, t2) Appends all elements of array t2 to the end of array t1 The array t2 is cleared and its memory released. Elements are moved directly to avoid intermediate duplication. Working like this, but without using extra memory during the process: extend(t1, t2) table.move(t2, 1, #t2, #t1 + 1, t1) table.clear(t2) -- but without preserving the allocated space return t1 end or better: table.extend(t1, ...) Appends the elements of each additional array to the end of array t1, in the order provided. The source arrays are cleared and their memory released. Elements are moved directly to avoid intermediate duplication.

SLua has no means of concatenating tables, this makes several functions designed for LSL incredibly unwieldy to use. A common practice for instance is to to loop a function call and build up a list of parameters append them to an existing list, then once done send it all to SetLinkPrimitiveParamsFast. SLua also struggles somewhat for memory and hits out of memory errors on lists that aren't incredibly long compared to LSL. Due to the table memory allocation doubling all of a sudden, which for many users is an enourmous footgun, as tabl[#tabl+1] = 1 taking their script form 64k memory to OOM is incredibly counter intuative. This leaves slua looking no better than LSL to many scripters for a very common task in SL. Until either better more 'lua' api's exist, or table memory allocation can be changed, it would be nice if the functions could accept nested tables and flatten them. Proposal ll.SetLinkPrimitiveParamsFast( 1, { PRIM_COLOR, {1,vector(1,0,0),1.0}, {PRIM_TEXT, "Text", {vector(1,1,1)},1.0}, PRIM_SIZE, vector(1,1,1) }) -- OR ll.SetLinkPrimitiveParamsFast( 1, { {PRIM_COLOR, 1,vector(1,0,0),1.0}, {PRIM_TEXT, "Text",vector(1,1,1),1.0}, {PRIM_SIZE, vector(1,1,1)} }) Would get flattened to ll.SetLinkPrimitiveParamsFast( 1, { PRIM_COLOR, 1,vector(1,0,0),1.0, PRIM_TEXT, "Text",vector(1,1,1),1.0, PRIM_SIZE, vector(1,1,1) }) This would make using SetLinkPrimitiveParams allot less painful, and also help with things like - LinkParticleSystem - RezObjectWithParams - SetAgentEnvironment - HTTPRequest This would also help aleviate the memory impact of LONG tables for set linkprimitive params, by allowing a scripter to break up their long list into several smaller ones and send them together. Not always, but 10 tables of 8 keys are 2560 bytes compared to 80 keys taking 4096 with the memory doubling tables do as you expand them. There is of course... one major caveat to this, the flattened table, while it exists needs to be be counted against the script that's running >.>

myRequestId = ll.HTTPRequest(myUrl, { HTTP_BODY_MAXLENGTH, 16384 }, "") Currently the maximum is 16384 in VM Mono and 4096 in VM LSO. In VM Luau, with more script memory, the maximum could be 32k or 64k.

The project/lua_editor viewer currently uses a bit of a hack to insert a default slua script. It would be good to clean this up along with the new script feature in the inventory. Proposal : Object content panel New script on an objects contents should default to a clean slua script THAT USES OWNERSAY not say, with an optional drop down next to the new script button to choose a new lsl script instead. While we are at it, it would be good if there was a config setting in the viewer to specify an alternate default script (from inventory?). Proposal : New script in inventory Either: - New script should default to creating a slua script - There could be 2 options New Slua Script / New LSL Script Related issues https://feedback.secondlife.com/slua-alpha/p/new-script-without-state-entry-and-hello-avatar-with-ownersay Though as Suzanna can likely no longer edit it LLEvents:on("touch_start", function(touches) ll.Say(0, "Touched.") end) ll.OwnerSay("Hello, Avatar!")

This seems to be some oversight that there is no way to actually a way to loop over the characters of a utf8 string. The roblox docs mention a utf8.graphemes but this doesn't seem to have been upstreamed into luau, so we would need our own utf8.graphemes in SLua to do the same. Graphemes make more sense into what a scripter would usually want to actually intuitively access or iterate over in a string. This is very important for any platform dealing with internationalisation and emojis. * See here for difference of the terms: https://stackoverflow.com/a/27331885 * Roblox's utf8.graphemes: https://create.roblox.com/docs/reference/engine/libraries/utf8#graphemes Per WolfGang: * https://codeberg.org/nazrin/grapheme * https://libs.suckless.org/libgrapheme/ I'm currently working on a mesh-based text renderer that needs to be able to iterate over graphemes for emojis and stuff correctly for example. But there are many other usecases like being able to properly utf8 substring without messing up graphemes such as combining characters etc.

The present system of limiting script memory on a per script basis gives scripters an incentive to create often incredibly inefficient workarounds when they want/need more memory than the limit allows, such as creating a large number of slave scripts and passing data back and forth via ll.MessageLinked. Simply increasing the limit to something more reasonable could alleviate this somewhat, but it doesn't really address the underlying problem, how to responsibly allocate memory per creation, whether that creation is a single prim, or a collection of linksets. I therefore propose the following alternative: Give each linkset a parameter adjustable by anyone with modify rights, Call it Linkset Memory Limit (LML). Default to a reasonable value, say 1 MB. Add this parameter to the collection of items that affect the linkset's LI, at a reasonable cost, say, 1 LI/MB. (I don't know if it's actually reasonable, but 1 LI/MB does make a mentally convenient conversion factor.) Per current practice let, the final LI be the max of the per item LIs. Then each script in the linkset draws memory from the common memory pool as defined by the LML. The simplest implementation of this feature at the script level would probably be to change ll.SetMemoryLimit to be limited to the currently available memory in the LML pool, with an argument of -1 meaning grab it all. This would allow the script to reserve needed memory and to free it when no longer needed. Adding ll.GetLML, llGetFreeLM, and possibly ll.SetLML (see discussion below), together with existing parcel prim count functions would constitute a sufficient set of functions. It might be possible to automate dynamically allocating memory to scripts from the common pool as needed, but I'm not prepared to say how desirable this might be. It would likely improve the use of the common memory pool, but it could greatly complicate impact and debugging of out-of-memory conditions and I'm not sure how it would work with attempts by a script to reserve needed memory in advance. This new feature would give scripting creators the ability to make efficient use of as much memory as they might need, with a clearly visible cost that prospective object owners can see and can budget against their available resources. It also give owners with linkset modify rights the ability to adjust this cost within the limits of the scripts' ability to adapt. It entirely eliminates the creator's incentive to use inefficient workarounds that are costly to sim resources and performance. It gives creators a reasonable incentive to limit their use of memory in order to improve the market appeal of their products and/or the land impact of creations they use themselves. It doesn't particularly affect the case for using HTML and external servers for very large or shared datasets when HTML delays are acceptable. Since the LI of worn objects is not currently counted against any budget, in order to keep worn object impact under control, it would be necessary to have a per agent LI limit as well. This limit would probably apply only to the LML LI, but grins one might possibly make the case for applying it to other LIs as well (no doubt with much cussing by our more elaborately decked out friends). A higher agent LML LI limit could become another perk of higher account levels. Since dividing and merging of linksets usually occurs at creation time, and we want creators to manage this process, I would not recommend elaborate algorithms for managing the allocation of LML on merge or divide. It probably suffices on merge to keep the LML of the root of the merged object. On division, it probably suffices to give objects with a new root the default LML. Allowing a script to change the LML of an object would mean that the script could be dynamically changing the LI of the object. This would have both pros and cons. Pros such as allowing a single script to adapt the object to present limits or to set the LML of a newly divided/merged/created object to reasonable values. Cons such as removing from the owner complete control over the LI of their rezzed out objects, and making marketplace data about LI less reliable. Perhaps a reasonable compromise would be to limit such functions to objects owned by the parcel owner per other parcel functions. The prospect and limitations of any ll.SetLML function definitely needs more discussion. It would be nice if this feature also applied to LSL scripts either when compiled to Mono and to the Lua VM, or possibly just when compiled to the Lua VM. If automatically applied to existing content, it would probably break a significant number of existing inefficient workarounds and other instances where the number of 64kb scripts in the object exceeds 16. (Beware of furniture with nPose and AvSitter systems and many seats.)

Currently to get the magnitude of a vector v we might code local v = vector(1,2,3) local m = vector.magnitude(v) One might reasonably expect local m = v:magnitde() to work, and similarly for other functions that might reasonably act like methods such as local dp = v1:dot(v2) and so on. It does not work because a vector instance's metatable is not set to the functions in vector . Seems to me that it should be, so that vectors can be treated like any other SLua object or smart table. I was somewhat surprised to find that vector is implemented as a native type rather than as an ordinary Lua table / object, with the functions in its metatable and so on. I would suppose that this might be because Luau already did it this way, or because of some performance concern. Curious. In any case, since, in my view, any competent Lua / SLua scripter is going to use objects and the : notation, vectors (and quaternions and any other built-in structured types) would be far better if they worked like objects with metatables. Thank you for your consideration and I'll be happy to assist with testing or Lua code if it would be useful.

Constants It might be good to have constants for the event names LLEvents:on(EVENT_TOUCH_START, handler) or LLEvents:on(TOUCH_START_EVENT, handler) Though the latter does break the general convention LSL has of prefixing constants, so may be less desirable. Aliases While at that, as mentioned here some aliases would be nice, to allow for nicer code read, constants could be used or true aliases could be provided, but that may not be worth it. LLEvents:on("on_rez", handler) -- to LLEvents:on("rez", handler) -- or LLEvents:on(EVENT_REZ, handler)