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: Defining a Block using a Custom Block Renderer
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 Defining a Block using a Custom Block Renderer
mikeprimm edited this page 2013-11-28 07:27:21 -08:00

To define a custom block with its model provided by a custom block renderer, the first step is to select and configure the renderer in the Model Definition file. This is done using the 'customblock:' line, which must include one or more block IDs (via the id attribute), any needed metadata values (via the data attribute), and the class of the custom renderer (via the class attribute). For example, the sandstone stairs block is defined as follows:

 customblock:id=128,,data=*,class=org.dynmap.hdmap.renderer.StairBlockRenderer

Besides these core attributes, certain custom block renderers will offer (and may require) additional attributes to properly configure the renderer. See the 'Attributes' section of the description for the corresponding renderer for the needed details.

Next, the texture references need to be defined in order to supply the textures needed for the custom renderer. The 'Patches Requiring Textures' section of the custom renderer's description defines the 'patch<N>' attributes that need to be supplied for the block. Using these descriptions, the appropriate 'block:' line must be included in the Texture Definition file, with a 'patchN' attribute for each of the indicates patches. For example, the above custom renderer for stairs requires 3 patches: one for the block sides, one for the tops, and one for the bottoms: for Sandstone Stairs, the corresponding line is:

 block:id=128,data=*,patch0=0:sandstone_normal,patch1=0:sandstone_top,patch2=0:sandstone_bottom,transparency=SEMITRANSPARENT

Note: most custom renderers define blocks that are not full, opaque blocks, so the transparency attribute is generally required on the "block:" line. Use the TRANSPARENT setting for blocks that do not block light to other blocks, or SEMITRANSPARENT for blocks that do block light to other blocks (like slabs and stairs).

Contents

Setup

Advanced Configuration

Mod Support

Developers