> On 17 Oct 2019, at 16:15, dz <d...@bitzend.net> wrote:
>
> Haravikk..
> In my experience writing scripts that use OSSL functions ( NPC scripts
> mostly), the possibility of integrating a "default" event handler is
> virtually zero.
> You have to remember "normal" processing described by the O.P is
> script failure and spam everyone in the region..
I fail to see how requiring the scripter to add an event handler rather than an
entirely separate state is different here?
In both cases the scripter has to add something in order to signal their desire
to use the new behaviour, and then to take advantage of it.
The difference is that an event handler can be added to any existing state
(most scripts only have one) and it's entirely up to the scripter what they
want to do with it. They can even switch to a different state themselves.
The added advantage of an event handler is that it could have data passed into
it, for example, if the handler took the form:
error(integer error_code, string error_message)
Now we have an error handler that can receive a code indicating the type of
error, and the string message that would normally be spat out to the entire
sim, and can use (or ignore) these as we please.
> I would also argue against requiring the coding of an event handler as
> the default, since 80 % of the scripts I use most often are not
> complicated enough to have one defined.
I'm confused by this statement; literally 100% of useful scripts have at least
one event handler defined.
> I'm all for people improving the idea and getting a consistent ,
> simple, and even useful design for OSSL spam, It just seems like with
> some slight effort we could have LSL error handling for all scripts.
We already have error handling for all scripts; it just happens to currently be
shouting messages across the sim 😝
IMO that should remain the default behaviour, because as as obnoxious as it is,
it's easy to notice. If you want to block existing scripts from doing this,
then it makes more sense to have a simulator option to disable these messages
(or change the channel they're spat onto). For actually handling the errors
properly, it should be up to the scripter to do it, and ensure its done the
right way for their script.
> On Thu, Oct 17, 2019 at 8:52 AM Cinder Roxley <cin...@alchemyviewer.org>
> wrote:
>
>> What do you imagine will happen if an error is raised inside of the OnErr
>> state?
>>
>>
>> On October 17, 2019 at 9:17:40 AM, dz (d...@bitzend.net) wrote:
>>
>> While I agree that the on-error (event) might be the more elegant
>> solution, it suffers the downside of requiring significant additional
>> coding in the LSL script.
>> It is true that state changes are disruptive, but we are comparing it to a
>> solution ( NOW) where the program fails and spams everyone in the region.
>>
>> My expectation is that a very large portion of the scripts using OSSL
>> functions wouldn't be very useful if the OSSL function is not permitted,
>> so failure is a valid result.
>> Scripts designed to fail in a limited way can put the call to the
>> function in a "SETUP' state which would allow them to easily set a "do
>> the OSSL call" flag (TRUE/FALSE) and restart initialization.
>>
>> retrofitting scripts with generic [example] bit of code for the onErr
>> state is relatively simple cut and paste..
>>
>> state OnErr
>>
>> {
>> state_entry()
>> {
>> llOwnerSay( "OSSL call failure");
>> }
>> }
>>
>>
>> This simple code block can also be easily "stubbed out" as a default
>> action in the script engine for processes that do NOT include the state
>> definition as written.
>> Trying to design a default event handler that adds this functionality
>> seemed to me like it might be too contentious and hard to get agreement on.
>>
>> I agree... this isn't the best solution.. But is is SIMPLE, works for
>> ALL scripts, and is an opportunity to get a LSL code example out
>> demonstrating the proper use of script states,
>> I think it is certainly more elegant that adding an additional
>> function call that is required BEFORE EVERY OSSL function.
>> It is certainly less likely to create as many problems as requiring 2
>> function calls and/or modifying the script engine to support try/catch
>> blocks..
>> If you REALLY HAVE TO muck with the script engine... why don't you
>> give us $INCLUDE. then the retrofit for existing scripts can be
>> "$INCLUDE ErrState.lsl" .....
>>
>>
>>
>> On Thu, Oct 17, 2019 at 1:37 AM Dahlia Trimble <dahliatrim...@gmail.com>
>> wrote:
>>
>>> Perhaps you mean an on_error() event instead of a state change? An
>>> unexpected state change can be difficult to recover from (closing
>>> listeners. timers, and whatnot, and not knowing which state was active
>>> before the change occurred).
>>>
>>> On Wed, Oct 16, 2019 at 5:55 PM dz <d...@bitzend.net> wrote:
>>>
>>>> You miss the point...
>>>>
>>>> LSL programs function in States... most folks only ever see the
>>>> DEFAULT state label and ignore it,
>>>> What I am suggesting is that the new LSL programs Include a ONERR
>>>> State that would be invoked in the event of a OSSL call failure
>>>> This allows the LSL program to decide if it is a fatal error and (
>>>> maybe ) OwnerSay the returned value, or (maybe) ignore it and
>>>> return to the Default state with the call disabled.
>>>>
>>>> Obviously there needs to be a "default" ONERR state defined for
>>>> programs that do not explicitly define one...
>>>>
>>>> But the error handling required in the script engine is trivial,
>>> trigger
>>>> the ONERR state in the calling program ( and maybe pass a code/string)
>>>> No additional lsl functions are required you just push ONERR into
>>> the
>>>> State and call the Change State function that exists
>>>>
>>>> This approach has the advantage that it will also work for scripts
>>> that
>>>> do NOT call OSSL functions, but that may otherwise Fail for Unknown
>>>> reasons..
>>>>
>>>> On Wed, Oct 16, 2019 at 10:43 AM Haravikk <open...@haravikk.me> wrote:
>>>>
>>>>>
>>>>>
>>>>>> On 16 Oct 2019, at 16:45, Kevin Cozens <ke...@ve3syb.ca> wrote:
>>>>>>
>>>>>> On 2019-10-14 11:53 p.m., dz wrote:
>>>>>>> Why don't you just have the default action of the " failed " call
>>>>> invoke a
>>>>>>> standard user defined error state.
>>>>>>
>>>>>> Interesting idea. One aspect of that is that it should be able to
>>> know
>>>>> which state the script was in prior to an error being triggered as it
>>>> might
>>>>> not be the default one for those scripters who know you can have
>> other
>>>>> states.
>>>>>
>>>>> As already mentioned, the problem with just returning default values
>> is
>>>>> you can't necessarily test these for an error, as some methods don't
>>>> return
>>>>> anything at all, while others may return empty lists/strings during
>>>> normal
>>>>> operation. There's also the possibility of there being scripts that
>>> were
>>>>> written in the expectation of failing if a function isn't enabled, so
>>>>> changing the behaviour means they'll suddenly continue when they
>>> weren't
>>>>> supposed to, potentially resulting in unexpected/unpredictable
>>> behaviour.
>>>>>
>>>>> ...
>>>>> _______________________________________________
>>>>> 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
>>>
>> _______________________________________________
>> 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
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
