Program Layout Tool for LSL

I'm realizing rapidly that multiple-script programs in LSL become very, very confusing, very, very fast at that the only key to being able to successfully complete such projects is good planning. I've been drawing everything out on paper in a modified OOP/UML type layout, but it's not quite right ... not with LSL.

Does anyone know of a tool that can be adapted to laying out and visualizing LSL projects? I'd be really, really appreciative.

You mean something like a flowchart tool? I don't know of any, but perhaps the best way to manage it might be with a pencil and paper. Wrtie down each part of the program, including some basics of how they might communicate and what they would do. This works for me, although I'm not sure about how well it might work for others. Don't put a lot of information into this outline, but know how you would confront each individual problem that you might face.

Also, Scite-EZ is very nice if you need to write a multi-script LSL program, or a single-script LSL program.

Scite-EZ for the win!

Seriously though.. it is a great tool. Highly recommended.

I tried this, but it just wasn't happening. LSL's event and states system isn't well-suited to being represented as a flowchart.

Instead, try to focus on the inputs and outputs of each script. Tackling each one as a self-contained machine that accepts certain input and returns corresponding output allows one to really focus on specific tasks instead of getting caught up in the whole.

Ironically, this is exactly what I was told in two required "Design of Information Systems" courses for my degree. That was about the only useful lesson out of the entire class.

So, yeah - better to manage your link messages, listeners, and functions as self-contained processes. That way, when the time comes to figure out which script does what where, it'll be managable.

And on that note, we really need persistent storage. Splitting off everything due to the 16k limit is driving me batty.

I knew not finishing up all those computer sci clases was going to haunt me, lol. Thanks for the suggestion Catherine think I may try it out this way, I've been going crazy as of lately with my new project.

Thanks. Much good advice there. I had also tried the flowchart/UML style program planning, but it wasn't working for me either.

Now, the way I've been doing this, is by breaking the program into scripts to handle simple functions: kind of like very, very simple classes.

For example; I recently created a sphere that hovers on its own, and orbits in random patterns around the owner. I want to be able to add to it in the future, so I tried for a very modular, expandable idea.

BRAIN: Handles AI. Has a timer which generates random and sents it to the LINK_SET as a linked message.

INITIALIZER: Resets the object on rez. Sets all the llSetStatus settings. Defines the object name, desc, etc.

MOVEMENT_HANDLER: Listens for linked messages. Upon recieving a message, it sets the target, moves to target, applies random force to cause deviation, monitors for at_target, and then resets the script to wait for another command.

INTERFACE: Has a listen event which takes verbal commands from owner and transmits the corresponding linked messages such as START, STOP, CLONE, SET_PATTERN, etc to the LINK_SET.

Now, it is pretty complicated and its currently not working because I can't debug it! Something has gone wrong, I can't figure it out. Does anyone know of a better scripting technique for LSL that will promote good readability and minimize debugging issues?

Personally, I would put all of that functionality together into one script. It would ease many problems.

If you don't have to do multiple scripts, don't.

Also, an llApplyImpulse won't change an llMoveToTarget noticeably, unless it has a very, very large force.