Although to clarify one particular point, you don't really need to use Furbot to debug the dream, it's only being used as a "raw server data capture program" for the application being described here. And that application is the Raw Log Decoder. The raw log decoder takes a raw capture file and decodes the contents, producing several lists for you to use in streamlining and figuring out how to make your DS either work better, or why it's being wonky at some point in the script. This program and the DragonSpeak Line Counter combined helped me to find some spots in my DS where I sort of made a wonky occur, ...

Plus it's helped in other areas as well, in determining in heavy DS triggering dreams where most of the action was occurring. When run on a properly formatted capture file, that is, a file which the data is stored "as is" as it comes from the server, it generates four lists:

1. Events - A list of all the different events that the decoder can decipher.
2. Counts - Each individual DS Trigger ID and the number of times it occurs.
3. Sequences - The "chains" of DS that happen and the number of times each chain is seen.
4. DS Train - The order in which each chain is sent from the server.

Detail each of these lists in order. The first list, Events, is simply telling you how often each of the various types of events are sent from the server, example:

FYI, this is a capture of about 10 minutes hanging around in Allegria Island. The Capture Start & End tags are generated by Furbot, when you start / stop the capture of the server data, it stamps the log. Note that this is only available in Furbot version 2.4.272 or above, prior versions of Furbot will make the capture file, but without those two tags.

Next up is the Triggers:

This is the primary list to use for determining how much time your dream's DS is spending on which trigger, as we can see from this simple example, the most common trigger DSID is #23, which, if you could read the DS, is:

23 (0:9) When a furre arrives in the dream,
24  (1:92) and their entry code is less than 10,
25      (5:302) take variable %ZoneCounts and add 1 to it.

The next two most common are 334 & 284, which, if you could read the DS, you would see that 334 is the F3 bounce about the dream trigger, and 284 is bumping the %ZoneCounts whenever someone arrives in the dream. Enough of that, next up is the Sequences:

The Sequences table is just as important as the Triggers table, the Triggers table tells you what particular individual DS trigger is being processed most often, the Sequences tell you which particular set of Trigger Events happens most. From the above table, we see that of all things, it's the F3 Bounce About The Map, a stand alone trigger, which causes the most DS activity as a single sequence, most of the rest of the Sequences in little chunks of 1 & 2's are related to the Random Landing Zone Entry DS. The column labeled Chunks is how many triggers are grouped together in that particular Sequence. Again, if you could look at the DS, you would find that the last few bits being triggered are:

1. 296 = Bump Though Path Blockers (Area A) (Occurred 2 times)
2. 310 = Bump Though Path Blockers (Area C) (Occurred 3 times)
3. 317 = Bump Though Path Blockers (Area D) (Occurred 2 times)
4. 390 = Idle Furre Checking (Occurred 2 times)

The final table is the DS Train, and that's a list of Sequences and the order in which they arrived to the client:

Output truncated because it's not necessary to show all of it for this post. There's no real easy means to time stap the chunks as they come in without creating a possible problem with what you're looking for, so the best you can do is take the time the capture was run and divide it by the number of triggers that the server sent. In this case, it's averaging about 8 triggers a minute. A lot of what is not being decoded by the program is all the avatar actions and other commands sent, so that has to be taken into account somewhat as well, but if you can narrow down where a lot of DS activity is happening in your dream, you will probably reduce that as well because some events will cause those avatar actions to be sent as well, for example, a teleport, which will send a DeleteAvatar, ClearAvatar, and ManifestAvatar to the client. That wonderful action of moving the triggering furre 0 steps in the direction they're facing? Generates Avatar actions.

It should be pointed out that the program makes no differentiation between User generated triggers, and Other generated triggers, a trigger is a trigger and needs to be looked at if it's being a point where a large amount of time is being spent. So if you're the one who coded:

(0:71) When a furre stays in the same square for 1 seconds,
 (1:70) and the triggering furre's name is {Dream Uploader},
  (3:5) where the triggering furre is at, not moving,
    (5:19) move any furre present 0 step(s) forward ...

Hey, that's on you, ok?

Using this system is very well suited for your own dream, because you have access to the original DS, and can use the DragonSpeak Line Counter to locate all the offending lines of DS, but that does not mean you can't use this system to help others figure out what's running so badly with their dream, neither the decoder nor Furbot needs access to the script, they're dealing with what is actually being sent from the server.

Notation about DLC: The program does NOT do any parsing or checking for valid DS when it loads the file, all it does is check if the first available character in each line is the opening parenthesis which is the usual hallmark of a line of DS. The above sample will be indexed, (if it was the only thing in the file) as:

1 (0:71) When a furre stays in the same square for 1 seconds,
2  (1:70) and the triggering furre's name is {Dream Uploader},
3   (3:5) where the triggering furre is at, not moving,
4     (5:19) move any furre present 0 step(s) forward ...

The number of spaces before that opening parenthesis does not matter, if it's missing, the line is counted as a comment. Anything without that leading parenthesis is a comment as far as DLC is concerned. Stacking two or more lines of DS onto a single line, (AKA "Compressing") will be counted as a single line:

(0:71) same square 1 seconds, (1:70) name is {Dream Uploader}, (3:5) (5:19) move 0 step(s)

So if you want to maximize the use of the program, at least put each command on it's own line.

In using this system to determine wonkyness, bear in mind that the DSID is the (0:xx) of each chunk, so if you come across a trigger being sent from the server which does not correspond to a valid (0:xx), then the DS is damaged above that point and you need to locate where you broke it. Because everything is being sent in a nice orderly fashion, you can use the Sequences to figure that out, just follow the chain and the bad part will be in-between the last valid trigger in the chain and the out of order trigger. Likewise, if there's some part which is triggering and you think it shouldn't be, or it's not triggering and you think it should, the chain will help you in determining the order of events so you can easily look through your DS and figure out what's going wrong. Like you were using a variable %Alabaster for most of the DS, except for that one line where you managed to use %Alabasted, ...

Operation of the decoder is simple:

• File
  • Open - Opens a Furbot XDB Capture file, or any properly formatted capture file.
  • Export
    • Export To CSV - Exports each table in the results as a separate CSV file, the CSV format does not permit multiple sheets to be welded together. Suitable for uploading to a popular webservice's documents system.
    • Export To HTML - Exports everything to a simple stripped down HTML file. Note that neither of these export functions deal with any sorting, the output is delivered as the decoder originally found them in the capture file.
  • Load - Loads a previously decoded set of results.
  • Save - Saves a set of results so you can use multiple instances of the program to compare results.
  • Exit - Duh!
• Configure
  • Detail Train - Not built yet, will produce a detailed train of events.
• Help
  • About - Simple about.
  • Help - Simple help.

The DS Line Counter is even simpler, won't even bother doing fancy nested lists for it, it's got an Open, & Exit listed under the File menu, and a Goto Line under the Edit.

Both programs will run as is, they have no external dependencies other than the native window stuff. Preferrably you should drop the decoder in the Furbot Files folder, or where ever your particular capture program puts it files so you don't have to walk the folder tree to the file. And the line counter can be dropped into the same folder just because it's easy to do, and most likely your dragonspeak file will be in the dropdown list of the open dialog.