integer "type casting" in "lists" for ll functions
complete
WolfGang Senizen
Secondlife functions like
ll.GetObjectDetails
, ll.SetLinkPrimitiveParams
, ll.ParticleSystem
that take lists as arguments require integer and booleans inside them to be converted to a userdata integer object.This is extremely cumbersome for basic use.
An example
ll.ParticleSystem({
integer(0),
integer(bit32.bor(0x100,0x400,0x008)),
integer(9),
integer(0x01),
integer(17),
1.0,
integer(1),
vector(0.8,0.0,0.0)
})
It would be great if luau could be setup to allow for the use of normal number types and booleans.
Like this
ll.ParticleSystem({
0,
bit32.bor(0x100,0x400,0x008),
9,
0x01,
17,
1.0,
1,
vector(0.8,0.0,0.0)
})
Correctly "cast" constants would improve this somewhat, but still leaves allot to be desired.
For now I have made myself a function to "auto cast" these for me, but that is sub optimal at best...
function table2FuncList(tab)
for k,v in pairs(tab) do
if type(v) == "number" and math.round(v) == v then
tab[k] = integer(v)
elseif type(v) == "boolean" then
tab[k] = integer(v and 1 or 0)
end
end
return tab
end
Log In
H
Harold Linden
complete
This should be handled in all the cases we're aware of now, let us know if there are any stragglers!
Signal Linden
Update: We're pushing out some fixes to make "integer-like" values acceptable in most cases where
ll*()
functions currently demand an integer within lists. Any number where floor(val) == val
and val
is within int32
range will be acceptable, as will bools.WolfGang Senizen
Signal Linden
If this went live today, we have some odd breaking changes
LSL Mono scripts are error'ing with
llSetPrimitiveParams error running rule #1: non-integer rule.
So are most of the lua scripts I have, even after a recompile.
llGetObjectDetails
is returning empty lists/tables in both lua, lsl/luau, monoRuby Maelstrom
Signal Linden
I've found the following casting issue today also involving llSetPrimitiveParams:
PRIM_LINK_TARGET, 2,
in SLua doesn't automatically cast to an integer, throws the error llSetPrimitiveParams error running rule #2 (PRIM_LINK_TARGET): arg #1 integer expected but float given.
PRIM_LINK_TARGET, integer(2),
works fine.H
Harold Linden
WolfGang Senizen
Yep, unfortunately fixing this issue has required some fairly deep surgery all over the codebase in places that can't currently be unit-tested and haven't been touched in 20+ years, so we've had a couple of bugs :P .
We've added code to optionally treat
numbers
within INT32_MIN<-> INT32_MAX range where floor(num_val) == val
as integer
-like within lists, but only in cases where the function demanded integer
s and only when SLua is used._Most_ of the issues should be worked out with the latest simulator version we rolled today, have you noticed any issues since?
WolfGang Senizen
Harold Linden
ll.Say(0,typeof(HTTP_METHOD))
ll.HTTPRequest("<valid_url>",{0,HTTP_METHOD,"POST"},"")
says
integer
in chatthen errors with
HTTP parameter key 1 is not an integer
Doens't work if i pass the number 0 either as thats HTTP_METHOD's "value"
H
Harold Linden
WolfGang Senizen
Oof, okay, we'll try to get that fixed for tomorrow, accidentally flipped an
if
!Once all the typecasting nonsense is squared away, we're going to flip all the
integer
constants over to being number
s, so apologies if anything breaks!H
Harold Linden
Alright,
ll.HTTPRequest()
options should be fixed in the latest roll, please let us know if there are any more issues with number
->integer
typecasting within lists!Frionil Fang
Harold Linden
The very least ll.SetLinkPrimitiveParamsFast does not accept any integer values without explicit casting. The situation hasn't changed from earlier.
WolfGang Senizen
Harold Linden
ll.JsonGetValue('[1,2,3]',{0})
and
ll.JsonSetValue('[1,2,3]',{0},'9')
Also do not work with numbers at the moment and need integer casting
H
Harold Linden
Frionil Fang
Do you have an example of a call that doesn't work?
ll.SetLinkPrimitiveParamsFast(99, {PRIM_LINK_TARGET, 0, PRIM_COLOR, -1, vector(1,0,1), 1})
works for me.H
Harold Linden
WolfGang Senizen
Good catch, we'll get that one sorted!
Frionil Fang
Harold Linden
This is my bad, an accidental division instead of floor division while computing a value for PRIM_LINK_TARGET. Disregard, seems fine now!
Thornotter Resident
Appreciate the hard work on the fixes so far from the Lindens!
Hopefully some sort of "type casting wrapper" can be used internally for the remaining integer requirements.
Using the Lua numeric natively for all the ll* functions would make coding a lot simpler and avoid technical debt carrying into the future. Having an integer type is going to confuse every new Second Life Lua developer for years and years to come - they'll think it's a native part of Lua. Better to try to get rid of it now, if possible. 😊
Kristy Aurelia
While in the area, it might be worth considering adding support for
nil
as keep current value
especially for ll.SetLinkPrimitiveParams
that take texture UUIDs as parameters. As you know - keep existing/do not change
and similar has been much requested feature for LSL so this might be a great opportunity to introduce it.WolfGang Senizen
Kristy Aurelia
👍👍👍👍👍👍👍👍👍👍👍👍👍👍�
Signal Linden
in progress
Thanks for the report, WolfGang Senizen. We will be partially solving this in a release later today.
From our engineers:
> bit32 operations now return an integer if all arguments were integers, but the core issue of list typing for particle and prim param functions still needs to be dealt with.
Maestro Linden
The integer casts in your example are _mostly_ unnecessary; this works for example:
ll.ParticleSystem({
PSYS_PART_FLAGS,
integer(bit32.bor(PSYS_PART_EMISSIVE_MASK, PSYS_PART_RIBBON_MASK, PSYS_PART_WIND_MASK)),
PSYS_SRC_PATTERN,
PSYS_SRC_PATTERN_DROP,
PSYS_SRC_BURST_SPEED_MIN,
1.0,
PSYS_PART_START_COLOR,
vector(0.8,0.0,0.0)
})
It does seem like
bit32
requires an explicit cast to integer for the interpreter to be happy. The bitwise operators from Lua 5.3 would be a lot cleaner to use if they were working, and should return an integer already: https://www.lua.org/manual/5.3/manual.html#3.4.2WolfGang Senizen
Maestro Linden
Yeh this was before the constants were added
We still need to ternary or "cast" bools/numbers if we want properties to be decided by logic or math which is going to keep leading to gotcha's forever
Lua is a "clean slate" it'd be nice if it could start as clean as possible.