Just to clarify that blow job refers to early Bronze age, where some
people job was to blow into fire so to it could reach the temperature to
melt cooper ore and other elements.
;)
Ubit
On 15-Oct-19 14:49, Melanie wrote:
The important things here are:
- functions that can now be disabled should retain that option
- the defaults we have should be preserved, any sensible change to
defaults need to allow, not restrict, in order to not break things when
people load oars
- The extra file data should be processed efficiently in order not to
slow down OSSL
There are some functions that never should have seen the light of day,
like my pet peeve, osAvatarPlayAnimation, added to opensim for the single
purpose of synchronising a music band. That was before we had NPCs and I
hate this function still being in the codebase. Imagine you're in a serious
situation, maybe a business meeting, and someone uses it to play a blowjob
animation on your avatar! There is nothing the victim can do except log out.
Another is osMakeNotecard, with which a script in a tight loop can
create 10s of thousands of notecard assets. DOS attack, anyone? I may just
end up making an asset service that uses a database for notecards so they
can be cleaned up.
- Melanie
---- On Tue, 15 Oct 2019 06:06:10 +0000 Mike Higgins <mailto:
mailto:m...@kayaker.net> wrote ----
As you noticed with the Linda Kelley scripts, the reason why the LSL
function sleeps have been kept in the code is for compatibility with
scripts that counted on those delays. So they have to stay in. I believe
there are a bunch of OSSL functions that are simply duplication of LSL
functions with no sleep, a scripter who cares can use those. So I'm only
going to make one change: Add an OSSL function that tests if you can
call another OSSL function. It sounds like you would vote for me to move
the threat level settings into the osslEnable.ini file so you can adjust
some of them down. If nobody else has an opinion that is how I will do
it.
On 10/14/2019 8:53 PM, onefang wrote:
On Tue, 15 Oct 2019 00:02:41 +0100 Leal Duarte <mailto:
mailto:ajldua...@sapo.pt>
wrote:
<snip stuff about try/catch>
About adding even more code on top of this, just can say that i would
(will?) remove all this threat mess once a cleaner way (and a lot
lighter) is found to keep the needed level of protection..
I'm happy that people are now seeing that some parts of the OSSL threat
level stuff are a bad idea, and are now considering ways of rolling it
back a bit, or providing work arounds for it. It's encouraging. I
have a fork of Opensim that I call opensim-SC, and one of the main
things I had done so far was my own clean up of the OSSL threat level
mess. I had seen that previously the Opensim devs would stick to
their guns about that, so didn't bother letting the devs know about my
fork. Might be time to come in from the cold.
One of the first things people notice when using my fork is how much
faster the script engine (still Xengine) is. I managed that by
removing three things from OSSL and LL script functions. One of them
was the call to the threat level checking function for stuff that had
no threat level. Lots of things really didn't need a threat level,
like reading notecards. Another was removing the so called "LPS"
accounting. After careful inspection of the code, I found out that
"LPS" figure was not being calculated properly, and ending up in the
wrong place anyway. All it was actually achieving was slowing things
down. The major speed up I think was the last thing I did, remove
function sleeps. Back in the dim past, over a decade ago, the function
sleeps might have served a useful purpose in saving CPU resources on
Second Life servers. Now they serve no useful purpose, and obviously
just slow things down. Your average smart phone these days is probably
as fast as those ancient SL servers.
People from three grids have been testing this, and so far only one
script had issues. In Linda Kellie's Boardwalk sim, there are swans
and trains that people can ride, with these script engine speed ups,
they zoom around at ludicrous speed.
The other major thing I did to the script engine was review the actual
threat levels, and reduce a lot of them.
A function to tell you if an OSSL function will be allowed is a good
idea, but it should have been there in the first place. The
http://opensimulator.org/wiki/Threat_level crash and recover trick
didn't work on some versions of Opensim. My own work around was to
listen to the DEBUG channel from a separate script in another prim (coz
scripts running in the same prim as the one triggering the error can't
hear the error message), parse the error message, and send a message to
the script that generated it, which would then keep it's own list of
functions it isn't allowed to do. This also didn't work in some
versions of Opensim. So if the proposed idea goes through, there will
be three different methods of checking threat levels, none of which
work in every version of Opensim that is currently in use.
I'll continue my fork, since there are many other things I'm doing that
Opensim likely wont want, but you are free to have a look and grab
anything of interest.
https://sledjhamr.org/cgit/opensim-SC/?h=master
possible some functions should had been added in first plane (no im
not talking about dyn textures)
Ubit.
On 14-Oct-19 22:04, Melanie wrote:
The original intention of the LSL permissions system was to make a
script fail catastrophically. Subsequent edits have made it so that
using a not allowed function would not crash and stop the script,
which was the original, and back then intended, behavior.
The history of this is that it should be impossible for a script to
detect that it is not running in SL, as an attempt to prevent the
creation of multi-grid griefing scripts.
The threat of griefing never materialized as the SL griefers proved
to be uninterested in OpenSim.
Still we're stuck with this legacy. However, as was said, there
isn't an obvious "invalid return" for some of the functions and,
worse, some don't return a value and expect the user to assume the
call has succeded.
While I have been, at the start, an opponent of discoverability,
I've since changed my mind and I believe a querying function for
script permissions is the logical step to take. The internal code
is already able to determine permissions from a string version if
the osFunction name, exposing that would be quite trivial.
Also some "safe" functions that used to be subject to permission
checks, aren't anymore.
So this gets a +1 from me.
The donated xmrEngine, which is now YEngine, also had, at the time
it was donated, a try/catch mechanism. I am not aware of how much
of that remains after the removal of the extension APIs and the
linux-only parts that caused it to become YEngine. However, until
it, or it's successor(s) become the standard engine and any engines
not able to use try/catch are removed, the API can't really make
use of it.
- Melanie
---- On Mon, 14 Oct 2019 19:42:56 +0000 Haravikk
<mailto:mailto:mailto:open...@haravikk.me> wrote ----
On 14 Oct 2019, at 15:12, dz <mailto:mailto:mailto:d...@bitzend.net> wrote:
just an observation from a casual observer with decades of
software design experience...
Wouldn't it be more productive to wrap all OSSL function calls
in error handling so the response is "correct" regardless of the
permissions? Adding another seperate function that will ALWAYS
need to be called before any OSSL function just adds bloat,
confusion, and removes any incentive for the problem to be
handled "correctly" (looks at the forum name) OOO ya
nvm…
The problem with that is that a default return value may not be
distinguishable as an error; for example, for a function that
returns a list, an empty list might make sense, but you wouldn't be
able to tell if the return was genuinely empty, or the call wasn't
allowed.
In an ideal world we'd use C# or another language with exception
handling, as that's a much cleaner way to handle capturing of
recoverable errors. Of course it's also a lot of work.
I wonder though, how difficult would it be to expose a minimal
version of exception handling to LSL? i.e- a very basic try/catch
block (no multiple catch blocks, or catches of specific types, just
catch everything)?
On Sun, Oct 13, 2019 at 10:27 AM Mike Higgins
<mailto:mailto:mailto:m...@kayaker.net> wrote:
Yeah, there is an example of that crash and recover trick at
http://opensimulator.org/wiki/Threat_level, at the bottom of the
page.
I have done that and it works after SPAMMING EVERY AVATAR IN THE
REGION once. Which is still annoying.
On 10/13/2019 4:25 AM, Michel Beauregard wrote:
Its a good idea to have a function that test if a osl function
is
available to a owner in a specific location.
For now there is a way to test for osl function scriptwise. A
failing
osl function cause a crash of the event calling it. So what I do
is on state_entry I call a timer with a fake call to all the OSL
function(s) to be use in my scripts . If the timer failes it
means that one or any of the function I need is not allowed . And
the script simply spell out to the owner of that object that it
cant be use and abort. So at least it does not repeatedly spam
the region .
I will post an example of the script I use in my user page in
opensim if
you like more detail.
(http://opensimulator.org/wiki/User:Gimisa) . With your function
you might be able to detect the failure of the osl function call
instead of sending it to report inworld and act by sending back a
message to the script for action. Allowing me to use the reply in
any way I need instead of using timer failure.
hope it helps
GiMiSa
_______________________________________________
Opensim-dev mailing list
mailto:mailto:Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
mailto:Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
mailto:Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
