LL functions that return "integer/boolean" could return lua boolean
inĀ progress
WolfGang Senizen
Common usage of methods like
ll.AgentInExperience
etc in lsl is to just stick them in an if directly as 1
evaluates true
As this is not the case in lua, it would be good for the relevant functions to return booleans.
I have scoured the function list and updated the wiki to include all the ones I could see on a first pass through.
ll.AgentInExperience
ll.DerezObject
ll.EdgeOfWorld
ll.GetScriptState
ll.GetStatus
ll.IsFriend
ll.ManageEstateAccess
ll.SameGroup
ll.ScaleByFactor
ll.ScriptDanger
ll.SetMemoryLimit
Were missing and I added them, listed separately in case they are "wrong"
ll.DetectedGroup
ll.IsLinkGLTFMaterial
ll.OverMyLand
ll.SetRegionPos
ll.VerifyRSA
Log In
H
Harold Linden
marked this post as
inĀ progress
I've got this working in development for functions, going to see if I can get it working for prim params / media / whatnot things that return "bool-like" values in lists as well.
SuzannaLinn Resident
Will TRUE, FALSE and other constants be changed to boolean too?
WolfGang Senizen
SuzannaLinn Resident
Maybe
TRUE
and FALSE
won't, mostly so you have simple 1
's and 0
's to use when talking to lsl scripts?Once this is "feature" done you should never need to use
TRUE
or FALSE
except when sending something to an lsl script.But on the flip side, I can see them being big gotcha's for new users.
H
Harold Linden
SuzannaLinn Resident For posterity, TRUE / FALSE will be completely gone to prevent confusion with the real boolean literals in SLua. If you need the TRUE / FALSE constants (maybe because you're transpiling LSL) you'll need to define them yourself.
SuzannaLinn Resident
Harold Linden
Thanks Harold! I'm happy that they will be gone.
No, I don't need them, I'm transpiling them to true/false and sometimes to 1/0 depending on how the variables are used.
And I guess that, being TRUE/FALSE undefined, in SLua in VS Code the Luau analyzer will show a warning if we try to use them.
H
Harold Linden
marked this post as
planned
We've got these functions tagged internally as having "boolean semantics" for the return value. We'll address this around the same time as we change the index semantics for index-like function parameters.
H
Harold Linden
A handful of the functions you listed were missing from our internal list, so I've added them, thanks!
Kristy Aurelia
I'd say that any function with
is
, does
, can
or anything else that turns the function name into a question with a yes/no answer should be a boolean type and return true/false. ll.IsFriend
would be the primary example of that... unless there are plans to add "maybe friends" in the future :D