<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>For doing something completely new and different, I'd be tempted to suggest forming a group to write up a "LSL as we'd like to see it", and see if we can get Linden Labs on board too. So, splinter off, do more experimental things than Linden Labs could easily do on main grid, and then try getting them to merge the successful ideas back into their sims.</div><div><br></div><div>Definitely, absolutely, LSL is a mess, though. Total lack of any support for library code, no object orientation (please, no prim jokes), inconsistent API naming (llGetListLength() vs llStringLength(), llRot2<anything> vs llStringToBase64() ) , there's wonderful methods such as llXorBase64StringsCorrect() (because the original one wasn't correct), methods that affect "the avatar detected" ( llMapDestionation() ) or "the avatar you most recently received this permission for" ( llStartAnimation() ), the entire llList2<blah>() set of methods which don't convert a list, but instead extract something from one... I could go one for a while. Point is, I'd love to see both OpenSim and SL have a sane, well thought out scripting language, rather than one that grew organically over the years.</div><div><br></div><div><div>On 14 Sep 2008, at 16:09, Mike Deem wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div>Yes, LSL makes things difficult. What is the general feeling on compatibility vs. improvements when it comes to scripting? Would having both a "100% compatible" and a completely separate, and completely different, "new scripting model" make sense?</div> <div> </div> <div>One thing that a new model could explore are some simple declarative triggers and actions for things like door opening, etc. In it's simplest form, the (possibly external) script would call an API to associate something like an llSetPrimitaveParams argument list with an event like touch. The sim would automatically apply those changes when the event occurs, no further interaction with the script would be needed. Look at how events and animations work in WPF or Silverlight for an example of what I mean.</div> <div> </div> <div>One big long term advantage of going down a path like this is improved security. Moving untrusted code execution out of the core simulation process would be a really good thing. Pushing declarative trigger/action pairs back into the secure process is much safer.</div> <div> </div> <div> == Mike ==<br><br></div> <div class="gmail_quote">On Sun, Sep 14, 2008 at 5:30 AM, Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>></span> wrote:<br> <blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Tedd originally wanted to do a script server. Unfortunately, he<br>found that many things that need to work to support LSL could not be<br> pushed across a remoting path.<br>He then abandoned the ScriptServer project and has removed it from<br>the tree a couple of days ago.<br><br>While it may be possible to make it work for some scripts and<br>scripting languages, it is an unsuitable concept for LSL and<br> per-prim scripting.<br><br>Also, if the script server is half a world away, it would not do<br>responsiveness any good. Clicking a door and encountering a 2 second<br>delay until it actually opens isn't my idea of a good user experience.<br> <font color="#888888"><br>Melanie<br></font> <div> <div></div> <div class="Wj3C7c"><br><br>Dahlia Trimble wrote:<br>> I'm not sure I agree, periodic state backups could preserve quite a bit of<br>> information, and machines hosting simulators can fail just as a machine<br> > hosting a script server. Not sure I agree with the delays either as the<br>> script server may even be able to do things faster since it may only have<br>> script processing to do and doesn't have to spend time processing physics or<br> > whatnot. If it was able to communicate all the changes that needed to happen<br>> in a server frame before the next frame starts then it may actually be a<br>> faster design. I guess a lot depends on how it's implemented.<br> ><br>> On Sat, Sep 13, 2008 at 4:32 AM, J Ross Nicoll<br>> <<a href="mailto:jrn2005@cs.st-andrews.ac.uk">jrn2005@cs.st-andrews.ac.uk</a>>wrote:<br>><br>>> The problem with an external script server is you're still doomed if<br> >> the server goes down. You need to be able to serialise state anyway or<br>>> the first extended powercut/hardware fault/intern looking for a kettle<br>>> lead will cause unspeakable chaos.<br>>><br> >> You'd also be bringing in even more delay in script response time, but<br>>> that's relatively minor.<br>>><br>>> On 7 Sep 2008, at 15:52, Mike Deem wrote:<br>>><br>>> > I've also been thinking about things like global scripts and<br> >> > external script servers. External script servers would solve some of<br>>> > the script state serialization issues. Instead of moving a running<br>>> > script from one region to another, it just keeps running on it's<br> >> > server.<br>>><br>>> The University of St Andrews is a charity registered in Scotland : No<br>>> SC013532<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 target="_blank" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br> >><br>><br>><br></div></div>> ------------------------------------------------------------------------<br> <div> <div></div> <div class="Wj3C7c">><br>> _______________________________________________<br>> Opensim-dev mailing list<br>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>> <a target="_blank" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">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 target="_blank" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br> </div></div></blockquote></div><br></div> _______________________________________________<br>Opensim-dev mailing list<br><a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br></blockquote></div><br><div> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>The University of St Andrews is a charity registered in Scotland : No SC013532</div><div><br></div></div></span><br class="Apple-interchange-newline"> </div><br></body></html>