Dialog System Documentation

From Nexus Mods Wiki
Revision as of 13:40, 7 February 2020 by WarhorseStudios (talk | contribs)
Jump to: navigation, search

All dialogs are created in Skald and stored in several DB tables.

Dialogs do not only hold the dialog texts and dialog structure, but also provide crucial means for scripting. They are, in fact, one of the 3 main places for content scripting along with (Quest) Flow Graph and MBT Trees.

Skald provides a human readable look at dialogs which slightly obscures the actual data structure. Skald provides the chapter-subchapter systems for purely organizational purposes. All dialogs are equal, and could theoretically be moved to another subchapter(=quest) without affecting the game in any way.


What happens when you initiate a dialog via Talk action

  1. When you look at an NPC, the dialog system selects all dialogs where the player’s role and the NPC’s role are present, and evaluates validity of all their root sequences.
  2. If it finds any such sequences, the Talk action (press E) is shown.
  3. When you press E the dialog system selects the dialog (actually a topic) with highest priority to be played. If there are more dialogs with the same priority, the player gets to choose which one to start (you almost never want this to happen!). If there are no priority dialogs (=priority is higher than 0) the dialog system simply goes to dialog root without playing any sequence.
  4. Dialog root lists all the valid root sequences from all the dialogs between you and the NPC. Additionally, the dialog system adds an auto-generated topic (End Dialog), but only in root.
  5. You can select any of these sequences which takes you whichever dialog and its structure it belongs to.
  6. If the dialog reaches a DECISION and more than one sub-sequence are valid, the player is again presented with a list of valid sequences. If there is NO valid sub-sequence the dialog abruptly ends (this is treated as an error). If only one sub-sequence is valid the dialog continues automatically.
  7. If a sequence end with END TOPIC the dialog goes back to root. If the dialog ends with END DIALOG the dialog ends then and there. If there is no valid root sequence when the system goes back to root the dialog ends.

Dialog breakdown

A dialog typically looks like this



Each response (line of dialog) must belong to a role (see more in souls, roles...). A dialog may contain any number of roles. Roles are reusable across all dialogs, and are then ascribed to any number of souls, and subsequently a character and a voice. A soul can potentially engage in any dialog where their roles appear.

One role makes a monolog, 3 roles make a trialog, and so on. This particular dialog contains 2 roles which makes it a true dialog. The role JINDŘICH represents HENRY, the player character.


There is no technical difference between monologs, dialogs, trialogs, quadrialogs etc. They however do differ in their usage.

Roles array

A temporary Dialog Context array, with references to the participant entities, is created when the dialog starts. The participants are written in the array in the following order: [0] initiator, [1] first other appearing role, [2] second... etc.

  1. In exit script you can refer to the entity via table reference dc.ROLE
    Utils.GiveItem(player, dc['MILOMIR'], "money", 80) --gives 8 player’s groschen to entity with role MILOMIR
  2. In the entry conditions you can refer to the entities via index number ([0],[1]...etc.) or directly via entity name. Entry conditions which require that contain the word Actor
    GetActorMoney()['Dude'] > 50 --True if player has more than 5.0 groschen GetActorMoney()[0] > 50 --True if dialog initiator (usually the player) has more than 5.0 groschen IsActorInside('q_skalitz_kunes_triggerArea2')[1] --True if second-role participant is inside area specified by area entity name


Types by role count

Monologs - utilize a more lightweight part of the dialog system (it skips some checks and synchronizations), which makes them faster but also somewhat limited. One of the downsides is that a monolog is not guaranteed to be played in their entirety and you SHOULD NEVER expect them to execute any critical logic.

Dialogs are further divided into forced and normal.

Forced dialogs – are initiated by an NPC via a special behavior script. They can happen between any 2 NPCs or an NPC can force it on the player. Both situations are somewhat dangerous and unguaranteed. A dialog forced on the player should always be preceded by some kind of fader situation (fast travel, cutscene, custom fader, jail etc.). A dialog forced on the player should always start with the NPCs role, not the player role, and vice versa.

Normal dialogs – are initiated by using the Talk action on the NPC and are the only safe dialogs. The Talk action is shown only if the soul has ANY valid dialog. A normal dialog should never start with the NPC speaking, unless you know what you are doing.

Polylog (Trialogs and up) – cannot be initiated by the Talk action; must be forced by an NPCs. Since automatic dialog cameras don’t work properly in trialogs (and up), they require hand-made custom camera and pre-determined positions for every participant. That, just like forced dialogs, requires a fader sequence prior to start, if only to hide the forced positioning. Dangerous trick: You can initiate a trialog via Talk action by enabling fake empty dialog(s), which immediately end but turn on a fader screen, which you use for trialog preparation, which then use one NPC to force the trialog.

Kingdom Come: Deliverance: Forum | Before you start | Tutorials & Instructions | Basic Mods | Tools | Documentation | Glossary | EULA