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: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: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:open...@haravikk.me> wrote ---- >>> >>> >>> >>> >>>> On 14 Oct 2019, at 15:12, dz <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: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: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
