There's three categories of .itp's, so you should make sure that you keep them separated in your head. The .itp files most people are used to knowing exist are the cus.itp files. It's a little backwards to start with them, but since they are the most front facing, I'll start with them. The cus.itp files are a saved, compiled collection of categorized blueprints created from taking everything in your custom palette (blueprint files, like .utp placeable blueprints) and listing them in a hierarchy. As far as I can tell, these .itp files have no use whatsoever in the toolset. They also are not used by the server. They are only for making human readable lists in the Creator for DM's (and players using DebugMode), and are sent to DM's when they connect to a server and stored locally temporarily. They are a product of the toolset, the toolset makes these files for DM's when you save the module. Moving backwards are the std.ip files. The "standard" itp's are just like the cus.itp files, used to display all of the "vanilla" content in the creator for DM's and players in the game. They were produced by Bioware, and the Toolset does not export new copies because generally the standard palette is read only, so everyone's standard palette is the same. (I've customized mine at times to reveal the familiars/summons etc) The third and primary .itp category has no suffix, so that would be something like "placeablepal.itp", and these are the most important categories for the toolset and custom content. These main .itp files are frameworks for the toolset palette, and when you load a module, it uses this framework and the blueprints in the module, and combines them to populate the blueprint lists you see in the toolset. When you save the module, it also uses these .itp's to generate the cus.itp's also by detecting and sorting the blueprints in the module.


So, if you do something like make "custom palettes" for the toolset, like CEP does, you have made a new pal.itp file with new structure, new categories, which are classified purely by number by blueprints, and the presence of this pal.itp override allows you to break the normal layout of the toolset palette, as well as manufacture DM palette palcus.itp files for your running module.


When you reload the palette in the toolset, this wipes the temporary toolset palette (which isn't a palcus.itp), and starting from scratch, grabs the pal.itp, detects all blueprints in your module, and sorts them into your toolset palettes based on the category number of each of those blueprints.

Making it So Custom Templates (Blueprints) Do Not Appear on the Palettes

Although not recommended, some Builders and CC makers find it convenient to directly modify the template files (e.g. UTC, UTI, UTP files, etc.) for vanilla resources, placing them into a HAK file attached to the module. Unfortunately, this method has the undesired affect of having the modified template appear on both the Standard and Custom Palettes. You can fix this by opening the template file with GFF Editor (available in the /util/win32 folder of your EE installation) and changing the PaletteID to 255. The modified template will still appear on the Standard Palette but not on the Custom Palette.   

-written by Symphony in Discord

Modifying Palettes

If you have ever felt like the palette you utilize in the toolset or DM client is too limiting, that you want better definition with additional categories, there is hope for you by creating your own specialized palette. To start modifying palettes, an easy way to begin understanding them is to open your module, then open your ****palcus.itp file within Neverwinter Nights/modules/temp0 with the GFF editor. A simplified list of rules for these files is the following: Every struct needs a string, a struct cannot have it's own substruct (it has to be struct > list > struct), every struct that has an ID cannot have a list with more structs, and every ID has to be unique unless you want two lists with shared blueprints. Unfortunately, using this method will require that you go through and systematically delete all of the blueprints that exist in this list but do not worry as this is not where your blueprints actually exist and they will be added back to the palette once it is generated. To see your modified changes, save it as ****pal.itp to your override folder (or add it to a hak), move/delete the ****palcus.itp in your temp0 folder, and refresh the custom palette that you chose to edit. Once you do so, a new custom palette will be generated. A more detailed tutorial will follow, but this should at least get you started with the basics of creating your own palette.


Also see the ITP documentation, which can be located here: File Format Specification (Bioware)

Naming Palette Categories

Note that the game in EE now supports a (properly named) "NAME" field that can be a text string. The one Bioware added which, well, did work was called DELETE_ME. Patch note: DM Creator Palettes can now contain plain CExoString entries in addition to STRREFs. Strictly speaking, this was possible before (node name was DELETE_ME); we’ve renamed that node to - surprise - “NAME” to make it prettier. This is especially useful for tileset authors.

  • No labels