llInstantMessage() throwing threat warning

[Mike Lorrey]

I did a slight modification to a simple teleport script today, to IM the user who touches the object to notify them that the permissions request they are getting is to teleport. Previously the permissions request used the touchers key without issue, but the llInstantMessage() function is throwing a red threat warning in chat which is absurd since its not an OSSL function.

Here is the code:

touch_start(integer num)
{

teleportee = llDetectedKey(0);
llInstantMessage(llKey2Name(teleportee),"Please grant permission to teleport you to the Solar System Amphitheater. Thank you.");
llRequestPermissions(teleportee, PERMISSION_TELEPORT);
}

This is the warning thrown in open chat (the script compiler compiled the script code just fine with no warnings.)

[18:41] Primitive: llInstantMessage: An invalid key was passed to llInstantMessage

All I added to this script today is the llInstantMessage code. The llRequestPermissions function handles the key of whoever touched the object just fine.

I used the llKey2Name() function to get the avatar name for the touchers key because the hovertext when you put your mouse over the function in the script dialog says that the first parameter is "string user", NOT "key user" which would be the case if the function wanted the users key. I am not sure if this is a problem with Opensim or Firestorm, but the compiler accepted the code just fine and compiled it. If using the user name was invalid for the IM function, it should have indicated that when I compiled it, not when I tried to execute it.

[Ilan Tochner]

Hi Mike,

See: https://wiki.secondlife.com/wiki/LlInstantMessage

The first parameter that llInstantMessage expects is the user's UUID, not the user's name. I don't know where Firestorm is getting it's hover info from but I suggest you use the LL functions using their official SL wiki definitions.

[Mike Lorrey]

Hi Mike,

See: https://wiki.secondlife.com/wiki/LlInstantMessage

The first parameter that llInstantMessage expects is the user's UUID, not the user's name. I don't know where Firestorm is getting it's hover info from but I suggest you use the LL functions using their official SL wiki definitions.

Is it the viewer that compiles the script or the server that compiles the script? Your response does not answer the issue of why the compiler accepted that line as valid code, it should have detected that the llKey2Name() function was feeding the wrong type of data into the function. If it is the server that compiles the code, then that is also a kitely issue.

[Tess Juel]

I don't know whether code validation in the editor is done viewer-side or server-side but you're passing a call to a function that returns a string as the first parameter and it's possible to encode a UUID as a string. A compiler that uses weak typing wouldn't be able to catch this type of error without knowing in advance whether the string that the function returns would be a valid UUID, which would explain why you're encountering this as a runtime error and not a compilation error.

[Mike Lorrey]

I don't know whether code validation in the editor is done viewer-side or server-side but you're passing a call to a function that returns a string as the first parameter and it's possible to encode a UUID as a string. A compiler that uses weak typing wouldn't be able to catch this type of error without knowing in advance whether the string that the function returns would be a valid UUID, which would explain why you're encountering this as a runtime error and not a compilation error.

Sounds like a good reason to upgrade to Yengine then...

[Graham Mills]

fwiw SceneGate has the same hovertext and likewise compiles and throws a runtime error.

Firestorm behaves exactly the same on OSCC grid.

I would guess that both derive syntax support from the viewer file keywords_lsl_default.xml in the app_settings folder so if you know what you're doing (I don't) you could fix it there.

While YEngine may well resolve this and other issues identified previously ("more strict on syntax and typecasting"), it may also break existing scripts as noted by Ai Austin in the final paragraph here.

https://blog.inf.ed.ac.uk/atate/2019/10 ... m-0-9-1-0/

[Mike Lorrey]

fwiw SceneGate has the same hovertext and likewise compiles and throws a runtime error.

Firestorm behaves exactly the same on OSCC grid.

I would guess that both derive syntax support from the viewer file keywords_lsl_default.xml in the app_settings folder so if you know what you're doing (I don't) you could fix it there.

While YEngine may well resolve this and other issues identified previously ("more strict on syntax and typecasting"), it may also break existing scripts as noted by Ai Austin in the final paragraph here.

https://blog.inf.ed.ac.uk/atate/2019/10 ... m-0-9-1-0/

I would NOT say that upgrading to Yengine would "break" scripts. It would make them nonfunctional until the authors correct the syntax errors, but that is easy enough. I will say what is ACTUALLY breaking scripts. Not just breaking them, but destroying them, making them disappear: having a script created in Kitely under xengine that you need to wear for some activity as an attachment, a hud whatever, and going to a Yengine grid, recompiling the otherwise functional script there to be able to use it there, then returning to Kitely and your script is now missing from kitelys database (it shows that it is present in the object contents, but if you try to edit it, you will be told the script is "missing" and of course it won't function.
While this is managable if you created the script yourself and keep an original copy in your inventory that you leave in an xengine condition, it permanently destroys content purchased over the Kitely Marketplace by customers who do not have mod perms to scripts, since you cannot properly recompile a script you do not have full perms to. So kitely's current policy is destroying peoples property, not just making it nonfunctional. This is tortious.

[Ilan Tochner]

Mike, Kitely Market delivers content to the grid people have the content delivered to and that content functions on delivery. If teleporting to other grids that use a different physics engine later breaks that content due to recompilation that is done on those other grids then it's not Kitely that is breaking the content.

This Yengine<>Xengine problem exists in OpenSim because the people who created Yengine didn't make sure to keep it backwards compatible with Xengine. That incompatibility is the main reason why we don't even provide the option to use Yengine on Kitely. There is nothing torturous in us not supporting software that would break people's content on our own system. If you teleporting with working content to third-party grids breaks that content then don't take that content to those grids. Or, at the very least, do what I've recommended multiple times in the Kitely Community Meetings you were present in and only place copies of content you don't mind losing in your My Suitcase folder. That way, if anything happens to the contents of your My Suitcase folder on third-party grids then you'll still have other working copies of that content in other places in your inventory that can't be broken or deleted by third-party grids.

[Tess Juel]

I don't know whether code validation in the editor is done viewer-side or server-side
...

It must be server-side, since the hover text says "key Avatar ID" in Second Life (or at least on SL Beta) and "string user" on opensim. I tested both places with the opensim version of Firestorm.

Sounds like a good reason to upgrade to Yengine then...

Isn't that the script engine Kitely uses already? But in any case, the hover text is wrong with Yengine too so it wouldn't help.

[Tess Juel]

Hi Tess,

We only use Xengine in Kitely. Yengine is a script engine replacement that isn't backwards compatible with Xengine. The existence of 2 different script engines in OpenSim causes more issues than the existence of 3 different physics engines. It's unfortunate that the people who developed Yengine didn't consider interoperability as one of their main design goals.