Upstream/dynmap
1
0
Fork 0
mirror of https://github.com/webbukkit/dynmap.git synced 2024-11-21 17:55:22 +01:00
Code Issues Projects Releases Wiki Activity
Page: Common Features for Texture and Model Definition Files
Pages
. AWS S3 Storage Addons Advanced Map Configuration Base Plugin Settings Boosting areas on Dynmap BoxRenderer Class Chunk Status Colors Chunk Version Colors Color Schemes Commands Common Features for Texture and Model Definition Files Component Configuration Configuration Configuration.txt Configuring Maps and Worlds using dmap Credits Custom Block Definitions Defining a Block using a Custom Block Renderer Defining a Block using a Volumetric Model Defining a Cuboid Block Defining a Simple Block Defining cuboid models Defining custom lightings Defining custom perspectives Defining custom shaders Defining volumetric models Dmarker Dynmap API Dynmap On Xenon Hosting Service, courtesy of mavbear Dynmap With IIS Using URL Rewrite and applicationrequestrouting thanks to kekec852 Dynmap with Apache httpd on Arch Linux Dynmap with IIS Dynmap with Nginx server on Centos Dynmap with Nginx Dynmap with apache2 on Debian Dynmap with lighttpd on Arch Linux Earthmc maps Example configurations and demo website Exporting World Data in Wavefront OBJ Format External Webserver Basics External Webserver on Linux External Webserver on Windows External Webserver on hosting providers FAQ Features FenceWallBlockRenderer Class File System Storage Forwarding Dynmap port through cloudflare Full list of predefined perspectives Guides HD Map Configuration Home How to compile Dynmap Incompatible mods Installation Setup of Dynmap on Linux Installation Internal Webserver with Caddy as a Reverse Proxy (Linux) Internal Webserver Lighttpd and SQLite on a Raspberry Pi 4 with DietPi Model Definition Files MySQL MariaDB Storage Nginx as a Reverse Proxy OCI; Oracle Cloud Instance; Quick how to enable DynMap PaneRenderer Class Permissions PostgreSQL Storage RedstoneWireRenderer Class Resources SQLite Storage Setting up Dynamic Map with apache2 under Debian Setting up Dynmap through hosting services Setting up the Dynamic Map plugin under Windows Setting up without the Internal Web Server SkullRenderer Class Special texture file types StairBlockRenderer Class Storage Setup Support for Minecraft Servers other than CraftBukkit Support for MinecraftForge based mods Support for Tekkit Texture Definition Files Textures of Dynmap Use dynmap via Pterodactyl Using Markers Using custom block renderers Web Setup Web UI Parameters Web ui login support and permissions World and template settings [Tutorial] Setting up a standalone web server with MySQL SQLite limiting render area
2 Common Features for Texture and Model Definition Files
mikeprimm edited this page 2013-11-25 20:42:12 -08:00
Table of Contents

Texture and model definition files follow a number of common formatting and syntax conventions:

  • All definitions are line-oriented, although some definition lines will dictate the interpretation of following lines.
  • All lines are processed in the order they are defined in the file
  • Any line starting with a number sign (#) or semicolon (;) will be treated as a comment, and ignored
  • Any line may start with a version restriction token, allowing the line only be processed for specific versions of Minecraft or specific versions of the mod associated with the definition file). For Minecraft version restriction, the token is formatted [-], where is the optional minimum Minecraft version matching and is the maximum Minecraft version matching (e.g. '[1.5.0-1.6.4]' would cause the line to only be processed on Minecraft versions 1.5.0 through 1.6.4, while '[-1.6.4]' would be processed on any version up to 1.6.4, and '[1.5.2-]' would be processed on any version starting with 1.5.2). For mod version restriction, the format is similar : '[mod:-]'.

Both texture and model definition files support the following definition lines, which generally are placed at the start of the definition file:

  • 'version:' - If defined, this specifies a global restriction on the Minecraft version. The line is formatted 'version:-', with the indicating the minimum supported Minecraft version and specifying the maximum version (either bound can be omitted to not have an associated minimum or maximum version). If the range specified by the constraints does not match the server's version, processing of the definition file will abort and will not be used.
  • '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 '[-<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 '=' 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.

Contents

Setup

Advanced Configuration

Mod Support

Developers