<div dir="ltr">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.<br><br>The best approach imo is the __MAGIC_VAR_SERVER_MAJOR_VERSION__ = "" <br>
approach.<br><br>It won't hurt any scripts in SL and doesn't need any Linden's serverside modification.<br><br>lc aka Sm<br><br><br><br><div class="gmail_quote">On Wed, Jul 30, 2008 at 12:12 AM, Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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>
<font color="#888888"><br>
Melanie<br>
</font><div><div></div><div class="Wj3C7c"><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: <a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a> [mailto:<a href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a>] On Behalf Of Melanie<br>
> Sent: Tuesday, July 29, 2008 5:27 AM<br>
> To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><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 <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> 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 <<a href="mailto:lcc1967@gmail.com">lcc1967@gmail.com</a>> 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>
>>> > <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>>> > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>> ><br>
>>> ><br>
>>> _______________________________________________<br>
>>> Opensim-dev mailing list<br>
>>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>><br>
>><br>
>><br>
>> ------------------------------------------------------------------------<br>
>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div>