Upstream/dynmap
1
0
Fork 0
mirror of https://github.com/webbukkit/dynmap.git synced 2024-06-26 06:34:48 +02:00
Code Issues Projects Releases Wiki Activity

Updated Common Features for Texture and Model Definition Files (markdown)

mikeprimm 2013-11-25 20:42:12 -08:00
parent e2c975d521
commit 32d802fbeb
1 changed files with 11 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
Common-Features-for-Texture-and-Model-Definition-Files.md

@ -9,3 +9,14 @@ Both texture and model definition files support the following definition lines,
* 'modname:' - If defined, this specifies the name of the mod associated with the definition file. This is case sensitive, and must match the name used in the mod itself. If the mod uses different names (for different versions, for example), more than one name can be provided (with commas used to separate the list). Optionally, each name can be followed by a mod version constraint, formatted as '[<lower-bound>-<upper-bound]' (as above). In this event, the definition file will only be used if the mod with the given name is installed AND has a version matching the given constraint. For example, "modname:BiomesOPlenty[-0.5.8]" would cause the definition file to only be used if the BiomesOPlenty mod is installed, and has a version of 0.5.8 or earlier.
* 'cfgfile:' - If defined, this specifies the relative path and file name to use to find the configuration settings for the mod (assuming the format is standard for Minecraft Forge mod configuration files). This causes the associated configuration file to be loaded, and symbols to be defined for the various settings within the file (in particular, for the IDs configured for the various block IDs). See 'Configuration Settings' for the details on how these settings are mapped.
* 'var:' - If defined, this allows default values to be defined for symbols that may not be defined in the configuration file (e.g. block IDs for blocks that were not defined in older versions of the mod). The fields defined are formatted as a comma-separated list of '<attrib-id>=<number>' pairs (e.g. 'var:template.id=0,architect.id=0,pathMarker.id=0'). If any 'var:' lines need to be defined, they should be defined BEFORE the 'cfgfile:' lines (otherwise, they may replace the values loaded from the configuration file).
## Configuration Settings Mapping
Configuration files loaded via the 'cfgfile:' directive produce a population of usable symbols, based on the contents of the configuration file loaded. The mapping of the setting names within the configuration files to symbols is as follows:
* Each setting is combined hierarchically with the section containing it, formatted with the section name followed by a '/' followed by the attribute name (e.g. the "my Block ID" setting in the "blocks" would be combined to be "blocks/my Block ID".
* Any spaces within the symbol name are converted to underscores (e.g. "blocks/my Block ID" becomes "blocks/my_Block_ID").
* If the symbol name starts with "block/" or "blocks/", the starting section is stripped off (e.g. "blocks/my_Block_ID" becomes "my_Block_ID", but "biomes/my_Biome" would stay "biomes/my_Biome").
* If the symbol name starts with "item/", it is replaced with "item_" (e.g. "item/myItem" becomes "item_myItem").
* Finally, the value of the attribute is associated with the resulting symbol name.
Symbol values from the configuration file can used in a variety of specific cases in the definition files (most commonly for block ID attribute values). Attempting to use a symbol that has not been defined - via a configuration file or via the 'var:' directive - will result in a processing error while loading the definition file.