šŸ“ƒ SLua Alpha

General discussion and feedback on Second Life's SLua Alpha
The case for per script random sequences with math.randomseed.
Having math.randomseed start a consistent pseudorandom sequence in each script when calling math.random allows saving and restoring, or transmitting any procedurally generated object simply by storing, recalling, or transmitting the seed, assuming knowledge of the procedure used to generate the object, be it an instance of a puzzle, a maze, a level in a game or whatever. Without this, one is obliged to either save, restore, and/or transmit potentially a great deal of data, or to create one's own pseudorandom number generator that does not depend on math.random. Also, when debugging a script, being able to repeat a psuedorandom sequence to get consistent results among trials can be invaluable when dealing with intermittent faults and tracking down uncommon errors. I like the idea that if math.randomseed has not been called, that the effective seed is itself random as is presently the case. Nevertheless, for the above reasons, I feel that it is valuable to be able to stipulate a seed that applies specifically to the script in question and does not affect and is not affect by sequences being generated by any other scripts concurrently running. On possible option that might be less painful than completely replacing the current implementation, could be to add a second math.rand and math.randseed pair that performed as described above, using a relatively simple, fast algorithm that might not be guaranteed to be quite as well randomized as math.random, but that is adequate for randomized procedural object generation.
0
Ā·
Feature
Always treat both 0 and 1 as root prim
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})
3
Ā·
Feature
SLua functions to replicate lsl's (integer) and (float) casts
LSL has these casting functions. They are not exposed directly in SLua. Here's what I've been replacing them with: (integer)x -> math.modf(tonumber(x) or 0) (float)x -> tonumber(x) or 0 (string)x -> tostring(x) (vector)x -> tovector(x) or ZERO_VECTOR (rotation)x -> toquaternion(x) or ZERO_ROTATION (key)x -> touuid(x) or NULL_KEY My (string) , (vector) , and (rotation) replacements seem to behave identically in all cases I've thought of. My (key) replacement behaves identically in all cases I actually care about. It's behavior doesn't match when the string is not a valid uuid, but, I actually prefer the new behavior, so I'm happy with the replacement. However, the (integer) replacement is a bit cumbersome. Additionally, (integer) and (float) have some very convenient behavior when you're parsing real notecards that aren't trivial to replicate using the luau standard library. My replacements get close, but don't behave the same in all cases: default { state_entry() { llOwnerSay((string)((integer)"0xf")); // 15 llOwnerSay((string)((integer)" 99.5 red baloons")); // 99 llOwnerSay((string)((float)" 99.5 red baloons")); // 99.500000 llOwnerSay((string)((float)" -99e2 red baloons")); // -9900.000000 }} In SLua, we still have indirect access to this behavior via ll.List2Integer and ll.List2Float : print(ll.List2Integer({"0xf"}, 1)) -- 15 print(ll.List2Integer({" 99.5 red baloons"}, 1)) -- 99 print(ll.List2Float({" 99.5 red baloons"}, 1)) -- 99.5 print(ll.List2Float({" -99.5e2 red baloons"}, 1)) -- -9950 print(tonumber("0xf")) -- 15 print(tonumber(" 99.5 red baloons")) -- nil print(tonumber(" -99.5e2 red baloons")) -- nil print(tonumber("-99.5e2")) -- -9950 But it would be nice to have a direct conversion, or even better, one that replicated all the oddities of the lsl casts, but returned nil rather than 0 on failure. Also, such functions might be necessary for the future LSL -> SLua transpiler
4
Ā·
Feature
Ā·
planned
Load More
→