Some notes on Tilesets and their creation.
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).
See the Vault for an example of a very basic tileset: https://neverwintervault.org/project/nwn1/other/basic-tileset
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.
A SET file begins with a section for "GENERAL" (*Note All Caps*) information about the tileset. This section includes the following keys:
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:
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:
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:
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:
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:
Tiles can apparently have sound sub-sections. (Merricksdad: I don't know the format of the sound section.)
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:
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.
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.
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.