We know that to create custom blocks, you need to utilize block states that, even when used, won't significantly impact the game. A good example of this is the note block.
We need to specify the original block state that we intend to replace. For the note block, this state includes the instrument, note, and powered status.
state:instrument:harpnote:0powered:false
If you find this too complicated, you can simplify the process by using a straightforward numeric ID, which the plugin will handle for you. The upper limit of the state is determined by the number of variants available for that particular block.
state:0
You can use any parent model, which can be sourced from Minecraft's built-in models (such as minecraft:block/cube_all), or from your custom models (such as my_blocks:block/template).
Unlike other plugins, in the design of this plugin, items and blocks are separated. Just like in Minecraft's design, some blocks appear as 2D items in the inventory but become 3D when placed. Some blocks look the same before and after placement, while others, like the End Portal block, do not even have a corresponding item form.
You will notice that in this case, the item is also called spirit_log, but this does not conflict with the spirit_log in the block configs because these two IDs are essentially registered in different registries.
In this example, we created an item associated with the block, and its model inherits from the block's model, so it appears the same as the block. Here, we utilized the placeable_block behavior, which is one of the default behaviors provided by the plugin, offering a block placement mechanism similar to the vanilla Minecraft system. Of course, there are many other types of mechanisms available, including custom ones registered through the api, to suit various needs.