docs: update docs to new codec based data loading api

Author: klikli-dev

versioned_docs/version-26.1.2/advanced/custom-conditions.md

@@ -6,48 +6,86 @@ sidebar_position: 40
 
 Mods can add custom conditions that can be used to lock entries or categories. To this end you need to:
 
-1. Create ResourceLocation for the new condition (e.g. "mymod:my_condition")
-2. Create a custom condition class
-3. Register the custom condition 
+1. Create a `ResourceLocation` ID for the new condition (e.g. `mymod:my_condition`)
+2. Create a custom condition class with `ID`, `CODEC`, and `STREAM_CODEC`
+3. Register the condition via a dedicated registry class
 4. For datagen: create a condition model class
 5. Finally use the condition in your book
 
 :::tip
 
-The ResourceLocation is what you will use in your entries and categories to gate them behind your custom condition. 
+The `ResourceLocation` is what you will use in your entries and categories to gate them behind your custom condition.
 
 :::
 
 ## Condition Class
 
-Conditions need to extend `BookCondition` in the package `com.klikli_dev.modonomicon.book.conditions`.   
-In addition to implementing the interface methods that your IDE will suggest you need two static methods `fromJson` and `fromNetwork` which you will need when registering the condition.
+Conditions need to extend `BookCondition` in the package `com.klikli_dev.modonomicon.book.conditions`.
 
-in `getType()` return your ResourceLocation.
+Each condition class must declare three static fields:
 
-See https://github.com/klikli-dev/modonomicon/blob/-/common/src/main/java/com/klikli_dev/modonomicon/book/conditions/BookAdvancementCondition.java for an example condition.
+- `ID` — a `ResourceLocation` (use `Modonomicon.loc(...)` or `new ResourceLocation("mymod", "my_condition")`)
+- `CODEC` — a `MapCodec<T>` for JSON deserialization, typically built with `RecordCodecBuilder.mapCodec(...)`
+- `STREAM_CODEC` — a `StreamCodec<RegistryFriendlyByteBuf, T>` for network serialization, typically built with `StreamCodec.composite(...)`
+
+You must also override `type()` to return the corresponding `BookConditionType<T>` from your registry class.
+
+See these example conditions for reference:
+- [`BookModLoadedCondition`](https://github.com/klikli-dev/modonomicon/blob/-/common/src/main/java/com/klikli_dev/modonomicon/book/conditions/BookModLoadedCondition.java)
+- [`BookFalseCondition`](https://github.com/klikli-dev/modonomicon/blob/-/common/src/main/java/com/klikli_dev/modonomicon/book/conditions/BookFalseCondition.java)
+- [`BookResearchNodeUnlockedCondition`](https://github.com/klikli-dev/modonomicon/blob/-/common/src/main/java/com/klikli_dev/modonomicon/book/conditions/BookResearchNodeUnlockedCondition.java)
 
 ## Condition Registration
 
-To register the condition call LoaderRegistry.registerConditionLoader(...).   
-For the BookAdvancementCondition this call looks as follows: `registerConditionLoader(Condition.ADVANCEMENT, BookAdvancementCondition::fromJson, BookAdvancementCondition::fromNetwork);`
+Create a dedicated registry class to hold your condition registrations. Use `public static final` fields initialized via `BookConditionTypeRegistry.register(...)`, and provide an empty `bootstrap()` method to trigger class loading:
+
+```java
+public final class MyModModonomiconConditionRegistry {
+
+    public static final BookConditionType<BookMyCustomCondition> MY_CUSTOM =
+        BookConditionTypeRegistry.register(
+            BookMyCustomCondition.ID,
+            BookMyCustomCondition.CODEC,
+            BookMyCustomCondition.STREAM_CODEC
+        );
+
+    private MyModModonomiconConditionRegistry() {
+    }
+
+    public static void bootstrap() {
+    }
+}
+```
 
-This needs to be called from both the client and server side mod initialization.   
-In Fabric: Call in `onInitialize` in your `ModInitializer`.   
-In (Neo)Forge: Call in `onCommonSetup` (your `FMLCommonSetupEvent` handler).	
+Then call `bootstrap()` during `FMLCommonSetupEvent` (NeoForge) or your `ModInitializer.onInitialize` (Fabric):
+
+```java
+// NeoForge
+public void onCommonSetup(FMLCommonSetupEvent event) {
+    MyModModonomiconConditionRegistry.bootstrap();
+}
+
+// Fabric
+@Override
+public void onInitialize() {
+    MyModModonomiconConditionRegistry.bootstrap();
+}
+```
 
 ## Condition Datagen Model
 
-The model class helps you to generate the condition json files via DataGen. 
+The model class helps you to generate the condition JSON files via DataGen.
 
-See https://github.com/klikli-dev/modonomicon/blob/2a067357bacaf3e15a5f490520a4headaf64807fe83e/common/src/main/java/com/klikli_dev/modonomicon/api/datagen/book/condition/BookAdvancementConditionModel.java for a reference model class.
+Extend `BookConditionModel<T>` and override `toBookCondition(HolderLookup.Provider)` to return the runtime condition instance. Pass the condition's `ID` to the `super(...)` constructor.
 
-(On 1.20.1 it looks a bit more complicated: 
-https://github.com/klikli-dev/modonomicon/blob/bdf639c835908393198f695999c70f2ac53e154c/common/src/main/java/com/klikli_dev/modonomicon/api/datagen/book/condition/BookAdvancementConditionModel.java )
+See these example models for reference:
+- [`BookModLoadedConditionModel`](https://github.com/klikli-dev/modonomicon/blob/-/common/src/main/java/com/klikli_dev/modonomicon/api/datagen/book/condition/BookModLoadedConditionModel.java)
+- [`BookFalseConditionModel`](https://github.com/klikli-dev/modonomicon/blob/-/common/src/main/java/com/klikli_dev/modonomicon/api/datagen/book/condition/BookFalseConditionModel.java)
+- [`BookResearchNodeUnlockedConditionModel`](https://github.com/klikli-dev/modonomicon/blob/-/common/src/main/java/com/klikli_dev/modonomicon/api/datagen/book/condition/BookResearchNodeUnlockedConditionModel.java)
 
-:::tip 
+:::tip
 You need not register the model.
-::: 
+:::
 
 ## Usage
 
@@ -61,6 +99,6 @@ On your entry or category, add:
   },
   ...
 }
-```	
+```
 
 See also [Unlock Conditions](../basics/unlock-conditions) for more information on how to use conditions.

versioned_docs/version-26.1.2/basics/formatting.md

@@ -260,14 +260,12 @@ Macro instructions (ab)use the link syntax as follows: to start a macro use `[{}
 [{}](my.dynamic.key) could be replaced to show a config value!
 ```
 
-To register that macro call the following code during server setup:
+To register that macro call the following code during `FMLCommonSetupEvent` (NeoForge) or your `ModInitializer.onInitialize` (Fabric):
 
 ```java
-LoaderRegistry.registerDynamicTextMacroLoader(<my-book-id>, () -> {
-    return Map.of(
-            "my.dynamic.key", MyConfig.SOME_VALUE.get()
-    );
-});
+DynamicTextMacroRegistry.register(myBookId, () -> Map.of(
+        "my.dynamic.key", MyConfig.SOME_VALUE.get()
+));
 ```
 
 :::info 

versioned_docs/version-26.1.2/multiblocks/state-matchers/predicate-matcher.md

@@ -4,22 +4,19 @@ sidebar_position: 50
 
 # Predicate Matchers
 
-# Tag Matcher
-
 **Type:** `modonomicon:predicate`
 
-Predicate matchers can use advanced logic to match blocks. The matching logic must be provided as Java Code and registerd with a Resource Location ID.
-Tag matchers will check if the placed block is part of the provided tag. Additionally BlockState properties can be provided to match against, in that case the matcher will only match if the block is in the tag, and has the provided properties.
+Predicate matchers can use advanced logic to match blocks. The matching logic must be provided as Java code and registered with a `ResourceLocation` ID.
 
 ## Attributes
 
 ### **predicate** (ResourceLocation, _mandatory_)
-  
+
   The ID of the predicate to use for the matcher.
 
-### **display** (BlockState, _mandatory_)
-  
-  The block to display in the multiblock preview. 
+### **display** (BlockState, _optional_)
+
+  The block to display in the multiblock preview.
 
   :::info
 
@@ -29,33 +26,54 @@ Tag matchers will check if the placed block is part of the provided tag. Additio
 
 ### **counts_towards_total_blocks** (boolean, _optional_, default: `true`)
 
-  If set to `false` the block will not count towards the total number of blocks required to complete the multiblock.   
+  If set to `false` the block will not count towards the total number of blocks required to complete the multiblock.
   E.g. for the `modonomicon:air` predicate you would set this to `false`.
   If set to `true` the block will count towards the total number of blocks required to complete the multiblock, which in the case of air and air-like blocks would lead to an insane number of blocks shown as still required to complete.
 
 ## Registering Predicates
 
-Predicates are registered in the `FMLCommonSetupEvent`: 
+Create a dedicated registry class and register your predicates via `PredicateRegistry.register(...)`:
 
-```java 
-public void onCommonSetup(FMLCommonSetupEvent event) {
-    LoaderRegistry.registerPredicate(new ResourceLocation("modonomicon:air"), (getter, pos, state) -> state.isAir());
+```java
+public final class MyModModonomiconPredicateRegistry {
+
+    public static final PredicateType MY_PREDICATE = PredicateRegistry.register(
+        new ResourceLocation("mymod", "my_predicate"),
+        (getter, pos, state) -> state.isSolid() && pos.getY() > 64
+    );
+
+    private MyModModonomiconPredicateRegistry() {
+    }
+
+    public static void bootstrap() {
+    }
 }
 ```
 
-You can of course define any predicate you like that fits a 
-```java 
-TriPredicate<BlockGetter, BlockPos, BlockState>
+The predicate lambda must match the `TriPredicate<BlockGetter, BlockPos, BlockState>` signature.
+
+Then call `bootstrap()` during `FMLCommonSetupEvent` (NeoForge) or your `ModInitializer.onInitialize` (Fabric):
+
+```java
+// NeoForge
+public void onCommonSetup(FMLCommonSetupEvent event) {
+    MyModModonomiconPredicateRegistry.bootstrap();
+}
+
+// Fabric
+@Override
+public void onInitialize() {
+    MyModModonomiconPredicateRegistry.bootstrap();
+}
 ```
-:::caution 
 
-To access the `LoaderRegistry` you need to define a dependency on the full modonomicon jar in your `build.gralde` (See **[Maven Dependencies](../../getting-started/maven-dependencies)**)
-If you then call `LoaderRegistry.registerPredicate` in your `FMLCommonSetupEvent` like above you effectively create a hard dependency on Modonomicon. 
-You can avoid this by calling `LoaderRegistry.registerPredicate` in a separate class, and only call that classes Methods if Modonomicon is loaded.
+:::caution
+
+To access `PredicateRegistry` you need to define a dependency on the full modonomicon jar in your `build.gradle` (See **[Maven Dependencies](../../getting-started/maven-dependencies)**).
 
-::: 
+If you then call `PredicateRegistry.register(...)` directly you effectively create a hard dependency on Modonomicon. You can avoid this by calling `PredicateRegistry.register(...)` in a separate class, and only calling that class's methods if Modonomicon is loaded.
 
-<!-- TODO: Link to an article that explains in detail how to guard against no class def -->
+:::
 
 ## Builtin Predicates
 
@@ -65,14 +83,20 @@ You can avoid this by calling `LoaderRegistry.registerPredicate` in a separate c
 
 Matches air blocks. Requires players to remove any blocks in the location of this matcher.
 
+### Non-Solid Predicate
+
+**Predicate ID:** `modonomicon:non_solid`
+
+Matches blocks that are not solid.
+
 ## Usage Examples
 
-Match air predicate and display .. nothing
+Match air predicate and display nothing:
 
 ```json
 {
   "type": "modonomicon:predicate",
   "predicate": "modonomicon:air",
   "display": "minecraft:air"
 }
-```
+```