77
edits
Changes
Datageneration/States and Models (view source)
Revision as of 11:10, 25 October 2020
, 11:10, 25 October 2020Inital Import dokuwiki
The model providers are a specific type of data generators for defining models. All model providers are a subclass of <code>ModelProvider</code>.
<code>ModelProvider</code> provides methods to define models for blocks and items alike: cubes, single textures, doors, slabs, and even custom non-data-generated models as parent models.
== Existing Files ==
All references to textures or other data files not generated for data generation must reference existing files on the system. This is to ensure that all referenced textures are in the correct places, so typos can be found and corrected.
<code>ExistingFileHelper</code> is the class responsible for validating the existence of those data files. An instance can be retrieved from <code><nowiki>GatherDataEvent#getExistingFileHelper()</nowiki></code>.
The <code><nowiki>--existing <folderpath></nowiki></code> argument allows the specified folder and its subfolders to be used when validating the existence of files. By default, only the vanilla datapack and resources are available to the <code>ExistingFileHelper</code>.
== Implementation ==
There are three main abstract implementations of <code>ModelProvider</code>: <code>ItemModelProvider</code>, <code>BlockModelProvider</code>, and <code>BlockStateProvider</code>.
For items, use <code>ItemModelProvider</code> to define their models: override <code>#generateModels</code> and use the helper methods.
For blocks, it is recommended to use <code>BlockStateProvider</code> to define the blockstates, models, and their item models in a single class. It contains an instance of both <code>BlockModelProvider</code> and <code>ItemModelProvider</code>, which can be accessed through <code>#models()</code> and <code><nowiki>#itemModels()</nowiki></code>. <code>BlockModelProvider</code> is used to define only block models.
Call <code><nowiki>#getVariantBuilder(Block)</nowiki></code> to get a <code><nowiki>VariantBlockStateBuilder</nowiki></code> for building a blockstate with different variants, or <code><nowiki>#getMultipartBuilder(Block)</nowiki></code> to get a <code>MultiPartBlockStateBuilder</code> for building a blockstate using multiparts.
<code>ModelProvider</code> provides methods to define models for blocks and items alike: cubes, single textures, doors, slabs, and even custom non-data-generated models as parent models.
== Existing Files ==
All references to textures or other data files not generated for data generation must reference existing files on the system. This is to ensure that all referenced textures are in the correct places, so typos can be found and corrected.
<code>ExistingFileHelper</code> is the class responsible for validating the existence of those data files. An instance can be retrieved from <code><nowiki>GatherDataEvent#getExistingFileHelper()</nowiki></code>.
The <code><nowiki>--existing <folderpath></nowiki></code> argument allows the specified folder and its subfolders to be used when validating the existence of files. By default, only the vanilla datapack and resources are available to the <code>ExistingFileHelper</code>.
== Implementation ==
There are three main abstract implementations of <code>ModelProvider</code>: <code>ItemModelProvider</code>, <code>BlockModelProvider</code>, and <code>BlockStateProvider</code>.
For items, use <code>ItemModelProvider</code> to define their models: override <code>#generateModels</code> and use the helper methods.
For blocks, it is recommended to use <code>BlockStateProvider</code> to define the blockstates, models, and their item models in a single class. It contains an instance of both <code>BlockModelProvider</code> and <code>ItemModelProvider</code>, which can be accessed through <code>#models()</code> and <code><nowiki>#itemModels()</nowiki></code>. <code>BlockModelProvider</code> is used to define only block models.
Call <code><nowiki>#getVariantBuilder(Block)</nowiki></code> to get a <code><nowiki>VariantBlockStateBuilder</nowiki></code> for building a blockstate with different variants, or <code><nowiki>#getMultipartBuilder(Block)</nowiki></code> to get a <code>MultiPartBlockStateBuilder</code> for building a blockstate using multiparts.