[Opensim-dev] new LSL state to implement

Wed Jul 30 06:07:21 UTC 2008

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080730/0f46fd82/attachment-0001.html>