Modding:Item Json Properties: Difference between revisions
CreativeMD (talk | contribs) No edit summary |
CreativeMD (talk | contribs) No edit summary |
||
Line 1: | Line 1: | ||
A complete list of all available properties | __NOTOC__ | ||
== Overview == | |||
A complete list of all available properties | |||
<table id="treeviewtable" class="table table-bordered tt-table" style='table-layout: fixed'> | <table id="treeviewtable" class="table table-bordered tt-table" style='table-layout: fixed'> | ||
Line 5: | Line 7: | ||
<th width='300' align='left'>Property</th> | <th width='300' align='left'>Property</th> | ||
<th width='200' align='left'>Type</th> | <th width='200' align='left'>Type</th> | ||
<th width=' | <th width='120' align='left'>Default</th> | ||
<th align='left'>Usage</th> | <th align='left'>Usage</th> | ||
</tr> | </tr> | ||
Line 15: | Line 17: | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td colspan="4" style='font-size: 14pt; border-bottom: 2pt solid black; padding-left: 100px; | <td colspan="4" style='font-size: 14pt; border-bottom: 2pt solid black; padding-left: 100px;'><b>Core (no byType available)</b></td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td scope="row"><div class="tt" data-tt-id="p_code" data-tt-parent="root"> | <td scope="row"><div class="tt" data-tt-id="p_code" data-tt-parent="root">Code</div></td> | ||
<td>string</td> | <td>string</td> | ||
<td> | <td>required</td> | ||
<td>A unique identifier for the | <td>A unique identifier for the block.</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td scope="row"><div class="tt" data-tt-id=" | <td scope="row"><div class="tt" data-tt-id="p_code_info" data-tt-parent="p_code" data-invisible="true"></div></td> | ||
<td> | <td colspan="3"> | ||
A '''domain prefix''' will be added dynamically depending on the location of the file. Every mod and VintageStory itself have a unique prefix. | |||
For example the code '''<code>stone</code>''' turns into '''<code>game:stone</code>'''. | |||
The code identifier has to be unique inside its domain. In theory there could be equal identifiers with different domain prefixes. | |||
Find out more about [[Basic Modding#Domains|Domains]]. | |||
</td> | |||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td scope="row"><div class="tt" data-tt-id="p_enabled " data-tt-parent="root"> | <td scope="row"><div class="tt" data-tt-id="p_enabled" data-tt-parent="root">Enabled</div></td> | ||
<td>boolean</td> | <td>boolean</td> | ||
<td>true</td> | <td>true</td> | ||
<td>If the | <td>If the block will be loaded or not. Can be used to temporarily remove the block.</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td scope="row"><div class="tt" data-tt-id=" | <td scope="row"><div class="tt" data-tt-id="p_variantgroups" data-tt-parent="root">VariantGroups</div></td> | ||
<td> | <td>array of object</td> | ||
<td> | <td>-</td> | ||
<td> | <td>Allows you define multiple variants of the same block.</td> | ||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td scope="row"><div class="tt" data-tt-id=" | <td scope="row"><div class="tt" data-tt-id="p_variantgroups_info" data-tt-parent="p_variantgroups" data-invisible="true"></div></td> | ||
<td> | <td colspan="3"> | ||
The variantgroups property allows you to define multiple variants of this block. All of them will have their unique pattern, which will be added to the block code. | |||
An easy example would be a bowl, which can either be raw or burned: | |||
<syntaxhighlight lang="json"> | |||
variantgroups: [ | |||
{ code:"type", states: ["raw", "burned"] }, | |||
], | |||
</syntaxhighlight> | |||
Meaning there will be two blocks <code>bowl-raw</code> and <code>bowl-burned</code>. | |||
---- | |||
It's also possible to define multiple groups. | |||
<syntaxhighlight lang="json"> | |||
variantgroups: [ | |||
{ code:"state", states: ["closed", "opened"] }, | |||
{ code:"contents", states: ["empty", "cabbage"] }, | |||
], | |||
</syntaxhighlight> | |||
As a result you will have 2x2 groups, which will be added one after each other: <code>barrel-closed-empty</code>, <code>barrel-closed-cabbage</code>, <code>barrel-opened-empty</code> and <code>barrel-opened-cabbage</code>. | |||
---- | |||
Additionally it is possible to refer to external lists that are found in the worldproperties folder, such as <code>block/rock</code>, which contains all states of all rock types. This used for <code>gravel</code>, <code>sand</code> and <code>rock</code>. It's a good way to keep everything organized: | |||
<syntaxhighlight lang="json"> | |||
variantgroups: [ | |||
{ loadFromProperties: "block/rock" }, | |||
], | |||
</syntaxhighlight> | |||
Here is a full list of all groups and their variants (you can also find them in the <code>assets/worldproperties</code> folder): | |||
{{:json:block:worldvariantgroups}} | |||
---- | |||
Futhermore there are two ways of combining groups together. So far we covered the default combination mode, which is <code>multiplicative</code> (the total count of variants is the product of all states). | |||
Let's take a look at a different example (flowerpot), which uses the <code>additive</code> combination mode: | |||
<syntaxhighlight lang="json"> | |||
variantgroups: [ | |||
{ code: "type", states: ["raw"] }, | |||
{ code: "empty", states: ["empty"], combine: "additive" }, | |||
{ code: "flower", loadFromProperties: "block/flower", combine: "additive" }, | |||
{ code: "mushroom", loadFromProperties: "block/mushroom", combine: "additive" }, | |||
{ code: "sapling", loadFromProperties: "block/wood", combine: "additive" }, | |||
], | |||
</syntaxhighlight> | |||
The variants are <code>flowerpot-raw</code>, <code>flowerpot-empty</code>, <code>flowerpot-{all flowers}</code>, <code>flowerpot-{all mushrooms}</code> and <code>flowerpot-{all saplings}</code>. | |||
<code>Additive</code> mode could also be called separate, since it defines a variant separate from all the other groups: | |||
<syntaxhighlight lang="json"> | |||
variantgroups: [ | |||
{ code: "something", states: ["same", "different"] }, | |||
{ code: "type", states: ["raw", "baked"] }, | |||
{ code: "empty", states: ["red", "green"], "combine": "additive" }, | |||
], | |||
</syntaxhighlight> | |||
In this case, the result would be <code>same-raw</code>, <code>same-baked</code>, <code>different-raw</code>, <code>different-baked</code>, <code>red</code> and <code>green</code> | |||
</td> | |||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td | <td scope="row"><div class="tt" data-tt-id="p_byType" data-tt-parent="root">(any) byType</div></td> | ||
<td>key: string; value: object</td> | |||
<td>-</td> | |||
<td>You can create properties for certain variants of the block.</td> | |||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td scope="row"><div class="tt" data-tt-id=" | <td scope="row"><div class="tt" data-tt-id="p_byType_info" data-tt-parent="p_byType" data-invisible="true"></div></td> | ||
<td></ | <td colspan="3"> | ||
In order to define properties for specific variants you can add '''byType''' to the property name. This allows you to define it depending on the type and always follows the same syntax: | |||
<syntaxhighlight lang="json"> | |||
(property)ByType: { | |||
"selector": property, | |||
"selector2": property2, | |||
... | |||
} | |||
</syntaxhighlight> | |||
If the selector matches the name of the variant the given property will be used. Keep in mind that only the first matching one will be used (everything below will be ignored). | |||
A slab for example has two variants ('''up''', '''down'''), which have different collision boxes: | |||
<syntaxhighlight lang="json"> | |||
collisionboxByType: { | |||
"*-down": { x1: 0, y1: 0, z1: 0, x2: 1, y2: 0.5, z2: 1 }, | |||
"*-up": { x1: 0, y1: 0.5, z1: 0, x2: 1, y2: 1, z2: 1 } | |||
}, | |||
</syntaxhighlight> | |||
The char '''<code>*</code>''' stands for anything. In this case it ignores the code of the block. | |||
Furthermore this opens up even more possbilities for more advanced selectors like this one for doors: | |||
<code>*-north-*-opened-left</code>. This will ignore the second variantgroup. Additionally ByType can also be used for child properties: | |||
<syntaxhighlight lang="json"> | |||
collisionboxnbox: { | |||
x1: 0, y1: 0, z1: 0.875, x2: 1, y2: 1, z2: 1, | |||
rotateYByType: { | |||
"*-north-*-opened-left": 90, | |||
"*-north-*-closed-left": 0, | |||
"*-west-*-opened-left": 180, | |||
"*-west-*-closed-left": 90, | |||
"*-east-*-opened-left": 0, | |||
"*-east-*-closed-left": 270, | |||
"*-south-*-opened-left": 270, | |||
"*-south-*-closed-left": 180, | |||
"*-north-*-opened-right": 270, | |||
"*-north-*-closed-right": 0, | |||
"*-west-*-opened-right": 0, | |||
"*-west-*-closed-right": 90, | |||
"*-east-*-opened-right": 180, | |||
"*-east-*-closed-right": 270, | |||
"*-south-*-opened-right": 90, | |||
"*-south-*-closed-right": 180 | |||
} | |||
}, | |||
</syntaxhighlight> | |||
</td> | |||
</tr> | </tr> | ||
<tr> | <tr> | ||
<td | <td colspan="4" style='font-size: 14pt; border-bottom: 2pt solid black; padding-left: 100px;'><b>Specific</b></td> | ||
</tr> | </tr> | ||
</table> | |||
</table> | |||
Revision as of 12:30, 24 October 2017
Overview
A complete list of all available properties
Property | Type | Default | Usage | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
json |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Core (no byType available) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Code |
string | required | A unique identifier for the block. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A domain prefix will be added dynamically depending on the location of the file. Every mod and VintageStory itself have a unique prefix. For example the code The code identifier has to be unique inside its domain. In theory there could be equal identifiers with different domain prefixes. Find out more about Domains. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Enabled |
boolean | true | If the block will be loaded or not. Can be used to temporarily remove the block. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
VariantGroups |
array of object | - | Allows you define multiple variants of the same block. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The variantgroups property allows you to define multiple variants of this block. All of them will have their unique pattern, which will be added to the block code. An easy example would be a bowl, which can either be raw or burned: variantgroups: [
{ code:"type", states: ["raw", "burned"] },
],
Meaning there will be two blocks It's also possible to define multiple groups. variantgroups: [
{ code:"state", states: ["closed", "opened"] },
{ code:"contents", states: ["empty", "cabbage"] },
],
As a result you will have 2x2 groups, which will be added one after each other: Additionally it is possible to refer to external lists that are found in the worldproperties folder, such as variantgroups: [
{ loadFromProperties: "block/rock" },
],
Here is a full list of all groups and their variants (you can also find them in the For example, the following creates a variant group named orientation. It contains 5 states. variantgroups: [
{ code: "orientation", states: ["up"], loadFromProperties: "abstract/horizontalorientation" }
],
Unwanted variant states can be filtered out with the
Wondering where some links have gone?
Futhermore there are two ways of combining groups together. So far we covered the default combination mode, which is Let's take a look at a different example (flowerpot), which uses the variantgroups: [
{ code: "type", states: ["raw"] },
{ code: "empty", states: ["empty"], combine: "additive" },
{ code: "flower", loadFromProperties: "block/flower", combine: "additive" },
{ code: "mushroom", loadFromProperties: "block/mushroom", combine: "additive" },
{ code: "sapling", loadFromProperties: "block/wood", combine: "additive" },
],
The variants are
variantgroups: [
{ code: "something", states: ["same", "different"] },
{ code: "type", states: ["raw", "baked"] },
{ code: "empty", states: ["red", "green"], "combine": "additive" },
],
In this case, the result would be |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
(any) byType |
key: string; value: object | - | You can create properties for certain variants of the block. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In order to define properties for specific variants you can add byType to the property name. This allows you to define it depending on the type and always follows the same syntax: (property)ByType: {
"selector": property,
"selector2": property2,
...
}
If the selector matches the name of the variant the given property will be used. Keep in mind that only the first matching one will be used (everything below will be ignored). A slab for example has two variants (up, down), which have different collision boxes: collisionboxByType: {
"*-down": { x1: 0, y1: 0, z1: 0, x2: 1, y2: 0.5, z2: 1 },
"*-up": { x1: 0, y1: 0.5, z1: 0, x2: 1, y2: 1, z2: 1 }
},
The char Furthermore this opens up even more possbilities for more advanced selectors like this one for doors:
collisionboxnbox: {
x1: 0, y1: 0, z1: 0.875, x2: 1, y2: 1, z2: 1,
rotateYByType: {
"*-north-*-opened-left": 90,
"*-north-*-closed-left": 0,
"*-west-*-opened-left": 180,
"*-west-*-closed-left": 90,
"*-east-*-opened-left": 0,
"*-east-*-closed-left": 270,
"*-south-*-opened-left": 270,
"*-south-*-closed-left": 180,
"*-north-*-opened-right": 270,
"*-north-*-closed-right": 0,
"*-west-*-opened-right": 0,
"*-west-*-closed-right": 90,
"*-east-*-opened-right": 180,
"*-east-*-closed-right": 270,
"*-south-*-opened-right": 90,
"*-south-*-closed-right": 180
}
},
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Specific |