Version 23 (modified by 2 years ago) (diff) | ,
---|
Custom/Mod Blocks
WorldPainter supports the use of mod blocks in custom materials, for use in e.g. Custom Terrain types, Custom Ground Cover layers, Custom Underground Pockets layers, etc.. One way to do this is to manually enter the block ID ("resource location") on the material selector (the Select Custom Material or Edit Material screen), and manually add any properties the block might have. This is a lot of work though, and WorldPainter will not know how to treat the block properly during the Export, post processing and lighting phases. As a result the blocks may not be correctly lit, may inadvertently block the placement of Custom Objects, etc.
To alleviate these problems, it is possible to tell WorldPainter about the properties of the known blocks of existing mods, by installing Custom Block Definition Files.
You can create such a file yourself, but ideally they will be created by the authors of mods, or volunteer users. If there is no definition file listed below for a mod you would like to use, please contact the authors of the mod and point them to this page.
Installing Custom Block Definition Files
To add support for a mod's blocks to WorldPainter, follow these steps:
- Download the Custom Block Definition File for the mod below
- In WorldPainter, select
Open custom materials folder
from theTools
menu - Move the downloaded
.csv
file into the opened folder - Restart WorldPainter
For now, everyone working on the same world will have to do this separately; the definitions do not travel with the .world
file. This will be improved in the future.
Supported Mods
Here you can find Custom Block Definition Files for select mods:
None yet. Please contact the authors of your favourite mods and ask them to create such files, or do it yourself, and have them emailed to info@…!
Creating Custom Block Definition Files
Custom Block Definition Files are tables in the form of CSV files that describe basic properties such as the ID, lighting, colouring, and the block properties each block has.
IMPORTANT: Do not use Excel or other spreadsheet software to create or edit these files! They will mangle them. Use a text editor or programmer's editor, for example Visual Studio Code.
Basic format
The files should be CSV files with the following properties:
- Filename extension:
csv
- Encoding: UTF-8 without a BOM
- Field separator: comma
- The first row should contain the field names
- String values should be quoted with double quotes:
"
- Boolean values should be either
true
orfalse
Fields
The data should contain the following fields:
Field | Mandatory | Type | Description |
---|---|---|---|
name | * | String | The namespace and name of the block separated by a colon ("ID" or "resource location") |
discriminator | String | An optional discriminator to discriminate multiple rows with the same name
| |
properties | * | String | A comma-separated list of the names and types of all the properties this block can have. See below for details |
opacity | * | Integer | The opacity of the block (how much light it blocks), from 0 (fully transparent) to 15 (fully opaque) |
receivesLight | * | Boolean | Whether the block should be lit itself, despite being fully opaque (e.g. stair blocks, slabs, etc.). Only applies to fully opaque blocks; should be set to false for other blocks
|
insubstantial | * | Boolean | Whether the block should be considered insubstantial. See below for details |
resource | * | Boolean | Whether the block should be considered an ore or resource. These are replaced with minecraft:stone by the "remove resources" Merge option
|
tileEntity | * | Boolean | Whether the block is a tile/block entity |
tileEntityId | Boolean | If tileEntity is true : the ID of the corresponding behaviour. This is often, but not always, the same as name
| |
treeRelated | * | Boolean | Whether the block is part of trees, or attached to trees. These are removed by the "remove trees" Merge option |
vegetation | * | Boolean | Whether the block is a plant, other than treeRelated . These are removed by the "remove vegetation" Merge option
|
blockLight | * | Integer | How much block light the block emits, from 0 - 15 |
natural | * | Boolean | Whether the block should be considered natural as opposed to being man-made. Chunks with blocks that are _not_ natural have the Read Only layer applied during Import
|
watery | * | Boolean | Whether the block is always flooded with water, regardless of its properties (e.g. water plants) |
colour | Hex | The colour in which the block should be rendered in the editor view, as a hexidecimal number in aarrggbb format, where aa should always be ff (opaque). When not specified, the block will be rendered in magenta
|
Discriminator
The discriminator is used if a block occurs multiple times with the same name but different values (e.g. a different
blockLight
). It consists of a comma-separated list of key-value pairs (separated by equals signs) describing the
property names and values of blocks to which this row should apply. It should only contain the discriminating properties
(those whose value actually determines which row applies).
Examples: berries=false
or waterlogged=true,pickles=3
.
NOTE: when using this field, the block must of course occur at least twice with the same name
, and you must make
sure that all possible permutations of the discriminating properties are covered by exactly one row! In other words: it
must not be possible for no rows to match, or for more than one row to match.
Properties
These are all the properties and their types and values that the block can have. It consists of a comma-separated list of property definitions. A property definition consist of the property name, a colon, and a type definition. The type definition should be one of:
b
: a boolean
i[n-m]
: an integer, where n
is the minimum value and m
is the maximum value
e[val1;val2;...]
: an enumeration, where val1,val2,...
is a semicolon-separated list of possible values
Examples: facing:e[north;south;west;east],powered:b,face:e[floor;wall;ceiling]
or distance:i[1-7],persistent:b
.
Insubstantial blocks
An "insubstantial" block is an inconsequential block that players would presumably not mind being summarily removed or replaced. Usually it is non-blocking (players walk through it) and it implies that it cannot support anything solid. It encompasses things like grass, flowers, water and snow, for example.
More concretely for WorldPainter, a block being insubstantial has the following consequences:
- It will be replaced by other blocks (substantial or not, except air blocks) when placing Custom Objects or when Merging
- It will not block the placement of Custom Objects by default
- Trees and Custom Objects will not be placed on it by default
- The Frost layer will not deposit snow on it
- Custom Ground Cover layers will not be placed on it
Snow
For a block to be eligible to have snow placed on it by the Frost layer, make sure that it is both fully opaque
(opacity
is 15
) and not insubstantial (insubstantial
is false
).
Example
View an example of a Custom Block Definition File here (click on Original Format
at the bottom of the page to download the file). These are some blocks from WorldPainter's own internal block definitions. Don't use these! This is just an example of how to create such a file.
Attachments (1)
-
custom-blocks-example.csv (2.0 KB) - added by 2 years ago.
An example Custom Block Definition File
Download all attachments as: .zip