Console



By using the console you can modify various game parameters in and. However most console commands are classified as "cheats", and the command  must first be entered into the console to activate those.

WARNING: Activating the console cheats causes achievements to be disabled for that game, not only for the session. Though entering  another time or reloading a subsequently created savegame will disable cheats again, the achievements remain blocked unless a savegame from before using the command initially for the affected play through is chosen. WARNING: Using console commands may mess up your game.

Need help with the console? Feel free to ask on the talk page.

About
The main purpose of the console is to give developers and modders the ability to test underlying systems and mechanics on any regular copy of the game, and players the freedom to explore and tinker without restriction.

Opening the console
For most keyboard layouts the default key that opens the console is either backtick ( - same key as tilde , found above tab, to the left of the 1 key on a US keyboard), or "o with diaeresis" (  found below P, to the right of the L key on a Swedish keyboard).

On home consoles, the console can be opened by holding down the left trigger (LT on Xbox, L2 on PS4), then clicking in the right thumbstick (RS on Xbox, R3 on PS4). After entering the command, press enter to finalize input, it can be submitted by clicking the right thumbstick again. A physical keyboard may also be plugged in to make inputting commands easier.

To rebind the console key, go to Options (by pressing Esc in-game) > Controls > Interface > Toggle Console, and bind it to your key of choice.

Note that in after pressing the console key, the Enter key (right thumbstick on console) must be pressed before entering a command (and then again to actually submit the command). This is not required for Deadfire.

The console can be opened up in-game, and in the main menu - but not during loading screens. Also note that the combat log/output is not visible while on the world map, which can make observing the result of entered commands difficult.

Entering commands
A command is an instruction that defines something that the game should do or change. Internally, each command is mapped to a function (or "method"), which is a block of code that actually carries out the command.

Most commands have parameters (also called "arguments"), that are entered after the command and describe information that the command should act on. Parameters are named to give some indication as to what they are for, or what information is expected.

Each command may define any number of parameters (or sometimes none) that are required as part of the command. Unlike a traditional console, all parameters must be entered otherwise the console will return an error. Errors and output messages are shown in the combat log. While the Deadfire console will output feedback on every command - and usually nothing if the command is successful - note that the console in Pillars of Eternity will not display errors, making it tricky to find out what went wrong, if anything. To suppress errors in Deadfire, you can prefix the command with.

An example of a typical console command is as follows:

Here, "GiveItem" is the command, and "Item_Pet_Kaz" is its parameter. Note that most commands are NOT case sensitive. If the parameter contains spaces, enclose it, or the entire parameter section, in quotes to prevent the whitespace being flagged as the end of a parameter. Escape characters are not supported in the console, however Unity-formatted Rich Text is.

As with a traditional console, you can use the Up and Down arrow keys to cycle through previously entered commands, and use the Tab key to complete partially entered commands and parameters (but only object instances of the parameter type) to save having to type them out. Pressing tab key after a completed command or parameter will cycle to the next valid value, and shift-tab will cycle to the previous value. Deadfire has slightly more control over navigating, selecting, and cursoring through text in the console, but both games have these features.

Sometimes you might find that pressing enter to run a command also propagates the keypress to whatever window is opened in-game (for example, a dialogue window). While most UI elements handle this, some do not, which can be annoying if it affects whatever you're trying to do. In this case, you may use Control + Enter to enter a command. This works as most other UI elements are looking for keypresses with no modifiers, while the console doesn't mind either way.

Multiple commands can be chained together using  between commands (that is, space-ampersand-space). If you plan on entering many commands at once, look at using the built in and Batch functions. You can also use to bind a command to a key or key combination so that it executes whenever the key combination is pressed, which saves having to open the console or type anything at all.

Referencing instanced objects
Some commands take parameters that reference GameObject instances in-game. These objects either exist as part of the loaded scene, or are created at runtime by "instantiating" a prefab, hence the term "instances". Examples of instanced objects are characters, creatures, party members (including the player), stores, etc. Generally any object in the scene that was created and has a "presence" in game can be referred to as an instance. Because instantiated objects only exist as part of the running scene, they are unloaded and loaded in as part of it, and therefore cannot be referenced unless the player is in the location where the instance is still in memory.

Not all objects within the hierarchy can be referenced! Only GameObjects that contain an InstanceID behaviour are able to be referenced via the console. Onyx stores a GUID to GameObject lookup table of all active InstanceID's in the scene. If GameObject with an InstanceID starts inactive, or is disabled through means other than, it will not be in this table, and cannot be referenced.

Wherever a command lists a parameter as a "Guid (Instance ID)", it expects either the GameObject name or GUID string of the instance. You are able to use these interchangeably. By default Unity will name an instantiated object by the name of the prefab they were instantiated from, with the suffix "(Clone)". Additional instances of the prefab will have the same name (for example, for multiple enemies of the same type), so in this case you can use the GUID, which will be unique for every created instance.

Thankfully, the console is forgiving, and doesn't always require the name to be typed in full, making it relatively easy to just guess the name of an instanced object by using a portion of its name (e.g. a "Flame Naga Archer" resolves to "CRE_Naga_Flame_Archer(Clone)" by typing in "naga".)

If this doesn't cut it, there are a number of other ways you can find the name or GUID of an instance:


 * With the command, which will print a list of GameObjects/Transforms that are named like the parameter name in the current scene. If an object has an InstanceID, its GUID will be printed in brackets beside it.
 * With the command to show a UI which will display the objects under the cursor.
 * With the command (poe2 only), you can get the instance id (GUID) of the object under the mouse cursor. It will be printed to the combat log, and copied to the clipboard.
 * In, with some commands that take the name of a party member; you can use the keywords "player" to affect the player only or "all" to affect all party members.
 * In you can view the scene hierarchy (which mimics the hierarchy from the Unity Editor) with the command.

Note that in poe1, many commands that use instanced objects are case sensitive and will NOT automatically resolve! Use to get the correct capitalization.

Many character-centric instances are unloaded on the world map, meaning any commands that reference a character instance ID will fail to find the associated object, and therefore will not work when used on the world map. This can be confusing, as the console output is not shown to indicate this. As a general rule of thumb, always use instance commands (with an instance name) in player navigable scenes, or alternatively use the cached/fixed GUID's instead (as listed below), as these will always resolve successfully.

There are some special constant GUIDs that always point to certain objects. Some of these GUIDs are "scoped", meaning they only apply to the context of the object on which a command or conditional was called. For example, using the this GUID in a command will automatically resolve to the instance ID of the calling object. Scoped GUIDs have little use in the console, where there is no associated context - and no way to set it.

Referencing fixed game data
In addition to instances, some commands require parameters that take the ID/GUID of fixed data not pertaining to a particular instance of an object. This includes things like items, maps, conversations or abilities. Wherever a command lists a parameter as "Guid (SomeTypeHere)", it expects either the name or the GUID of data of that type. Most of these ID's can be found on the associated wiki page.

The way in which fixed game data is stored differs between and.

In Pillars of Eternity
Pillars of Eternity takes a very static approach to game data. Every object, including items, abilities, creatures, etc, is stored in its own prefab/bundle (with the extension ".unity3d") containing all the information pertaining to it. These bundles are stored in the game directory, under:

As such, it's trickier to find information in poe1 than it is in Deadfire, but it does mean the data is less fragmented. You can use a tool like Unity Assets Bundle Extractor to view and extract the data.

In Deadfire
Deadfire defines the namespace  for types that are used as game data, all of which are derived from. These GameDataObjects are serialized and stored in JSON-formatted ".gamedatabundle" text files that are loaded at runtime. They can be found in the following directories:
 * - The vanilla base game Game Data Bundles. Always loaded first.
 * - Expansion and DLC Game Data Bundles. Always loaded second, if the associated expansion is installed.
 * - Game Data Bundles from mods. Loading can be enabled and disabled from Main Menu in the Mod Manager tab of the Options menu. The load order can also be modified in the Mod Manager.

Presumably to save disk space, the files are formatted without the indents, breaks, and spacing. To make it more readable, you can use a JSON formatter like this one for Notepad++.

Each bundle contain an array of GameDataObject's. Each entry contains the name of its underlying, the  ,  , and of course all the relevant data from the derived type made up of GameDataComponent's. As with instanced objects, the GUID of the GameData can be used interchangeably with the DebugName.

See the types table below for an overview GameDataObject derivatives, and in which files they are found.

The console in Deadfire also provides some commands for working with and finding GameData:
 * You can also use to print the DebugName of a GameData GUID.
 * Use to search for GameData entries.

See Game Data Formats - Concepts for more information.

Enumerations
In addition to GameData ID's, some parameters take an enumeration, which can be one of a set number of named values. The input is parsed from a string to the enumeration type, but will also accept the underlying type of the enum (by default a zero-based "index", e.g. 0 for the first value, 4 for the fifth value).

Generally in the case where the underlying type is overridden, you are able to pass "between" values that will still be correctly evaluated. For example  from poe1 takes a , which defines  ,  , and  , so while you can pass the string   (which will evaluate to 1) the command will still accept  , even though it isn't defined in the enumeration.

A list of commonly used enumerations can be found below.

Prefabs
Some commands require the name of a prefab, and will accept either the path of the prefab, or simply the name without extension. The command can be used to find the name a prefab, taking an AssetBundleHint enumeration and any portion of the ID of the object.

Global variables
Both poe1 and poe2 use global variables to store persistant flags associated with the hundreds of one-time checks that are made during gameplay. These include things like whether or not the party has a particular key or item, or has taken a particular action during a quest for example. The variables themselves are basically key-value pairs, containing a tag and an integer value.
 * poe1 (XML):
 * poe2 (JSON):

Global variables are not to be confused with 'global scripts, which are scripts consisting of a sequence of commands that can be executed with a single command and the globalscript ID.

See Globals for a complete list of global variables.

Conditionals
Conditionals are functions that perform some sort of check to return a Boolean true or false. They are often used in scripted interactions and dialogue where it requires a check to be performed before allowing an action, or presenting a dialogue option for example. They are similar to regular commands, but they cannot be used directly. Instead you can use to print the result of a conditional.

Note that when using, if passing 1 or more parameters to a conditional, the command and its parameters must be enclosed in quotes to encapsulate it as a single argument, for example:.

See Conditionals for a complete list of available conditionals.

Conversations
Conversations are referenced similarly to GameData, however they do not appear in commands that query GameData. Each character conversation and scripted interaction is saved to its own file, the structure of which is functionally identical in both poe1 and poe2. Each contains a series of nodes that define what a character says, who they say it to, generally defining the flow of dialogue. Nodes may be conditionally shown or branched depending on whatever check is required. The ID fields are used to identify the nodes, but also reference the ID of the string in the associated stringtable. The stringtables usually have the same name as the conversation bundle.
 * In poe1 (XML):.
 * In poe2 (JSON):.
 * Poe1 string tables (XML):.
 * Poe2 string tables (XML):.

Stringtables
Any language-based text that is shown in-game is usually retrieved from a stringtable. A stringtable file is an XML-formatted text file with the extension ".stringtable". Each entry in the table contains an ID unique to that table, as well as the text itself. GameDataObject's containing a "Name" or "DisplayName" field with an integer as its value are likely referencing the ID of a string in a stringtable. Depending on the language selected, the path to a stringtable is changed to point at the directory containing the localized version of that table. Each directory is an ISO 639-1 code one of the 9 supported languages:


 * poe1:.
 * poe2:.

Quests
Quests are essentially conversations without a speaker. They are made up of a series of objective and end state nodes, along with conditions and checks to determine the logical flow of the quest and what is considered to be a quest failure or success. Changes are made to the state of a quest when the player interacts with objects, speaks with NPCs, kills an enemy, etc.

Most quests keep track of their state using a global variable. When the variable is set to a specific value, this triggers the completion of an objective.

In poe1, quests are contained in XML-formatted  files, found in the following directory:

In poe2, the logic behind all quests is found in the JSON-formatted file:

Stringtable IDs

Each quest entry has an accompanying stringtable used to fill out the quest log. The stringtable node system is very much associated with the series of ID's under each  of the quest. The numbering system for these string tables is as follows:
 * Entry  is always the quest name.
 * Entries after zero with a single digit are objective 's. In the journal these can be folded out to reveal more information about what you've learned about that objective. Objectives are numbered chronologically.
 * Entries starting with 10000 are the initial s for each objective. 10000 is always the quest description at the top of the journal. 10001 is for the first objective, 10002 is for the second, and so on.
 * After that, objective  always start with 20000. The order - as well as which addendum belongs to which objective, is determined using the   field of each objective node, which lists the last digits of the addenda connected to the objective.
 * Entries starting with 30000 are s. These are always shown after the quest description in the journal, and only appear once the quest has reached an end state.
 * Entries starting with 40000 are . As the name suggests, they are descriptions that are used in place of both the root description, and objective descriptions in the case that the quest or objective was started via another route.

When using quest state related console commands, do not confuse stringtable entry IDs with the node IDs. Always use the node ID. Objective nodes are the same single-digit values, but addenda, end states, and alternate descriptions are always the stringtable entry ID, minus 20000, 30000, and 40000 respectively. The "Journal" section of quest pages lists the string table entry ID's, as these are unique across the board.

Other tips
General
 * Since both games run on Unity, you can use the slew of command line arguments that the engine provides when launching the game. Of note is the  argument, used to pipe the output of the Unity Debug log to a file, which can be useful when troubleshooting errors.

In 
 * Pressing the F11 key after enabling cheats via  will display a "Debug Transition" menu which will allow you to jump to any location in the game.
 * If on the main menu screen it also will show some options for starting a new game (e.g. difficulty) and will provide you with the choice of a default party loadout instead of using your current save game.
 * Note that starting a new game with this menu will bring with it the same restrictions that a brand new character has. In order to enable access to the ship and the ship management interface, use the console command  to complete the quest Stranded.
 * After enabling cheats you can press Shift + T to teleport your party (or ship) to the position under the cursor.
 * Press the Delete key to refresh or clear on-screen debug UI's that are only drawn once.

In 
 * Pressing the F11 key after enabling cheats via  (and only while in-game) will display a "World Map" debug menu with a list of all locations.
 * After enabling cheats, you are able to hover your cursor over any character and press:
 * Shift + H to revive a dead or unconscious character to full health and stamina.
 * K to instantly deal 10x their current stamina as damage (effectively killing them)
 * Shift + K to play the character's hit reaction animation, but deal no damage.
 * U to instantly apply a stamina change of -100% of a character's current stamina, maiming them and causing them to fall unconscious.
 * If mode is enabled:
 * F9 to disable fog of war (same as or ).
 * F10 to return to the main menu.

List of commands
In, commands are sourced from the  and   classes. No other documentation is available.

In, the commands available are pulled from the classes , and. More information regarding the syntax and parameters of these commands (only in Game.Scripts) can be found in the modding documentation, either in the game directory  or on Obsidian's website here.

Most if not all commands in the Scripts class of both games require "IRoll20s" in order to be used.

🡡 Return to top

Built-in types
The following is a subset of built-in types, and only those used by console commands.

Deadfire types
The following is a small subset of types from the  namespace. This doesn't outline their members, but instead a brief description and which file the data of this type is found. Using the command will return a list of GameData ID's that match the input string. For a full list of types, as well as their members and components attached, see Game Data Types.

Enumerations
The following is a subset of enumerations that are used as parameters in some console commands.

Shared enums
This is a list of enumerations used in both games.

Deadfire enums
For a full list of enumerations in Deadfire, see: Enumerations.