📃 SLua Alpha

my quats maths is uh weak so feel free to correct me, but to do a inverse of a quaternion I would have expected the unmary operator to do that, however it negates all parts, instead of only negating the vector parts (x, y, z) https://github.com/secondlife/slua/blob/main/VM/src/llsl.cpp#L1031-L1039 Could this be changed to be a conjugation operator instead perhaps?

I was trying to encode a table for debugging and it was just { [50] = true } Maybe an object meta table would be useful? lljson.object_mt To mark a sparse array to be encoded as an object instead? In the end i got around it using slencode but it might be useful to be able to output normal json with number keys, as a json object.

I was asked yesterday which math functions one should use Which made me realized, that having 2 ways to perform the exact same thing is going to lead to continuing confusing on is there a difference or now. Should duplicated functions like the math ones - ll . Abs - ll . ACos - ll . Floor - ... Or vector - vector . magnitude - vector . normalize - ... Be removed from the ll table, they should still be available in llcompat i think, but having them in "the main library" is more than likely confusing to less familiar users as to why they are in 2 places. Maybe they should be redirected to an error message instead? and removed from the docs? This would need to include work adding documentation to https://create.secondlife.com for the standard libraries, but that has already been brought up as well.

ll.LinksetDataRead("key") and ll.LinksetDataReadProtected("key", "pass") both will return an empty string if trying to access a stored value that doesn't exist. Which is not "nil". Can we get it so that if a key pair does not exist in the LSD store that the return is actually a "nil" type instead? It would also return nil on a protected key with a bad "pass". We have access to the nil data type with SLua now, and it'd be more logical for a non-existent key to return nil for a simple boolean test. IMO. Just an idea at least. Added thought: maybe have "llcompat" have the return still be a zero length ("") string for, well, compatibility sake.