DBEditor:BuildDialogs

DBEditor: Build Dialogs

This option is used to read the EQ2 "Raw Data" parsed from packet collects, and attempts to assemble them in the best-known order we can to reduce the amount of script writing that designers have to perform. Otherwise, we would be fetching text from fan sites and doing a lot of manual typing.

Parser: raw_dialogs

When Parser processes a Spawn packet, one of it's tasks is to scan the packet log for any "dialogs" the Spawn might have had with a player. A dialog is a two-way conversation between a player and NPC that is menu driven.

Every time a player engages an NPC with Dialogs, a new conversation_id is generated. You can see this in the raw data like in this example:

In the above example, the player clicked on Yasha Redblade at least 5 times, generating conversation_id 4, 5, 14, 15, and 16... etc. The server->client keeps track of every dialog session until the dialog is closed; thus every dialog and option become a part of the current conversation_id and we can track that, and use it.

When that player first clicked Yasha, she said to him

 Whoa!  You finally woke, eh?

This is noted by the sequence # in the parsed data - ie., the first dialog in the sequence. In the raw_dialog_choices table is where we track the possible responses to what Yasha said to us:

Note here your valid responses are:

 Yes, and my muscles are a bit stiff.
 Yes, and I heard you could use some help.

Depending on which of these choices you click, the dialog will head off in a different direction.

The Build Dialogs script attempts to build these dialog/conversation paths as best it can, however SOE data does not provide us a 1:1 "if I click this, I will get this" - so this is where the Script Author steps in.

What you end up with in the Build Dialogs menu is a huge script (depending on the number of dialogs) that at first seem very repetitive. Most convo options can simply be removed, but they are there to help you determine the flow of the conversation.

Example:

In this auto-generated script, you can see the convo ID that matches the conversation_id from the raw database.

 Note about "convo ID" 
 This is merely there to isolate the data, it serves no purpose in the functionality of the script

You can clearly match the StartConversation() options to the sequence 0 of each dialog step. Then, you can see your multiple options as AddConversation() steps which drive the conversation. Here's where you come in.

The script attempts to drive the conversation to a new set of dialogs automatically, but cannot "guess" at them all. The script automatically generates a new Function for each dialog it thinks the conversation is taking.

Example: In that first convo==4 dialog, if you choose:

 AddConversationOption(conversation, "Yes, and my muscles are a bit stiff.", "dlg_4_1")

...note the script added a dlg_4_1 - which stands for Dialog, conversation_id 4, sequence 1, in an attempt to automatically build the conversation flow. Unfortunately, raw data does not offer any clue as to the additional options so those have to be done manually.

Inside the Function dlg_4_1, the script attempts to guide you to the NEXT dialog as well (dlg_4_2) but this is not always correct, or optimal.

Luckily, one of our Collection mandates is to "click everything you can in every order possible". So if a NPC offers you 5 options, the Collector player will click the first option, then go back in, click the 2nd option, go back in, etc - until all options are clicked from that same dialog point.

The net result of this are dozens of conversation_id's with the same dialog options in them. Again, most of this can be discarded, but it helps determine the flow of conversation. Once you get used to the data and how it is presented, building dialogs will become much easier.

Back to DB Editor