Chapter Listing
< 1 2 3 4 5 6 7 8 9 >

9) Other assorted stuff
Some general tips/hints -- feel free to add your own and place your identification after it if you wish:

• When you save a script inside an object it automatically resets and enters the default state. Scripts saved into your inventory are not running, and as such, will only reset when placed in an object.
• It is possible to have more than one script in an object, and all can run simultaneously without running into memory problems. Each script has 16k available in total.
• One object cannot directly modify another, even if linked. You will need to implement a control protocol using the communications functions (link messages, or llSay/llListen on a special channel) to control the objects. The only exception to this rule is with regards to a linked prims color and alpha.
• When using llListen, try to think about how it can be used most effectively, and most efficiently. There are discussions on the forum about it. Check 'em out. In many cases using a link message is prefered, and speeds code execution. The advantages and disadvantages of listen vs. link messages gets very political.
• There are many ways to do cool things by using functions in ways they were not originally intended. This is an art, of sorts. Think creatively.
• Comments are not bad, but good code should need few comments. This is part of the self-documenting-code theory: if it's not clear what you're doing, do yourself a favour and document it. you WILL forget your thought-flow from a few months back
• First write your code for functionality and readability/expandability. Then worry about optimization. Once you're comfortable with programming, you should consider efficiency as you work, otherwise you may end up re-writing the program from scratch
• Don't forget to check for appropriate permissions when applicable.
• Remember that objects can change ownership while scripts are running. Make sure your scripts can handle this. There are other subtleties to consider as well. Try to be as thorough as possible when designing. Think about what will happen if your script is given to someone else, or attached, or placed on the ground. You may wish to test these possibilities so you're sure you understand what happens in each case.
• Use strategically-placed llOwnerSay calls to help you debug code.
• Like anything else, planning helps. So does smartly naming your variables. If you can, test in chunks. This gets harder and harder with bigger pieces of code and more complex operations, but you can often write little bits of code and then build them up into bigger and bigger sections. (-EloisePasteur)
• Like any other coding environment, when you find a good piece of code, keep it! The first time I started handling lists, it was clunky and horrible. Gradually I evolved a piece of code that is far from perfect, but works quite efficiently. Suddenly, I'm using it to handle lists in several other scripts that I've written. It can be hard to know when to adapt and when to write from scratch. I still get it wrong! But generally adapting code, or at least looking at code for something you have that is similar helps quite a bit.
• Ask in the scripting forum and look through the script library as well - there's a lot of code out there that people share freely, and some of it might do what you want.
• If you see a script that does something you want, consider asking the creator for help. Most people in SL are friendly and will help, or will direct you to someone who can. They may even give you the entire script itself.

Previous | Next

---

Homepage | Tutorial | CrashCourse | Glossary