I agree that many functions are dangerous, and some grid owners may
shoot themselves in the foot by enabling them. But I am talking about
writing scripts that behave in a professional way, so I can hand them
out for lots of people to use. If I wrote a phone app that popped up
internal error messages in some locations, this would be considered very
unprofessional and people would down-vote my app and stop using it. Most
programming languages have a try/catch (or on_error) flow control
construct, but LSL does not. I would love to add such a construct to LSL
but I do not have the skill to add that to the language. (I'm of the
opinion that a new error event rather than an error state is the way to go).
I do have enough skill to add an osPermissionToCall function that
returns some information about the OSSL functions. I agree this is not
ideal, but I could write the code for this function and submit it to the
Devs, saving them from needing to do this trivial task and saving them
from the more difficult task of adding error catching to LSL. Ubit tells
me he would reject this try-before-you-call submission. But I assume he
does not have the time to do the better option of adding an on_error()
state to the language. The result is that there is no way for us
scripters to write professional programs in OpenSim.
Here is the scenario I am looking at: I write a useful script that
people want to use as they hypergrid around. I thought it was safe to
call osGetGridName which seems an innocuous function and will probably
be allowed everywhere. But it turns out that osGetGridName has a
"moderate" threat level and some places, (most notably LBSA Plaza in
OSGrid), have the threat level set to "Very Low" and do not have an
“Allow_” line to override this for osGetGridName. So my script works
most places in the Metaverse, but fails and pops up messages when one of
the users of my script shows up there. I would love to catch that error
and do something reasonable with it. But LSL has no way to do this and
the developers are resisting alternative ways to do this. (In the case
of osGetGridName, I could catch the error and substitute “OpenSim” as
the grid name, or have the script tell my users “Sorry, I can't tell
where you are now”).
There was a secondary issue that when osGetGridName fails, it not only
popped up an internal error message, but it sends that message to every
avatar in the region. Ubit has thrown me a bone by adding an option to
the INI files that suppresses this behavior and only sends the message
to the user of the script. This has several problems: 1) Note that it is
the user of the script that gets the message, not the scripter. 2) Most
of my users and most of the avatars that get this message are that:
USERS, not grid owners who have the power to change the INI file. Since
they can't effect the outcome, they will stop using my script. And all
scripters like me will just stop calling ANY of the OSSL function in the
scripts we hand out. Even the innocuous looking ones. And all the effort
that the Devs have spent on writing the OSSL functions will have been
wasted.
Imagine that I write a phone app that works fine on the SPRINT network
but pops up internal error messages when you are roaming on AT&T. But
then it paws through my contact list and also sends a copy of that
incomprehensible error message to all my friends. Ubit has given me
equivalent of a tool that can stop that last behavior, but only if
SPRINT and AT&T change some internal flag on their servers. Unlikely to
happen. People are still going to get error messages and stop using my
phone app.
Then there is an additional problem: Currently there is no way for an
osPermissionToCall function to know what the threat level is for any of
the other OSSL functions. That threat level is hard-coded into each
function. Ubit resists moving that information to a central location in
the code. He also resists moving this information into the INI files.
But I still want to find a way to write professional scripts on OpenSim.
So if you are still reading this Ubit: Would you accept a patch with an
osPermmissionToCall function that was completely self contained and did
not require changing the location of the threat level values? For
example, the osPermissionToCall functioin could have a local table of
all the other functions and their threat levels. This might introduce
bugs if threat levels ever change, but that seems unlikely.
On 10/17/2019 8:10 AM, Leal Duarte wrote:
Well lets try put some perspective on this...
The problem is not how hard it is to detected and handle disabled
functions
The problem is WHY are you using them !!!
See OSSL got a lot a functions in time and for very different reasons.
Many are there because they are just funny/useful on very specific
regions or cases.
Once the allow control was introduced, that got worse, because as dev
in can just not care, i just flag a specious feature as SEVERE,
ESTATE_OWNER only. And just let you change it and shoot your own feet,
or worse someone else feet...
And in many cases you are just doing that. ( the C# scripts was a
example i just had to kill )
see a very simple and useful(?) example
osGetNotecardLine(..)
none of that Dataserv mess of llGetNotecardLine(..) right?
well wrong.. Dataservice is need because the notecard may be on a
assets server on the other side of the world...
and not using it will stall the engine thread, potentially all of then.
Why do i see its errors at osgrid LBSA ?
A lot more examples, but you got the point.
When one writes a script, one must take in consideration its target
audience..
you can't use osSlerp() if you want it to run at current Kitely, can
you?
So issue is to identify a set that should be universally supported,
and everyone make the effort to support it.
...
Ubit
On 17-Oct-19 15:17, dz wrote:
......
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
