Search the Community

Note: I expect that K'aeloree will create another darned good and simple-to-follow tutorial on this in the relatively near future, correctly outlined, and hopefully he will loot and pillage this attempt in the process. These materials are a consolidation and reference on the subject often passed quickly through on the way to getting dialog in the game. As a side benefit, they provide cut & paste template materials as "code shortcuts". -cmorgan There are many different dialog files the engine calls on when the game is unfolding. There are some great tutorials out there, but since I like to prep stuff beforehand, perhaps this breakdown will be a useful addition and save some folks some work coding their mods. Preparation Tutorial links useful to follow before/while/after reading this investigation of dialog file usage: The Road to Banter - by Blue, the Immortal Bard gives you a clue about some of the dialog files and their use, WeiDU Basics - by Japheth you basic IF THEN END states, a series of short tutorials/examples by Kulyok on PPG and several other sites gives you basic examples, and Definitions, Tools and Resources, NPC Creation Series, part 1, by berelinde and the follow up parts 2 and 3 give you a solid basis for all NPC creation including dialog files. A follow up with Theaceface's Ace's very long NPC creation guide should give you a crosscheck on ideas, so that you can get a handle on much of the syntax. Check out K'aeloree's new materials on SHS as well for follow-up and step-by-step breakdowns on things like "What is CD_STATE_NOTVALID and how do I use it?" or "Coding Interjections" or "Coding Friendships and Romances". If you are looking for item dialogs before I get there, there already is a great tutorial available on that: Easy Item Dialogs, for BG2 SoA and ToB by Smoketest. To organize the basic concepts, check out NPC Dialogue 101 by Ghreyfain, also found in a repost at SHS. This tutorial is an expansion of Ghreyfain's original work. After you have finished this tutorial, I suggest a quick visit to a pair of posts/tutorials, for the folks struggling with the whole "why does the order of states in a file matter" thing (or "why does my dialog not play correctly") which often has to do with the order that the engine 'sees' the various states in order to evaluate whether they are true or false. Weights - State Weights - by Japheth and the follow-up Another look at WEIGHT, by JCompton. So now you have some basics down, let's review again exactly what a state is, and what a dialog file is. Introduction: A review of States and Dialog Files Primary concept: dialog files are lists of states. At the most elementary logic level, a dialog file is no more than a list of possible text lines for the game to present. IF ~some_condition_exists~ THEN PRINT_TO_SCREEN ~some_text_with_or_without_additional_links~ END IF ~some_other_condition_exists~ THEN PRINT_TO_SCREEN ~some_text_with_or_without_additional_links~ END IF ~no_condition~ THEN PRINT_TO_SCREEN ~some_text_with_or_without_additional_links~ END Brought into the game by WeiDU reading in the file myMod.tp2, a dialog state is added when WeiDU compiles an IF THEN END code block through a ".d file" into a new or existing game resource designated by the extension .dlg Examples of usage in myMod.tp2: COMPILE ~myMod/c-aran.d~ COMPILE EVALUATE_BUFFER ~myMod/dlg/AnyNameYouwWant.d~ Reminder: when WeiDU compiles a .d file, it does not automatically add or start or set up references, or create a .dlg file. WeiDU still needs entries in the .tp2 file and .d file to set this into the game. So /* standard .d file with dialog */ COMPILE ~myMod/c-aran.d~ /* "evaluated" .d file with dialog and in-file variables that need to be evaluated before adding strings to the dialog.tlk */ COMPILE EVALUATE_BUFFER ~myMod/dlg/AnyNameYouwWant.d~ does not add the dialog files c-aran.dlg AnyNameYouwWant.dlg it just processes those files to find out what you *do* want added to the game. To add specific dialogs to the game, the .d file needs to have some entries. Why don't we start with adding a .dlg file so that the game will recognize a valid dialog: in myMod.tp2: COMPILE ~myMod/c-aran.d~ in the related c-aran.d: BEGIN ~c-aran~ So that gives the i.e. engine a chance at identifying and reading a new .dlg. Let's go on and add three states to c-aran.d. To keep things separated and simplified, we have begun a .dlg, and now we are going to add states to that .dlg - to "append" new materials to the existing file. BEGIN ~c-aran~ APPEND ~c-aran~ END The APPEND block contains all of the states that relate to a single dialog file, "c-aran". Now we add some actual states: BEGIN ~c-aran~ APPEND ~c-aran~ IF ~NumTimesTalkedTo(0)~ THEN BEGIN c-aranstarts SAY ~Aye, welcome, then. This is a fine day on Trade Way." IF ~~ THEN EXIT END IF ~NumTimesTalkedTo(1)~ THEN BEGIN c-aranagain SAY ~I do remember you - we talked before, didn't we..." IF ~~ THEN GOTO c-aranends END IF ~~ c-aranends SAY ~No matter. Welcome again, then. This is a fine day on Trade Way." IF ~~ THEN EXIT END END The only difference in the above three states is what brings them up to the engine's "use this now" list. While that's a whole other topic, we can shortcut to the following breakdown; When the game engine looks in the .dlg file c-aran, and begins evaluating each state in order. It checks agains State 1, and if it finds the condition NumTimesTalkedTo(0) is true, it fires off State 1 - and in the dialog box in-game, the player sees the text string "Aye, welcome, then. This is a fine day on Trade Way". If it finds State 1 is false (for example, if this is the second time we have called on the dialog file "c-aran.dlg"), then the engine skips State 1 and moves to State 2. It tries again; if it finds " number of times talked to = 1", then state 2 is fired, and the player sees the text string "I do remember you - we talked before, didn't we...". If this is the third time we have talked to the NPC assigned the .dlg "c-aran", then we have a problem. State 1 evaluates false and is skipped, state 2 evaluates false and is skipped, and state 3 has no condition - it literally cannot be evaluated. State 3 can only be linked from another state (in this case it is linked from State 2), so the dialog fails. What happens at this point depends on several factors not for discussion in this tutorial. For now, let's go back and fix this so there is no chance of failure: BEGIN ~c-aran~ APPEND ~c-aran~ IF ~NumTimesTalkedTo(0)~ THEN BEGIN c-aranstarts SAY ~Aye, welcome, then. This is a fine day on Trade Way." IF ~~ THEN EXIT END IF ~NumTimesTalkedToGT(0)~ THEN BEGIN c-aranagain SAY ~I do remember you - we talked before, didn't we..." IF ~~ THEN GOTO c-aranends END IF ~~ c-aranends SAY ~No matter. Welcome again, then. This is a fine day on Trade Way." IF ~~ THEN EXIT END END Now, either State 1 or State 2 will always be true, and we can look at the reply section of State 2. It creates a direct link to State 3. So the game evaluates State 2, then follows the reply, and we get two separate dialog boxes: I do remember you - we talked before, didn't we... No matter. Welcome again, then. This is a fine day on Trade Way. For great information on how to use and manipulate states, there are a large number of in-depth and beginner-friendly tutorials. So let's move on to the subject of this tutorial, which is more about organizing groups of states and forming and manipulating dialog file references. Here, we contextualize states, and break down what .dlg files are - what they do for our NPC.

Discussion started from Aran Whitehand development - Synopsis: AreaCheck() does not cover mod added areas without specific addition AreaType() does not cover mod added areas without specific addition AreaType(CITY) was intended to cover city outdoor areas Looking for a way of getting all areas, vanilla and modded, to be able to be checked for being in a city and an inn, so that the appropriate movie can be triggered and content can be tailored and still make sense Suggestions so far: Worse: Research and create mass "MYAREA" script extensions for all such areas Better: Create and identify new AreaType()s and set them up as community resources [-cmorgan AreaType() checks fail. Keep that in mind. You will need a more robust check than AreaType(CITY) to determine where the party is sleeping and cue the appropriate cutscene. You may need to do an extensive OR() block area check for this. Just saying. I've got the code up elsewhere and can post it here if you need it.