With your knowledge of how actions are handled in DragonSpeak, as well as how you can put the different lines together to form blocks of DragonSpeak code, it's time to talk about one last important issue: efficiency. You are not given an infinite number of DragonSpeak lines that you can use in your dream, so it's important that you know how to create the effects you desire in DragonSpeak using the most compact bits of code.

Creating compact code is not the only efficient thing that can be done with DragonSpeak, however. You also need to worry about the idea of creating lag with your DragonSpeak. There are certain lines that can cause more lag than others, as well as techniques that create more lag. Ways of dealing with lag in your dream will also be addressed.

The final aspect that we'll talk about on this page is how to avoid logic errors. These errors are oftentimes the hardest one for a DreamWeaver to find. I'll explain how they're formed. Once you know how they're formed, they should be pretty easy to avoid.

[ BACK TO THE TOP ]

Let's first address the idea of creating compact code by looking at the example of using switches in your dream. Switches, in case you didn't know, are objects 161 through 164. There are two types of switches, and each type has an "on" and "off" state. Well, speaking for myself, if I ever put a switch in one of my dreams, it generally means that I intend to have furres "bump" into that switch in order to make it change to the opposite state (from "on" to "off", or from "off" to "on").

This can be done in 6 lines of code: "Whenever anyone moves into object type 161, where the triggering furre moved into, place object type 162." and "Whenever anyone moves into object type 162, where the triggering furre moved into, place object type 161." All you have to do is place that code somewhere at the bottom of my DragonSpeak file, and I'm good to go for toggling on/off all 161 and 162 switches. Now I can put down as many of these switches as I like in my dream and only have to worry about coding the actual "locking" part of the switch. Let me show you an example of a good and bad way to do these switches.

This is a good example of how you can do locks with switches in your dream. Notice how both of the locks check to see what state the switch is in, but neither of them actually change the state. The state is changed later on by a script that works for all objects 161 and 162, so it saves you the hassle of having to change the switch in each of the individual lock codes. Below is a less efficient example of how to do the same two locks.

As you can see with two locks, you're saving 2 lines of DragonSpeak by doing it the good way. Think how that would add up if you had more. Here is a break down of how the two ways use up your DragonSpeak lines:

The Good Way:

• 8 Lines for every lock + 6 lines of Dragonspeak for the switch toggling
• Or: 8 * NumLocks + 6

The Bad Way:

• 12 Lines for every lock
• Or: 12 * NumLocks

Here's a table of how much DragonSpeak you'd use for up to 10 locks in your dream:

As you can see from the table, if you use a lot of locks in your dream the good way of doing locks will save you some of those precious lines of DragonSpeak we Dream Weavers like to preserve.

Remember: If you have a lot of the same type of Effect happening in your dream, then the best thing you can do (in terms of saving DragonSpeak lines) is to try to combine all of those similar Effects into a single block of code. As you can see, with the exception of only having one lock in your dream, doing it the good way will save you many DragonSpeak lines.

[ BACK TO THE TOP ]

The next issue to address is lag. There are a few things that you can do in your dream that can both create lag and cause other problems:

1) Using Classic mode is an example of this. If you don't know what Classic mode is, let's first explain what the current mode of Furcadia is. When your DragonSpeak does a lot of object changing, furre moving, or tile changing, it does all of this before it updates your client. That means that you'll see all of these changes happen at the same time. Classic mode, however, updates your client after each change to the dream for that block of DragonSpeak. This is great for doing animations, but it can cause lag by forcing your client to keep redrawing the screen.

2) "(5:1000) redraw the screen and show everything that's just changed" is another line of DragonSpeak that can cause lag. The reason why this lags is similar to how the Classic mode operates. When you put this trigger in your DragonSpeak, it'll cause everyone's client to update and be redrawn with the new map information before continuing with the rest of the DragonSpeak chunk. When alone, these don't cause a lot of lag, but if you have a bunch within the same DragonSpeak chunk, then it's almost the same as having Classic mode turned on.

3) Yet another issue that can cause lag is having a bunch of "When # seconds have passed (offset by #)" timers. If you're ever going to have a timer like this that triggers every 1 second, then it's probably best to stick all of the Effects under that same Cause. For instance, it would not be wise to have one 1-second timer that animates your water waves while you have another that animates your lights. Put both of these under the same timer and you're likely to reduce the amount of lag in your dream.

4) The last thing that causes lag isn't so much a line of DragonSpeak but rather a DragonSpeak practice. Whenever you change any large amount of items or tiles around, you're going to generate lag. On top of the lag that it creates, it also causes problems for people entering the dream. Hopefully this'll be fixed in future versions of Furcadia, but remember that the client can slow down if it has to handle animations on a large scale.

[ BACK TO THE TOP ]

The last issue that we'll discuss is logic errors. Logic errors occur when you have what looks like the correct DragonSpeak, but the desired Effect does not occur. The main reason why this happens is based on the idea that a single action can trigger more than one chunk of DragonSpeak.

As I said on the first page of this DS Theory tutorial, an action is sent from the server to your DragonSpeak file and the action works its way from the top of the file to the bottom, triggering all blocks of DragonSpeak code that it can. Knowing this, it's easy to see that you could very well have one chunk of DragonSpeak code at the top of your file that perhaps placed a red pillow under you whenever you use object type 0, but then later on down the file, you may have another chunk of code that removes the red pillow from underneath you whenever you use object type 0. This would result in you never seeing the red pillow beneath you. Why is that? Well, like I mentioned above, currently the way DragonSpeak works is that it'll make all the changes that the particular action creates before it tells your client to update. So it'll place the red pillow beneath you, but then it'll remove the red pillow, and then it will update your client. This results in you never seeing the red pillow appear. Below is an example of the code that will cause this to happen, as well as a way of fixing it.

The second version makes it so you can only place a red pillow if you're standing on an empty tile, and you can only make that red pillow disappear if you use object type 0 while you're standing/sitting on a red pillow.

The example may be cheesy, but it does a good job of demonstrating how important it is to remember that these actions that are sent from the server can trigger more than one line of DragonSpeak code and that they move from top to bottom.

[ BACK TO THE TOP ]

You've reached the end of this DS Theory text. Through the various examples and explanations we hope you have a firmer grasp on what DragonSpeak is and what it does. Now, test your knowledge by creating some of your own code to go along with your dreams. The best way to learn DragonSpeak is to experiment and practice with it. Happy DragonSpeaking!