[Opensim-dev] new LSL state to implement

Chang, Francis francis.chang at intel.com
Tue Jul 29 20:41:01 UTC 2008


Hi all,

I completely agree that the "I am shutting down because I hate your grid" error would be incredibly irritating. That said, the purpose of a programming language is to allow you to clearly express an algorithmic idea, not to enforce philosophy.

Moreover, for some scripts, it might be necessary to differentiate grids for correct behaviour. For example, a networked vendor or an auto-updater script need to be able to figure out which grid-specific server to contact.


So far, there seems to be 4 implementation suggestions:

1) Add an automatic state change: drawbacks are that it would interrupt program flow, cause side effects like killing off your llListen()'s, and can only encode 1 bit of information (on maingrid or not)

2) Add an additional llGetSimulatorVersion() function: drawbacks: requires LL to modify their compiler to get the same script to compile on maingrid

3) llGetSimulatorHostname() substring matching: drawbacks: heuristic - only works iff Lindenlab.com hosts all maingrid servers, and only maingrid servers.

4) llRequestSimulatorData() with a new constant: drawbacks: LL could break this going forward: Suppose they defined a new constant to mean something else, or they changed the failure mode of an undefined constant.
(This is my favourite idea so far)


 New suggestion: Use a magic variable - opensim compilers will automatigically change the value:

string __MAGIC_VAR_SERVER_MAJOR_VERSION__ = "";

string getCurrentGrid() {
        if ( __MAGIC_VAR_SERVER_MAJOR_VERSION__ == "" )
                return "LL_GRID";
        else if ( __MAGIC_VAR_SERVER_MAJOR_VERSION__ == "OPENSIM")
                return "OS_GRID";
        else
                return  "UNKOWN_GRID";
}

It would work forever going forward, since we're just changing the result of well-defined correct behaviour. This could be handled at both at runtime or compile time.

The drawback is it would be a total hack.

Just my 2 cents :)

--
Francis



-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie
Sent: Tuesday, July 29, 2008 5:27 AM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] new LSL state to implement

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



More information about the Opensim-dev mailing list