Hmm, the way I do it. My projects increasingly become more complex and vastly demanding of performance improvements, as well as most importantly, smart flexible design.
When I start a complex script these days, I create three scripts. Practical. This is the main script, where all the beta/final code is worked on. It is basically all the theory put into action. Comments are mostly left out, my written code is meant to be read mostly self-explanatory, unless a comment is really necessary. Lightweight is better than heavyweight, but that is just my own personal take. Theory. This mostly consists basically of the design, plan and specifications, I use a few tricks here I have learned over time. I keep this open in the background all the time. For example 'Pointers', basically emulating memory pointers from other programming languages for lists. This is basically used in concert with two lists, basically a hashtable kinda with custom data to tell me what data this is etc, then the other being all the raw data, a list of vectors, floats and heavy data. The raw data list can be pushed into slave-scripts if the data gets heavy enough depending on application. Another trick I use often is to condense as much information I can into a single integer, using bitshifting and all the neat bit operators such as AND for checking flags. Lastly, multi line comments are great here than having to push double slashes everywhere, especially if you are on an older client which doesn't support the highlighting you can take this to advantage to create your own custom highlighting without compiling into actual code! (/* Comment! */ Yeah, multi line comments are compiled correclty, the viewer doesn't support these syntax highlight tokens yet, although my custom client Vertical Life has a personal modification in the keywords file for "/*/" tokens) Scratch. This is something new to me, basically somewhere for me to quickly test functions or quick ideas. Found it very, very good for debugging code. It is just a big place for me to scratch around and compile stuff fast without the overhead in the main script. I tend to transfer over scripts in here to let LSL do the heavywork for me, say I was designing specifications to use various bits in an integer for different purposes, I use a set of various bitmask functions to get me correct offsets. Well, I switch around a lot, moving from programming methods and techniques to others. But this is basically my own personal current way of doing things effectively for now. Hope my shared knowledge may be of use to anyone with a similiar mindset. - Nexii Malthus On Fri, Oct 16, 2009 at 1:24 AM, Maxxi Short <[email protected]> wrote: > Thanks, Kubota - actually "LINK_THIS" is what I was thinking of when I said > "THIS_PRIM". This makes a lot of sense - I'll give that a go! > > > ----- Original Message ----- > From: "Kubota Homewood" <[email protected]> > To: "Maxxi Short" <[email protected]> > Sent: Friday, October 16, 2009 12:18 AM > Subject: Re: Complex scripts and good style > > > > Yes, you can. Further, use LINK_THIS to only talk to the current prim, > > or use the link number of the prim the script is in (but the same > > object). If you have a script in a "library" prim you can send > responses > > to the sender (the first parameter in the link_message event). The > thing > > to keep aware of is that any script in a prim that has a link_message > > handler will wake up with a link message is sent to that prim. Link > > messages do appear to be reasonably efficient, but also remember there > is > > a queue depth of 64 so if you send them faster than they can be handled > > (perhaps because a script doesn't get run often enough in a busy sim) > > that you can lose link messages. > > > > I dearly wish we could direct a link message at a specific script. > > Barring that, it would be wonderful to have two sets of mask/value pairs > > such that > > > > if ((n & mask1) == value 1 || (n & mask2) == value2) > > send link message to script > > > > Why two sets? One set to limit it to this prim, the other set to still > > allow global messages. I would even go for: > > > > if ((n & mask) == value 1 || (n & mask) == value2) > > send link message to script > > > > I already more or less do this inside scripts, but it would be nice if, > > on a busy sim, the script never even had to be woken up. > > > > Kubota > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
