<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>the whole substititution approach, however appealing, still will lead to extremely stub-bloated lsl. Not to mention magic confusing code.<BR><BR>
I guess the use cases fall in three: checking on grid to see what _resources_ are available<BR>
and<BR>
checking on the language to see what _commands_ are available<BR>
and<BR>
checking on the region to see what _features_ are available<BR>
<BR>Best regards,<BR>Stefan Andersson<BR>Tribal Media AB<BR> <BR>Join the 3d web revolution : <A href="http://tribalnet.se/" target=_blank>http://tribalnet.se/</A><BR> <BR><BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Tue, 29 Jul 2008 23:12:55 +0100<BR>> From: melanie@t-data.com<BR>> To: opensim-dev@lists.berlios.de<BR>> Subject: Re: [Opensim-dev] new LSL state to implement<BR>> <BR>> Hi,<BR>> <BR>> actually, I have been looking into implementing a prim motion limit. <BR>> There is a solid case to be made FOR such a limit, and the warpPos <BR>> "hack".<BR>> Specifically, it is incredibly easy to "lose" prims scripting. It <BR>> has happened to me before, when there was no such limit. Debugging <BR>> the script and some creative guesswork have often led me to find the <BR>> prims again, but some were gone. They're still out there, all alone :(<BR>> <BR>> So, warpPos should be needed, and used. In fact, the limiting is the <BR>> easy part, making warpPos work is the harder part.<BR>> <BR>> I still believe that there is no need for grid discovery in LSL. In <BR>> C#, we will be able to provide it easily. LSL really shouldn't have <BR>> it, IMHO.<BR>> <BR>> That said, either the new constant or the magic variable will work.<BR>> <BR>> I have it on authority that LSL is FROZEN.<BR>> <BR>> Nothing will be added after inbound HTTP and another, minor, feature <BR>> that slipped my mind.<BR>> <BR>> Melanie<BR>> <BR>> <BR>> Chang, Francis wrote:<BR>> > Hi all,<BR>> > <BR>> > 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.<BR>> > <BR>> > 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.<BR>> > <BR>> > <BR>> > So far, there seems to be 4 implementation suggestions:<BR>> > <BR>> > 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)<BR>> > <BR>> > 2) Add an additional llGetSimulatorVersion() function: drawbacks: requires LL to modify their compiler to get the same script to compile on maingrid<BR>> > <BR>> > 3) llGetSimulatorHostname() substring matching: drawbacks: heuristic - only works iff Lindenlab.com hosts all maingrid servers, and only maingrid servers.<BR>> > <BR>> > 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.<BR>> > (This is my favourite idea so far)<BR>> > <BR>> > <BR>> > New suggestion: Use a magic variable - opensim compilers will automatigically change the value:<BR>> > <BR>> > string __MAGIC_VAR_SERVER_MAJOR_VERSION__ = "";<BR>> > <BR>> > string getCurrentGrid() {<BR>> > if ( __MAGIC_VAR_SERVER_MAJOR_VERSION__ == "" )<BR>> > return "LL_GRID";<BR>> > else if ( __MAGIC_VAR_SERVER_MAJOR_VERSION__ == "OPENSIM")<BR>> > return "OS_GRID";<BR>> > else<BR>> > return "UNKOWN_GRID";<BR>> > }<BR>> > <BR>> > 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.<BR>> > <BR>> > The drawback is it would be a total hack.<BR>> > <BR>> > Just my 2 cents :)<BR>> > <BR>> > --<BR>> > Francis<BR>> > <BR>> > <BR>> > <BR>> > -----Original Message-----<BR>> > From: opensim-dev-bounces@lists.berlios.de [mailto:opensim-dev-bounces@lists.berlios.de] On Behalf Of Melanie<BR>> > Sent: Tuesday, July 29, 2008 5:27 AM<BR>> > To: opensim-dev@lists.berlios.de<BR>> > Subject: Re: [Opensim-dev] new LSL state to implement<BR>> > <BR>> > Hi,<BR>> > <BR>> > well, to be honest, I dont see a need, and don't even see it as<BR>> > desirable, to allow scripts to discover, with certainty, what grid<BR>> > they're on.<BR>> > <BR>> > In these days of aiming for interop, I think it is wrong to limit a<BR>> > script to run only on one grid, and this feature would most<BR>> > certainly be used in this way:<BR>> > <BR>> > "You are running MyFreeScript on Second Life. I don't like it.<BR>> > Shutting down"<BR>> > <BR>> > Not pleasant, is it?<BR>> > <BR>> > Melanie<BR>> > <BR>> > <BR>> > Lc wrote:<BR>> >> ok.<BR>> >> I will try that under SL and update the wiki.<BR>> >><BR>> >> Maybe a page like : "Porting script into SL/OS howto" will be a good<BR>> >> start...<BR>> >><BR>> >><BR>> >><BR>> >><BR>> >> On Tue, Jul 29, 2008 at 2:18 PM, Melanie <melanie@t-data.com> wrote:<BR>> >><BR>> >>> Hi,<BR>> >>><BR>> >>> simply use llRequestSimulatorData with a new constant (like I<BR>> >>> defined CHANGED_REGION_RESTART). That would silently fail in LL,<BR>> >>> IIRC, and deliver data in OS.<BR>> >>><BR>> >>> Melanie<BR>> >>><BR>> >>><BR>> >>> Mike Mazur wrote:<BR>> >>> > Hi,<BR>> >>> ><BR>> >>> > On Tue, Jul 29, 2008 at 5:00 PM, Lc <lcc1967@gmail.com> wrote:<BR>> >>> >> with the event, we are not CoreGrid dependant.<BR>> >>> ><BR>> >>> > Unfortunately events are part of the LSL grammar in SL. A script<BR>> >>> > defining an unknown event doesn't compile.<BR>> >>> ><BR>> >>> > Your example wouldn't compile either, as your custom state doesn't<BR>> >>> > have any events.<BR>> >>> ><BR>> >>> > I agree that this solution is a hack, but if required it would get the<BR>> >>> > job done for the time being. The optimal solution, as Adam suggests,<BR>> >>> > is to get Linden Labs to implement some function that returns the<BR>> >>> > current simulator version.<BR>> >>> ><BR>> >>> > Mike<BR>> >>> > _______________________________________________<BR>> >>> > Opensim-dev mailing list<BR>> >>> > Opensim-dev@lists.berlios.de<BR>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> >>> ><BR>> >>> ><BR>> >>> _______________________________________________<BR>> >>> Opensim-dev mailing list<BR>> >>> Opensim-dev@lists.berlios.de<BR>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> >>><BR>> >><BR>> >><BR>> >> ------------------------------------------------------------------------<BR>> >><BR>> >> _______________________________________________<BR>> >> Opensim-dev mailing list<BR>> >> Opensim-dev@lists.berlios.de<BR>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> > _______________________________________________<BR>> > Opensim-dev mailing list<BR>> > Opensim-dev@lists.berlios.de<BR>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> > _______________________________________________<BR>> > Opensim-dev mailing list<BR>> > Opensim-dev@lists.berlios.de<BR>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> > <BR>> > <BR>> _______________________________________________<BR>> Opensim-dev mailing list<BR>> Opensim-dev@lists.berlios.de<BR>> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR><BR></body>
</html>