The threat levels are obsolete and they have been superseded by the
Allow_= lines in the osslEnable.ini initialization file. Every
region reads a copy of this file when it boots. If there is an
Allow_...= line for a function, that can allow region owners, estate
managers, gods, parcel owners, s
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
ke
Ubit would you care to clarifiy
" ( the C# scripts was a example i just had to kill ) "
Its true that in official release 090 C# as XENGINE scripting language did not
compile anymore .
But I notice that in release 0901 C# compiling / running was allowed again .
Opensing C# as scripting sou
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
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 mes
> On 17 Oct 2019, at 17:39, dz wrote:
>
> The suggestion was to add a default OnErr state to the script engine so
> that it would provide the desired functionality to all programs,
>
> This would mean that no additional code would be needed in any program to get
> the default "spam to me
Cinder
I wasn't offering a solution, I was offering a suggestion,
Haravikk..
The suggestion was to add a default OnErr state to the script engine
so that it would provide the desired functionality to all programs,
not just those that used ossl calls. This would mean that no additiona
> On 17 Oct 2019, at 16:15, dz 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
>
On October 17, 2019 at 10:16:11 AM, dz (d...@bitzend.net) wrote:
Cinder..
Hadn't gone there it could be (inifinetly) problematic...
Seems like that hole is much smaller than all the other "its ok to fail
silently ..forever" features in the script engine.
An incomplete solution is worse than n
Cinder..
Hadn't gone there it could be (inifinetly) problematic...
Seems like that hole is much smaller than all the other "its ok to fail
silently ..forever" features in the script engine.
Haravikk..
In my experience writing scripts that use OSSL functions ( NPC scripts
mostly), the p
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 s
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 L
> On 17 Oct 2019, at 01:55, dz wrote:
> You miss the point...
Sorry yeah, I think I misunderstood, thought we were back on return values.
In that case though I think I agree with Kevin and Dahlia that it might be
better to have an error() event, rather than a special state. With an error()
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 every
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 wrote:
> You miss the point.
15 matches
Mail list logo
