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
