|
John Hurliman wrote: We had a developer that went by asterick in IRC that was working on an LSL to LSO compiler. ...This is helpful. Hopefully there is more to find as noted. The SL servers only run LSO bytecode right now, and LSL compiling will be moved to the servers much sooner than they will transition the grid to a mono scripting backend.I tried to verify if any LSL compile process is being moved to the server end. I've seen the "masterplan" in the LangNet conference video shows that the compilation is still outside the server. Ok, I just want to clarify that none of the libsecondlife developers work for Linden Labs, you probably want to talk to them directly about feature suggestions. As far as a local sandbox sim, it would have no need to pack up it's state since there would be no other sims to transfer scripts to. If you are talking about building a separate grid that's a bit out of the scope of libsecondlife and more in the realm of the Open Source Metaverse Project, Croquet, or other endeavors.Indeed. There is, however, the use LL as the asset databank. Perhaps, in the future they'll allow others to hosts contiguous sims. Private islands or planets, for example, which actually point to other hosts outside LL but still query LL for universal asset information. If I see asterick around again I'll direct him to this thread and see if I can convince him to help the compiler project move forward. There's a lot of possibilities if an open source compiler existed (think Eclipse and Second Life running side by side).I saw a LSL plug-in for Eclipse: Sloth @ http://adammarker.org/sloth.html There is also a lint program: lslint @ http://w-hat.com/lslint/ With asterick's docs, we may be able to redirect the edits and compilation through a proxy as SL runs at the same time. |
_______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/
