New Features:

• Added compatibility for 1.21.9.
• Implemented auto-assignment for custom-model-data, id, state, and char (details to be explained later).
• Added new block behavior types: button_block, fence_block, and stem_block.
• Added configurations for palm button, palm fence, and hami melon.
• Introduced a functions option for crafting recipes, allowing post-crafting operations.
• Added a conditions option for crafting/smithing recipes.
• Enhanced the totem-animation command with support for custom sounds.
• Added a damage function type.
• Introduced an fix-atlas option in config.yml
• Improved the code implementation for item retrieval in give/get commands.

Bug Fixes:

• Fixed light loss for blocks at chunk edges when the chunk is loaded.
• Fixed items based on tags not participating in new recipes promptly after reload.
• Resolved network protocol errors caused by blocks in minecarts in certain versions.
• Fixed the lack of custom sounds when the Wither destroys blocks.
• Addressed issues with merging certain pack.mcmeta formats.
• Fixed mismatched keys in some language files.
• Resolved an issue where trim recipes unexpectedly appeared in the CE UI and were unclickable.
• Fixed client-bound-data/material not being applied in the villager trade UI and component hover events.

API Changes:

• Added an asynchronous block entity tick method.
• Introduced a stepOn method for block behaviors.
• Removed the parent class of ImmutableBlockState.

IMPORTANT / MUST READ
The 0.0.64 update is CraftEngine's first breaking change in several months. But don't worry, you can smoothly upgrade to the new version by following the steps below.

First, let's understand the main changes in the new version. The most core change is the complete removal of the additional-real-blocks design. All real block IDs have been unified from craftengine:note_block_xx to craftengine:custom_xx. This means it's no longer necessary to register custom blocks individually for each block type. Instead, you can configure the serverside-blocks option in config.yml to create a shared internal ID pool for all blocks.

Secondly, mappings now support dynamic loading. They are no longer limited to fixed files in the plugin's root directory but can read configuration files from any resources/xxx/configuration directory.

These changes aim to automate ID allocation. In previous versions, manual ID assignment was often troublesome. Humans are prone to forgetting and had to repeatedly check for used IDs. To reduce the configuration burden, we decided to automate this process, ensuring high reliability without impacting configuration file loading speed.

Automatic ID allocation will apply to the following:

• The custom-model-data option
• The char option for images
• Block appearance states
• Block internal states

Of course, you can still manually set IDs by specifying the relevant options. All content automatically assigned by the plugin will be saved in the cache folder within the plugin's root directory. To clean up outdated cache files, you can directly use the /ce debug clean-cache command.

Safe Upgrade Guide

1. Full Backup: Before starting, be sure to back up the entire CraftEngine plugin folder. This is a crucial good habit that allows for quick recovery in case of issues.
2. Check Map Chunks: If your server contains custom block chunks not properly recorded by CraftEngine (e.g., maps edited by WorldPainter or local WorldEdit), ensure you enable the sync-custom-blocks-on-chunk-load option in config.yml and make sure all chunks requiring synchronization are loaded at least once.
3. Cautious Update and Testing:

• Place the new CraftEngine plugin file into your server. Start the server.
• If startup fails due to block issues in a datapack, temporarily remove the datapack.
• 【Important】 For production environments, it is strongly recommended to first perform the entire upgrade and verification process on a test server. Only after confirming everything is correct should you deploy the complete plugin configuration and datapacks to the production server.

1. Migrate Configuration Files:

• After updating, you will find that the old mappings.yml and additional-real-blocks.yml files have been removed. A new mappings.yml file will be generated in the resources/internal/configuration folder.
• You can choose to manually merge the configuration content from your old mappings.yml into the new file.
• 【Note】 Do not directly overwrite the new file! Ensure all custom content is placed within the block-state-mappings area and pay attention to the indentation format used by the new configuration file.

1. Adjust Block Quantity: Adjust the number of serverside-blocks in config.yml according to your actual needs.
2. Resolve ID Conflict Warnings:

• When the plugin starts, the console may display numerous warnings about internal real block ID conflicts.
• Fastest Solution: Remove the id parameter from each block's configuration. The plugin will then automatically assign unique IDs.
• Alternatively, you can manually assign a new, globally unique id value to each block.

1. Once all warning messages in the console have disappeared, restart the server once more. At this point, the upgrade process is complete, and all functions will return to normal.

Major Configuration File Changes
Multi-State Block Simplification:

• Real ID allocation no longer depends on the variants section, and this section is now optional.
• In the old version, you needed to write lengthy variants configurations for blocks with many variants. Now, you can use partial NBT to uniformly set properties or appearances for all block states meeting specific conditions.

For example, for configuring multiple leaf variants, in the new version you only need the configuration below. There's no need to repeatedly write 28 separate variant entries:

properties:
waterlogged:
type: boolean
default: false
persistent:
type: boolean
default: true
distance:
type: int
default: 7
range: 1~7
id: 100 # The allocation of real IDs has moved here from the old `variants` section. While you can still manually specify one as in this example, we highly recommend simply removing the `id` option. Letting the new system handle fully automatic allocation for you will greatly simplify configuration and avoid potential conflicts.
variants:
waterlogged=false:
appearance: default
waterlogged=true:
appearance: waterlogged
settings:
resistance: 1200.0
burnable: false
fluid-state: water
distance=7,persistent=false:
settings:
is-randomly-ticking: true
Automatic Image ID Allocation:
To simplify configuration, all image resources now support automatic ID allocation. You just need to remove the char option from your original configuration. Additionally, sprites requiring automatic allocation need to declare their layout via the grid-size parameter. Refer to the example below for the specific configuration method:

images:
default:emojis:
height: 11
ascent: 9
font: minecraft:emoji
file: minecraft:font/image/emojis.png
grid-size: 4,4 # Rows, Columns
Automatic Block Appearance State Allocation:
In the old version, manually configuring client block states via the state option was a complex and error-prone process. To simplify this operation, the new version introduces the auto-state option. You simply remove the original state configuration and specify a preset visual type via auto-state, and the plugin will automatically assign the most suitable block state for you.

Example 1: Creating an Arbitrary Solid Wood Block
Suppose you need to create a wood block requiring only a standard 1x1x1 solid visual appearance, regardless of whether the underlying block is a note block, mushroom block, or something else. You just specify solid in auto-state, and the plugin will automatically assign a suitable block.

block:
settings:
template: default:settings/planks
loot:
template: default:loot_table/self
state:
model:
template: default:model/simplified_cube_all
arguments:
path: minecraft:block/custom/palm_planks
auto-state: solid
Example 2: Creating a Leaves Block
If you need to create a new leaves block and don't care if its visual representation is oak leaves or birch leaves, as long as it has a generic leaves appearance, you can configure it as follows (this example is for a template):

appearances:
default:
auto-state: leaves
model:
path: ${model_path}
generation:
parent: minecraft:block/leaves
textures:
all: ${texture_path}
waterlogged:
auto-state: waterlogged_leaves
model:
path: ${model_path}
Currently Available auto-state Preset Types:

• leaves (All standard leaves without water)
• waterlogged_leaves (Leaves containing water)
• lower_tripwire (Tripwire with a smaller collision box)
• higher_tripwire (Tripwire with a larger collision box)
• tripwire (Any tripwire)
• note_block (Note Block)
• mushroom (Mushroom Block)
• solid (Any solid block, including note blocks and mushroom blocks)
• sapling (Any sapling)
• cactus (Any cactus)
• sugar_cane (Any sugar cane)