Page tree
Skip to end of metadata
Go to start of metadata

Some notes on Tilesets and their creation.

Contents

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, and to AA PP as per the below.

Basic Tileset

See the Vault for an example of a very basic tileset: https://neverwintervault.org/project/nwn1/other/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
  • 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

Grass

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.
  • 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

Terrain

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).

Crossers

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)

Rules

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.

Tiles

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: (String) 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.
  • Orientation: (Integer) A pathnode can be oriented in increments of 90 degrees. Tilesets make use of values of 0, 90, 180, and -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).

Tile-Door

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.

Tile-Sound

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.

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)

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.


  • No labels