LL functions that return "integer/boolean" could return lua boolean
planned
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
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
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