[Opensim-dev] new LSL state to implement

Melanie melanie at t-data.com
Wed Jul 30 06:21:15 UTC 2008 

I prefer the request call myself.

A variable is even more hacky, and pollutes the namespace.

Melanie


Lc wrote:
> Well, as long as SL doesn't provide c# scripting in a near futur, we do need
> a way to identify the running grid under LSL.
> 
> The best approach imo is the __MAGIC_VAR_SERVER_MAJOR_VERSION__ = ""
> approach.
> 
> It won't hurt any scripts in SL and doesn't need any Linden's serverside
> modification.
> 
> lc aka Sm
> 
> 
> 
> On Wed, Jul 30, 2008 at 12:12 AM, Melanie <melanie at t-data.com> wrote:
> 
>> Hi,
>>
>> actually, I have been looking into implementing a prim motion limit.
>> There is a solid case to be made FOR such a limit, and the warpPos
>> "hack".
>> Specifically, it is incredibly easy to "lose" prims scripting. It
>> has happened to me before, when there was no such limit. Debugging
>> the script and some creative guesswork have often led me to find the
>> prims again, but some were gone. They're still out there, all alone :(
>>
>> So, warpPos should be needed, and used. In fact, the limiting is the
>> easy part, making warpPos work is the harder part.
>>
>> I still believe that there is no need for grid discovery in LSL. In
>> C#, we will be able to provide it easily. LSL really shouldn't have
>> it, IMHO.
>>
>> That said, either the new constant or the magic variable will work.
>>
>> I have it on authority that LSL is FROZEN.
>>
>> Nothing will be added after inbound HTTP and another, minor, feature
>> that slipped my mind.
>>
>> Melanie
>>
>>
>> Chang, Francis wrote:
>> > 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
>> > _______________________________________________
>> > 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