[Opensim-dev] new LSL state to implement

[Melanie]

Hi,

XEngine provides an extensible language system. DotNetEngine 
currently doesn't. There is no interface to query the existence of 
such modules, but it could be implemented as an osFunction.

Of course, your script could still come to a grid without OS 
functions (SL) or with OS functions disabled (Mine).

It would still fail in those cases.

TBH, i believe the approach is wrong.

I think scripts that are meant to be portable should be written to 
use the guaranteed subset of functions that are always available, 
and scripts tied to specific functionality at grid level should be 
limited to that grid, or failure should be accepted, if not 
restricted in that way.

But that's just my opinion :)

Melanie


Lc wrote:
> well, no hope then :/
> 
> Last question for my knowledge : is it possible to add more OSfunctions
> /external functions in the language without modifying the Core, ie
> i create a plugin (dll) called Mylibs.dll. Inside this module, i made a
> function OsMyfunction().
> 
> First, is this "plugins" architecture implemented
> and how a script could know if a certain module exist on the sim ?
> 
> The idea behind that is doing something like that:
>   i create a "master prim" that check the existance of those module.
>   if the module exist, i rezz a prim containing the real scripts that call
> Osmyfuntion() otherwise nothing in done.
> 
> 
> 
> 
> Thanks
> 
> SM
> 
> 
> On Tue, Jul 29, 2008 at 2:45 PM, Melanie <melanie at t-data.com> wrote:
> 
>> Hi,
>>
>> you can't do that on a script level. That is done by the compiler.
>> LSL is compiled, not interpreted. If it contains os* functions
>> anywhere, it will fail to compile in SL.
>> There is no way to compile the script and then, at runtime, to
>> decide that we don't want to execute the code path that contains the
>> os functions. You would never get to that point in the first place.
>>
>> I see little value and lots of potential harm in runtime grid
>> discovery. Still, if people want it, it will be implemented and I
>> will even help. It's all about openness. I won't prevent anyone to
>> implement and use it, and no one will prevent me from disabling it
>> in any grid I run.
>>
>> Melanie
>>
>>
>> Lc wrote:
>> > it was not my idea but i think of use of some OSfunctions that don't
>> exist
>> > in SL.
>> > It's nicer to say to the end-user "sorry the sim you are actually doesn't
>> > support our features needed to use our product " than breaking with a
>> > compiling error.
>> >
>> > my "script" was just a demo ;)
>> >
>> >
>> >
>> > On Tue, Jul 29, 2008 at 2:27 PM, Melanie <melanie at t-data.com> wrote:
>> >
>> >> Hi,
>> >>
>> >> well, to be honest, I dont see a need, and don't even see it as
>> >> desirable, to allow scripts to discover, with certainty, what grid
>> >> they're on.
>> >>
>> >> In these days of aiming for interop, I think it is wrong to limit a
>> >> script to run only on one grid, and this feature would most
>> >> certainly be used in this way:
>> >>
>> >> "You are running MyFreeScript on Second Life. I don't like it.
>> >> Shutting down"
>> >>
>> >> Not pleasant, is it?
>> >>
>> >> Melanie
>> >>
>> >>
>> >> Lc wrote:
>> >> > ok.
>> >> > I will try that under SL and update the wiki.
>> >> >
>> >> > Maybe a page like : "Porting script into SL/OS howto" will be a good
>> >> > start...
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Jul 29, 2008 at 2:18 PM, Melanie <melanie at t-data.com> wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> simply use llRequestSimulatorData with a new constant (like I
>> >> >> defined CHANGED_REGION_RESTART). That would silently fail in LL,
>> >> >> IIRC, and deliver data in OS.
>> >> >>
>> >> >> Melanie
>> >> >>
>> >> >>
>> >> >> Mike Mazur wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Tue, Jul 29, 2008 at 5:00 PM, Lc <lcc1967 at gmail.com> wrote:
>> >> >> >> with the event, we are not CoreGrid dependant.
>> >> >> >
>> >> >> > Unfortunately events are part of the LSL grammar in SL. A script
>> >> >> > defining an unknown event doesn't compile.
>> >> >> >
>> >> >> > Your example wouldn't compile either, as your custom state doesn't
>> >> >> > have any events.
>> >> >> >
>> >> >> > I agree that this solution is a hack, but if required it would get
>> the
>> >> >> > job done for the time being. The optimal solution, as Adam
>> suggests,
>> >> >> > is to get Linden Labs to implement some function that returns the
>> >> >> > current simulator version.
>> >> >> >
>> >> >> > Mike
>> >> >> > _______________________________________________
>> >> >> > Opensim-dev mailing list
>> >> >> > Opensim-dev at lists.berlios.de
>> >> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >> >> >
>> >> >> >
>> >> >> _______________________________________________
>> >> >> Opensim-dev mailing list
>> >> >> Opensim-dev at lists.berlios.de
>> >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >> >>
>> >> >
>> >> >
>> >> >
>> ------------------------------------------------------------------------
>> >> >
>> >> > _______________________________________________
>> >> > Opensim-dev mailing list
>> >> > Opensim-dev at lists.berlios.de
>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >> _______________________________________________
>> >> Opensim-dev mailing list
>> >> Opensim-dev at lists.berlios.de
>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >>
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Opensim-dev mailing list
>> > Opensim-dev at lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev