VanillaReimplementation

VanillaReimplementation is distributed via JitPack. To use it:

1. Find the latest release on JitPack.
2. Select the specific modules (vanilla features) you wish to include in your project.
3. The core module is required. All other modules are optional and depend on your specific needs.

Once you have added the required modules to your classpath, you can hook VanillaReimplementation into your server startup by calling VanillaReimplementation.hook() and passing the result of MinecraftServer.process().

VanillaReimplementation vri = VanillaReimplementation.hook(MinecraftServer.process());

To clone the repository including all necessary submodules, use the following command:

git clone --recurse-submodules https://github.com/Minestom/VanillaReimplementation

In the Minestom vanilla implementation, LootFunction objects are used to modify ItemStack results within a loot table. Each function implements an apply(@NotNull ItemStack input, @NotNull LootContext context) method. Most functions also support a list of LootPredicate objects called conditions; if these predicates are not met within the given LootContext, the function returns the original input without making changes.

Common patterns for LootFunction include:

• Setting components: Modifying data components like enchantments, potion effects, or custom data.
• Modifying quantities: Using SetCount to change the stack size.
• Sequencing: Using Sequence to apply multiple functions in order.

You can combine multiple LootPredicate instances to create complex conditional logic:

• AllOf: Requires every predicate in the terms list to return true.
• AnyOf: Requires at least one predicate in the terms list to return true. If the list is empty, it returns false.
• Inverted: Wraps a single predicate and returns the opposite of its result.

The Recipe interface is the base type for all recipe implementations in the vanilla implementation. It is a sealed interface that includes various recipe types such as crafting, smelting, smithing, and special recipes. Every recipe must implement a codec() method to provide its StructCodec for serialization/deserialization.

Key sub-types include:

• Crafting: Includes Shaped, Shapeless, and Transmute recipes.
• Cooking: Includes Smelting, Smoking, Blasting, and Campfire recipes.
• Smithing: Includes Transform and Trim recipes.
• Stonecutting: A recipe for the stonecutter.
• Special Recipes: Various specialized recipes like SpecialArmorDye, SpecialFireworkRocket, etc.

There are two primary implementations of LootNBT provided in the vanilla implementation:

1. Context: Uses a Target to extract NBT from the environment.
   • block_entity: Returns the NBT of a block, augmented with its x, y, z coordinates and its id.
   • Entity: Returns NBT from a specific entity type (implementation of entity serialization is currently a TODO).
2. Storage: Intended to pull NBT from a specific Key source (implementation of command storage is currently a TODO).

Both implementations use StructCodec for serialization.

// Context implementation example (BlockEntity target)
// When target is 'block_entity', the resulting NBT includes:
// { "x": int, "y": int, "z": int, "id": string, ...original_block_nbt }

Loot entries can use a Standard weight calculation to determine the likelihood of a choice being selected. The final weight is calculated using both a base weight and a quality value, which is influenced by the player's luck.

Formula: finalWeight = max(1, floor(weight + (quality * luck)))

Where luck is the value retrieved from the LootContext using the LootContext.LUCK key.

• weight(): The base weight of the choice (minimum 1).
• quality(): A multiplier for the context's luck value.

This mechanism allows for 'luck-based' loot where higher quality entries become more probable as the context's luck increases.

To optimize world generation, several wrapping functions can be used to cache or smooth density values:

• Interpolated(DensityFunction argument): Wraps a function and performs linear interpolation (lerp) between 4x4x4 block corners to smooth the output.
• Cache2D(DensityFunction argument): Computes the input density only once per horizontal (X/Z) position, caching the result in a DoubleStorage.
• CacheOnce(DensityFunction argument): Caches the last computed value, only re-computing if the block coordinates change.
• FlatCache(DensityFunction argument): Caches the value for the current 4x4x4 'quart' area.