Upstream
/
dynmap
mirror of https://github.com/webbukkit/dynmap.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Page: Defining a Simple Block
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.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 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
4 Defining a Simple Block
mikeprimm edited this page 2013-11-26 07:08:29 -08:00

A simple block is a solid cubic block filling the whole cube where a block is placed. This is the most common kind of block, and is best used whenever possible (for both simplicity of implementation, and for performance). As the solid cubic block is the default model for a block, these blocks do not need corresponding definitions in the Model Definition Files. The block texture definition is defined via the 'block:' directive.

A simple block has 6 faces, known by a number of equivalent attributes:

  • top or face1 or patch4 (the top of the cube)

  • bottom or face0 or patch1 (the bottom of the cube)

  • north or face4 or patch0 (the side in the negative X direction - currently west: it was north before Minecraft GA)

  • south or face5 or patch3 (the side in the positive X direction - currently east: it was south before Minecraft GA)

  • west or face3 or patch5 (the side in the positive Z direction - currently south: it was west before Minecraft GA)

  • east or face2 or patch2 (the side in the negative Z direction - currently north: it was east before Minecraft GA)

The texture for each side is set by providing a texture reference for the corresponding attribute, in addition to the required block ID attribute, 'id=':

block:id=<block-id>,<side>=<index-plus-function>:<texture-id>,<side>=<index-plus-function>:<texture-id>,...

There are also convenience attributes for common combinations of faces, allowing the same reference to be applied to multiple sides:

  • allfaces (all six faces use the same texture reference)

  • allsides (all four faces on the sides of the block - not the top or bottom - use the same texture reference)

  • topbottom (the top and bottom faces use the same texture reference)

Due to legacy issues, standard simple blocks also need to have the attribute 'stdrot=true' set. This causes the rotation of the top and bottom textures to be correct - otherwise, those textures will be applied 90 degrees rotated from the in-game equivalent.

If the same texture mapping applies to all metadata values, the 'data=*' attribute should be specified (although this is also the default, when no other 'data=' settings are present). If only specific metadata values should use the given texture mapping, one or more 'data=<number>' settings should also be provided.

If more than one block ID uses the same set of texture mappings, additional 'id=' attributes can be specified on the same "block:" line.

Several other special attributes may be specified, if needed:

  • txtid - described above, this allows specifying of a default texture ID to be used by any texture references in the given 'block:' definition that do not have the ':' suffix.

  • transparency - this affects how lighting is calculated for the block. If OPAQUE (the default), the block's surfaces are lit based on the light levels of adjacent blocks. If TRANSPARENT, the block's surfaces are lit based on the light levels of the block itself. If SEMITRANSPARENT, the lighting of the block is a special case blend of the two (used by blocks that block light, but do not fill the cube - such as slabs and steps). If LEAVES, the lighting is a special case corresponding to how leaves are handled (generally the same as TRANSPARENT, except on some versions of Spout).

  • colorMult - this affects any textures using the multiplier-tinting option (17000, 21000), and consists of a 6 digit hexadecimal value: RRGGBB, where RR is the red component (00-FF), GG is the green component, and BB is the blue component.

  • *customColorMult" - this affects any textures using the multiplier-tinting option (17000, 21000), and consists of fully qualified classname of a tinting class. Currently defined values include:

    • org.dynmap.hdmap.colormult.TFBandedWoodColorMultiplier - special tinting function for banded wood in Twilight Forest mod
    • org.dynmap.hdmap.colormult.TFMagicLeafColorMultiplier - special tinting function used for magic tree leaves in Twilight Forest mod
    • org.dynmap.hdmap.colormult.TFSpecialLeafColorMultiplier - special tinting function used for special leaves in Twilight Forest mod

  • layer<M> or layer<M>-<N> - this allows textures to be 'stacked' - if any part of the texture on a given side is transparent, the texture from the next layer is applied to those transparent portions. The value of the 'layer<M>' or 'layer<M>-<N>' attribute is the index of the corresponding 'patch<index>' definition to use for the next layer behind the texture for the side matching 'patch<M>' or all patches between 'patch<M>' and 'patch<N>', respectively. For standard simple cubes, the standard sides use patch0 through patch5, so any additional layer textures need to use patch6 or higher.

  • patch<M> or patch<M>-<N> - these allow definition of additional texture references beyond the first 6 (patch0 through patch5, or the other aliases indicated earlier). For simple cubes, these are only needed for defining layered textures. The value is a texture reference, which is applied to the Mth patch, or to all patches between the Mth and Nth, respectively.

Contents

Setup

Advanced Configuration

Mod Support

Developers