[Opensim-dev] new LSL state to implement

Wed Jul 30 06:35:23 UTC 2008

the whole substititution approach, however appealing, still will lead to extremely stub-bloated lsl. Not to mention magic confusing code.
I guess the use cases fall in three: checking on grid to see what _resources_ are available
and
checking on the language to see what _commands_ are available
and
checking on the region to see what _features_ are available
Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ 

> Date: Tue, 29 Jul 2008 23:12:55 +0100> From: melanie at t-data.com> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] new LSL state to implement> > 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/6099dd84/attachment-0001.html>