Been lurking for quite a while, and I have to ask, Mel mentioned that the threat warnings were created to protect against a griefer threat that never materialized. If the perceived threat never happened, why are we keeping the threat levels at all? Keeping them is the same sort of illogic for keeping a government agency funded and operating despite having nothing to do, like regulating buggy whips. How about we turn this stuff off completely? I don't need to deal with OSSL functions if I wanted to grief opensim, theres plenty of LSL functions I could use to bring a grid to its knees if I wanted to. Furthermore, the main threat in opensim, the problem of copybotters, the devs do absolutely nothing about, so you cannot claim to be protecting us against a nonexistent threat when you are doing nothing about a real threat.
On Thu, Oct 17, 2019 at 3:51 PM Dahlia Trimble <dahliatrim...@gmail.com> wrote: > In SL we used to set up error event handlers with a listener on > DEBUG_CHANNEL. Errors will still show in red on the script debug window but > you're script will be able to be aware of the error(s). I don't recall if > I've ever tried it on OpenSImulator but I'd be surprised if it didn't work > there also. > > Users don't usually see the red text as most keep the script debug window > open. > > On Thu, Oct 17, 2019 at 11:05 AM Mike Higgins <m...@kayaker.net> wrote: > > > 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 > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > -- Mike Lorrey CEO Galactic Systems, Inc bntholdi...@gmail.com <m...@tokens.vc> International Spaceflight Museum m...@ismuseum.org Skype: michael.lorrey LinkedIn: https://www.linkedin.com/in/mikelorrey _______________________________________________ Opensim-dev mailing list Opensim-dev@opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
