-
Notifications
You must be signed in to change notification settings - Fork 51
Extra Data
This page describes all the different things that can be supplied in the extra
block in the CTM json data. Different texture types use this data differently, but some things can be applied to all.
All texture types can have light
data provided. The syntax is as follows:
extra
└─ light : Fullbright. Can be either a number (0-15) or an object. When using an object, block and sky light can be supplied separately.
├─ block : Ranged from 0 to 15. Applies artificial lighting. (Light from torches, glowstone, etc)
└─ sky : Ranged from 0 to 15. Applies daylighting. (Light as if sun-lit in the Day cycle)
Providing this will cause that texture to "glow" brighter than the current light level. If the current light level is above the provided value, nothing will change.
For "map" texture types (currently only "random" and "pattern"), custom size data can be provided. If no size is given, it defaults to 2x2. The syntax is as follows:
extra
├─ size : The height AND width of the map, a number greater than 0. If the map is not square, use height/width separately.
├─ width : The height of the map, a number greater than 0.
└─ height : The width of the map, a number greater than 0.
This covers ctm
and all other CT subtypes (currently ctm_horizontal
, edges
, and edges_full
)
extra
├─ ignore_states : Boolean setting. If true, it will allow connections to other blockstate variations of the same block.
└─ connect_inside : Boolean setting. If true, it will allow connections to the block even if its face is obscured by another block of itself..
For ctm
and all other CTM subtypes (currently ctm_horizontal
, edges
, and edges_full
), the states which the block will visually connect to can be specified. If none are specified, it defaults to the same state as the block this texture is applied to. The syntax is as follows:
extra
└─ connect_to : Either an array of conditions to check, or an object with a default and/or per-side overrides. Multiple conditions will be combined with OR.
├─ A Condition : A condition object which represents a block, and a set of property predicates.
| ├─ block : The registry name of the block this condition applies to.
| └─ predicate : A single predicate or an array of predicates. Multiple will be combined with AND.
| └─ A Predicate : Defines a boolean value based on a single property of a blockstate.
| ├─ A Property Name : A property value. Only a single property/value pair can be given. For example, if this was used for wool, the JSON could look like `"color": "red"`.
| └─ compare_func : The function to compare the property against. Can be one of "=", "!=", ">", "<", ">=", or "<=".
| For example, could be used to compare against the level of a water block, and accept any level
| above a given value. When left out, defaults to "=".
├─ default : The fallback condition when no override is given. Can be an array of conditions.
└─ UP / DOWN / NORTH / SOUTH / EAST / WEST : A condition or array of conditions for this side. Side-override conditions have a special field, shown below.
└─ defer : Either "and" or "or", defines how this condition will combine with "default". If this is left out, this condition will entirely override the default.
This may seem complex, but most of the advanced syntax is only necessary for rare cases. Most of the time, your JSON will look something like this:
"extra": {
"connect_to": [
{ "block": "water" },
{ "block": "flowing_water" }
]
}
This would cause the CTM to connect to any water. Or even simpler, one might just want to connect to a single block type, like a portal block:
"extra": {
"connect_to": [{
"block": "portal"
}]
}
In this case, the []
around the condition object is necessary, as the array is what tells the parser that this is not an object with side-overrides.