Some notes on Tilesets and their creation.

Tileset Limit

There is a limit of 100 active/in-use tilesets in a module. This limit refers to the actual number of tilesets loaded by the module when it is run. Thus, you could have 200 tilesets in your HAKs, but your loaded areas may only use 100 of them.

Note: If some PW really needed more, NWNX could remove the limit.

Tileset Tutorial

Tonden has written a PDF tutorial available here. This might be transplanted to the wiki at some stage.

This PDF is currently being unpacked and updated to be added to the wiki structure. – Merricksdad

Tileset Definitions

Tilesets are scoped mostly outside the 2da definition system - they have .SET files that are loaded when the area has a particular reference to it.

However loadscreens would still need to be added for it to be functionally complete (easily done however with loadscreens.2da).


At it's base a tileset contains a reference to a lot of different models, which are loaded along with walkmesh on those models into the game when references by an Area.

Tiles may be in groups (ie a special object like a building) of 1 or more tiles. There are also different kinds of tiles - such as roads which are easy to drag and drop, or different heights of tiles using elevation points. Tiles may have doors (with generic or specific door models used) as transition points as well.

Each tile has a connection type for pathfinding from A to Z (uppercase), and a to p (lowercase) as per the below. (Merricksdad: the JPG files shown below are named with double lowercase chars because some FAT tables won't allow uppercase and lowercase versions of the same text in the same folder).

Basic Tileset

See the Vault for an example of a very basic tileset:

File Type SET

A tileset is stored in a file with the extension .SET (note: requires DOS / Windows style line endings, not UNIX ones), however, a tileset is nothing more than a standard Windows INI file. Any standard INI read/write program should be able to view or edit a SET file. Such files are human-readable, and have a format much like JavaScript object notation (JSON) or XML. Being an INI file, the SET layout only has "sections", "keys" or "properties", and "values" for each of those properties. In short, it's a very simple tree structure.

While comment lines in INI files may differ by software, SET files use the semicolon (";") character. In addition, while INI files may sometimes have comments after contents of a line, SET files may only have full line comments. Any line that begins with a semicolon is read as a comment.

SET File Contents

A SET file begins with a section for "GENERAL" (*Note All Caps*) information about the tileset. This section includes the following keys:

  • Name: (String) Such as TNO01
  • Type (Always equals SET)
  • Version (Always equals V1.0)
  • Interior: (Boolean) Set to 1 if the area is meant to be inside
  • HasHeightTransition: (Boolean) Set to 1 if the area can use the Raise/Lower tool in the toolset
  • Transition: (Integer) Defines the height (in meters) of a Raise/Lower offset

    Setting Transition=0 will prevent placing groups and features adjacent to each other.
  • EnvMap: (String) Set the filename (without extension) of the default environment map for areas made with this tileset
  • SelectorHeight: (Integer) Defines the size (in meters) of the tile selector in the toolset when in tile mode (as opposed to object mode)
  • DisplayName: (Optional: Integer, StrRef) This is an integer value reference into the global DIALOG.TLK file. Any value over 16777216 will instead be a reference (minus 16777216) into the module-specific TLK file.
  • UnlocalizedName: (String) This name will be used instead of the "DisplayName" StrRef. It will not be user-language-dependent. As a special use, you can provide two strings separated by a colon (":"). The first string will be used in the toolset when selecting the tileset name. The second string will work as the description of the tileset.
  • Default: (String) This is the default terrain type for the inside of your map. This value must match a "Name" of a terrain in your terrain list for the set
  • Border: (String) This is the default terrain type used around the border of your map. This value must match a "Name" of a terrain in your terrain list for the set
  • Floor: (String) This is the default terrain type used for the main floor of your map. This value must match a "Name" of a terrain in your terrain list for the set


The next section is used to define grass for your tileset, and the section is aptly named "GRASS" (*note again this is in all caps*). This grass will be applied to areas of your tile where the associated WalkMesh faces are set to material 3. The grass section has the following keys:

  • Grass: (Boolean) Set to 1 if this set uses walkmesh grass.
  • GrassTextureName: (String) Defaults to "grass".  Can be customized for the tileset; as an example, the Tropical Tileset uses "ttz_grass"
  • Density: (Single) The density of the grass. (Merricksdad: I don't actually know how grass density is defined in the engine.)
  • Height: (Single) The height (in meters) of the grass.
  • AmbientRed: (Single: Range 0.0 to 1.0) Part of the ambient color of the grass
  • AmbientGreen: (Single: Range 0.0 to 1.0) Part of the ambient color of the grass
  • AmbientBlue: (Single: Range 0.0 to 1.0) Part of the ambient color of the grass
  • DiffuseRed: (Single: Range 0.0 to 1.0) Part of the diffuse color of the grass
  • DiffuseGreen: (Single: Range 0.0 to 1.0) Part of the diffuse color of the grass
  • DiffuseBlue: (Single: Range 0.0 to 1.0) Part of the diffuse color of the grass


Sets must have terrain types, so the next section is "TERRAIN TYPES" (*note the space between words*), which has one key: "Count". Terrain types are listed numerically and are 0-based, meaning the first terrain (when Count = 1) is terrain 0.

Each terrain is then given its own section, in the format of "TERRAIN#" where "#" is the terrain number minus 1. Terrain types have the following properties:

  • Name: (String) The internal name of the terrain used by tiles and general options of the tileset. A terrain name cannot have any whitespace, such as spaces between the words "tall hill".
  • StrRef: (Integer, StrRef) This is an integer value reference into the global DIALOG.TLK file. Any value over 16777216 will instead be a reference (minus 16777216) into the module-specific TLK file.
  • UnlocalizedName: (String) Overrides the display name in the toolset once an ITP map is made for the various terrains.

Common terrains include floor types (library, fancy room, jail) or region types (grass, mountain, water, pit).


Sets can also have crosser types, but these are optional. Crosser types begin in the same way as terrain, with a section called "CROSSER TYPES", with one key: "Count".

Each crosser then begins with a new section "CROSSER#", using the same 0-based index as with terrains. Crossers otherwise have the exact same keys as terrains.

Common crosser types include path types (corridor, mine car tracks, road), linear features (wall, stream, chasm), or modifiers to terrain (smooth, overhang)


Tilesets don't need rules to help a builder, but they can be handy for toolset logic. Therefore a SET file will often have a "PRIMARY RULES" section, again with a single key: "Count" (again zero-based). There are also "SECONDARY RULES", but are not used.

Primary rules begin with their own new section, "PRIMARY RULE#" (note the space). Rules have the following keys:

  • Placed: (String) This is a terrain name
  • PlacedHeight: (Integer) This is a
  • Adjacent: (String)
  • AdjacentHeight: (Integer)
  • Changed: (String)
  • ChangedHeight: (Integer)

When the builder places a terrain tile of type: Placed, adjacent to a type: Adjacent, and when the two associated heights match those given by the respective properties, then the toolset will perform a check on adjacent tiles to see if it needs to change. This silly, but you need a rule for each combination you expect to happen. See an original content tileset for the obviousness of Primary Rules.


You can't have a tileset without tiles, so the next section is "TILES" with a key: "Count" (again zero-based). Each tile begins a new section "TILE#" and has the following keys:

  • Model: (String) The model filename (without extension) which depicts that particular tile. (filename size should be limited to 16 characters)
  • WalkMesh: (string) Always "msb01". (Merricksdad: I don't think this actually does anything)
  • TopLeft: (String) Terrain name of the top-left corner of the tile (+Y direction).
  • TopLeftHeight: (Integer) Number of "transition" heights above zero elevation.
  • TopRight: (String)
  • TopRightHeight: (Integer)
  • BottomLeft: (String)
  • BottomLeftHeight: (Integer)
  • BottomRight: (String)
  • BottomRightHeight: (Integer)
  • Top: (String) Crosser name of crosser which splits the top tile edge.
  • Right: (String)
  • Bottom: (String)
  • Left: (String)
  • MainLight1: (Boolean) Set to 1 if this tile has the MainLight1 AuroraDLight node on the tile model. Light color is customizeable in the toolset. You can set this to 1 even if the light doesn't exist. It simply won't turn on in the tileset, and won't show in game.
  • MainLight2: (Boolean)
  • SourceLight1: (Boolean)
  • SourceLight2: (Boolean)
  • AnimLoop1: (Boolean) Set to 1 if this tile has a looping animation of the same name in the tile model file. This can then be enabled for play in the toolset. You can set this to 1 even if the animation doesn't exist. It simply won't turn on in the tileset and won't show in game.
  • AnimLoop2: (Boolean)
  • AnimLoop3: (Boolean)
  • PathNode: (Single Char) A text index representing the path node type. Used for long-distance path finding. PathNode "A" is the simplest and means that a tile is open on all four edges, without any obstruction in the tile. It is assumed that any unit can traverse the tile in any direction. See pathnodes discussion for more information. Current known path nodes range from uppercase A to Z, and lowercase a to p. There are however some missing very important three-entry per edge pathnodes. Please check the current list for the path node you need before you begin designing tiles with complex walkpaths.
  • Orientation: (Integer) A pathnode can be oriented in increments of 90 degrees. Tilesets make use of values of 0, 90, 180, and -90.
    • 90 degrees is a counter-clockwise rotation.
    • -90 degrees is a clockwise rotation.  Some tilesets use 270 in place of -90.
  • VisibilityNode: (String) Similar to a pathnode, this node does the same for visibility instead of movement, altering things like LOS for spells
  • VisibilityOrientation: (Integer) Used like Orientation for PathNode.
  • DoorVisibilityNode: (String) This is the override for visibility node when a door is placed on the tile. There is no special node for door-pathing, as this is handled instead with DWK walkmeshes and collision planes.
  • DoorVisibilityOrientation: (Integer) Used like Orientation for PathNode.
  • ImageMap2D: (String) Filename of the image representing the mini-map icon for this tile. (filename size should be limited to 16 characters)
  • Doors: (Integer) The count of door placement nodes associated with this tile. See Door nodes below.
  • Sounds: (Integer) The count of tile-based sounds associated with this tile. (Merricksdad: I have not seen this used).


Tiles can have door sub-sections. If a tile has a "Doors" count, then it will have a number of zero-based additional sections in the SET file. Each section includes both the tile index and door index, such as "TILE15DOOR2". Tile-door sections have the following keys:

  • Type: (Integer) This is an index into DOORTYPES.2DA which represents general and tileset-specific door options.
  • X: (Single) The X-axis position of the door placement point. This value is relative to the center of the tile, so negative numbers will be west and south on an un-rotated tile.
  • Y: (Single)
  • Z: (Single)
  • Orientation: (Single) The facing of the placed door object in the toolset. This is also the facing of a creature when it "emerges" after using a transition.


Tiles can apparently have sound sub-sections. (Merricksdad: I don't know the format of the sound section.)

Tile Groups

Tilesets can make use of multi-tile assemblages. This requires a new section "GROUPS" with a single key "Count" (again, zero-based).

Tile groups have their own sections as "GROUP#" and have the following keys:

  • Name: (String) Internal name of the group. Also used as unlocalized name if no StrRef is supplied.
  • StrRef: (Integer, StrRef) This is an integer value reference into the global DIALOG.TLK file. Any value over 16777216 will instead be a reference (minus 16777216) into the module-specific TLK file.
  • Rows: (Integer) Number of rows (Y-axis) covered by this tile group
  • Columns: (Integer) Number of columns (X-axis) covered by this tile group
  • Tile#: (Integer) A tile group has a number of zero-based tile references with values equal to tile indices in this SET file. Tile references must be made in a certain order for the tile group to be drawn correctly. The first reference is always the bottom-left corner tile. Tile references then proceed to the right (columns, x-axis), and then up (rows, y-axis. The last tile should then be top-right corner tile.

Null Tiles

When defining a tile group, you can specify a value of -1 in a tile reference to allow the group to use randomized parts. However, you CANNOT set the bottom-left (first) tile in a group to -1. (Merricksdad: this crashes the toolset for me)

The first tile in the group must also be unique because the ITP file (toolset palette related to this tileset) references only the first tile in the group, will look for where that is in the groups list, and then pull the rest of the group tiles from the list. In the case that you have non-unique first tile in multiple groups, then the last group containing that first tile will be placed. Doing this also makes it impossible to place the other groups using this first tile. Any other tile in the group may be non-unique.

Important note for UNIX users: If you're using a text editor to edit your SET file by hand, make sure you save with DOS file endings (\r\n), rather than UNIX line endings (\n). Using UNIX line endings in the SET file crashes the toolset when you try to create an area.

Toolset Blueprints (ITP)

A set file needs to have an associated ITP file which contains the construction materials, with proper names, for use in the toolset. Good SET editors have built in features to build these for you.

With the advent of NWN: EE, many of these software packages no longer work without being told where the base game folder is, where the NWMAIN.EXE file exists, or where DIALOG.TLK is located. In the event that you don't have DIALOG.TLK associated with the software, the program may crash or otherwise fail when trying to collect StrRef names for tiles, terrains, crossers, tilegroups, or the tileset DisplayName itself.

Toolset blueprints can also be made with a GFF editor. Use an existing tileset ITP file as a starter for your set so you can get an idea of what entry types are needed. For example, the base ITP file for Forest tileset is TTF01PALSTD.ITP.

Toolset blueprints constructed or altered in a GFF editor can have additional subsections, or builder-specific tile or group categories. For an example, check out ITP files associated with the "TNO: Exterior" tileset.

PathNode Explanation

Tile PathNodes help the game's pathfinding system when you move from tile to tile. Within a tile, basic pathfinding systems will navigate a unit through the tile, around Placeables, and across the local WalkMesh. But for tile-to-tile movement, especially across longer distances greater than 2 tiles, a game will need something to speed up the calculation process. PathNodes offer a quick, almost pre-rendered way of getting to a distant location by reading details about a path through tiles from tile-edge to tile-edge.

To read a PathNode image, investigate the black lines crossing the whitespace. If you can enter the tile from an edge, the black line will touch that edge. If that black line crosses to another edge, then there is a path in that region of the tile that will allow you to cross the tile from the entry edge to the exit edge. In short, this converts the entire tile WalkMesh system into a few details and shortens tile-to-tile pathfinding time.

PathNodes can have up to three entrypoints on an edge. Basic tiles, such as open rural or forest areas, will have single lines passing from edge to edge. Intermediate tiles, especially those with height transitions and crossers which block movement, will have one to two lines crossing from edge to edge. PathNodes with three lines per edge can be used to simulate raised sections, hidden passages inside walls, or walkable ledges on a cliff. Another special use of three-line PathNodes is to allow walkable-but-unreachable water. This special case allows for the placement of aquatic monsters with ranged abilities, and when you stand too close to the water edge, they can also physically attack. Other options are regions of air off the edge of a cliff in which aerial attackers can reside, or fire elementals may attack from a river of lava.

Naming Conventions

Tileset models mostly use the following naming convention: xyz01_a01_99. With xyz01 being the abbreviated tileset name, a01 being the type of tile and 99 being the number of tile with that type.
The majority of Bioware tilesets follow this convention for the type:

  • a, b, c, d, e for terrains
  • f, g, h, i, j, k for crossers (if there are streams they are most likely g, roads h and walls i)
  • l, m, n for extra terrains
  • o, p, q, s, t, u, v, w, x, y for groups and features
  • z for edge tiles
  • r for either groups or terrain

(Thanks to Zwerkules and Dafenatotally not Dafena on the vault discord)

  • No labels