llInstantMessage() throwing threat warning

[Graham Mills]

My bad, I think you're most probably right. Having looked at the .xml file more closely, I can't see how it could generate the tooltip I see on Kitely. What's confusing is that the file actually has a tooltip text defined (and identifies the first argument as a key).

Definitely XEngine on Kitely according to osGetScriptEngineName.

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.

[Graham Mills]

Turns out this was the subject of a dev chat a few years back.

According to Ubit "correct way should be, from file, then overriden by region provided information."

Seems to me, as Tess said, what we see currently is region-provided without moderation by keywords_lsl_default.xml ?

Quick search in server files identified three files that mention llInstantMessage (see image for example). However, llKey2Name also specifies a string argument but correctly shows key in the FS tooltip.

http://opensimulator.org/wiki/Chat_log_ ... 2019-10-15

[Tess Juel]

We only use Xengine in Kitely.

In that case both Xengine and Yengine have the error. I tested it both on my Kitely region and on Opensim's Sandbox Plaza III with the same result.

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.

Yes, I can imagine it is. The optimal physics model for a static non-physical object is the same for all three engines, the difference is only about which flaws they forgive and of course that annoyingly misleading physics weight/LI the viewer comes up with for some objects with ubODE.

With the two script engines on the other hand, the same functions and parameters can give different results on different simulators/grids and that's not good. The goal with Yengine was to make OSSL fully compatible with LSL and that makes sense but it probably wasn't the right priority.

[Graham Mills]

As I understand it, YEngine's origins were on a closed grid so it likely made sense to priorititze compatibility with SL over XEngine.

[Tess Juel]

As I understand it, YEngine's origins were on a closed grid so it likely made sense to priorititze compatibility with SL over XEngine.

You may be right.

For those who don't know the history behind this, in 2015 the biggest and best known commercial closed grid went belly up and its developers went to and more or less took over the official opensim dev team, bringing all their code with them. The merge of the old OS 0.8 and the code from that grid is essentially what OS 0.9 was all about and many of those changes were rushed through with little or no triaging. The Yengine wasn't actually added to opensim until OS 0.9.1.0, two years later, but I believe it's still part of that hurried batch update.