Cannot remap IDs to KubeJS created IDs #6

New issue

Open

opened 2026-04-24 11:34:50 -06:00 by ElementW · 1 comment

ElementW commented

2026-04-24 11:34:50 -06:00

(Migrated from github.com)

Mod Loader

NeoForge 1.21.1

Mod Version

1.3.0

Crash Log / Error Output

https://mclo.gs/N2vTmxF

Bug Description

Trying to remap an ID to something that's created by KubeJS fails, e.g.

[RemapIDs] Remap target 'kubejs:iron_plating' not found in item registry yet (may be a modded ID not registered at this point), remap from 'ad_astra:iron_plating' will be attempted at freeze time
...
[RemapIDs] Cannot inject alias ad_astra:iron_plating -> kubejs:iron_plating: target not found in item registry

Adding a System.out.println(key().toString()); line to remapids$beforeFreeze reveals both RemapIDs's effective startup and KubeJS Startup run on/after the ResourceKey[minecraft:root / minecraft:root] freeze but before minecraft:block & similar.

This is corroborated by NeoForge unfreezing and refreezing the registries after Minecraft started freezing some of them as part of base game init, but that does not include the root registry itself; yet the MappedRegistry::freeze() hook runs on the frozen root and expects all content to have been registered by that point, which may not have happened yet, especially if any mod is listening for RegisterEvent with @SubscribeEvent(priority = EventPriority.LOW) or EventPriority.LOWEST, like KubeJS does.

The general design of the mod seems to be based on the incorrect assumption¹ that here exists a point in time where you can obtain a fully initialized picture of all of BuiltInRegistries.BLOCK, ITEM, FLUID and ENTITY_TYPE at once whilst none of those registries are frozen yet. This is fundamentally wrong and

registration may happen at any time before a registry is frozen
- Some mods register content with mixin hooks and may not follow the expected init order
freezing happens whenever registrations are deemed to be over, and is not guaranteed to be synchronized across registries
both of those are up to the whims of the mod loader and optimization mods in use
- All hell breaks loose if someone uses DashLoader (Fabric)

Steps to Reproduce

Create anything with KubeJS

StartupEvents.registry('block', e => { e.create('abc') });

Remap anything to it

{
  "remaps": [
    {
      "source": "minecraft:oak_log",
      "target": "kubejs:abc",
      "types": ["block"]
    }
  ]
}

Observe RemapIDs be oblivious to what KubeJS made

Other Mods Installed

KubeJS 2101.7.2
its dependency Rhino 2101.2.7

As exhibited by RemapState::finalizeIfPending() and its "only the first call performs resolution" comment, and RemapConfig initialization being single-stage ↩︎

### Mod Loader NeoForge 1.21.1 ### Mod Version 1.3.0 ### Crash Log / Error Output https://mclo.gs/N2vTmxF ### Bug Description Trying to remap an ID to something that's created by KubeJS fails, e.g. ``` [RemapIDs] Remap target 'kubejs:iron_plating' not found in item registry yet (may be a modded ID not registered at this point), remap from 'ad_astra:iron_plating' will be attempted at freeze time ... [RemapIDs] Cannot inject alias ad_astra:iron_plating -> kubejs:iron_plating: target not found in item registry ``` Adding a `System.out.println(key().toString());` line to `remapids$beforeFreeze` reveals both RemapIDs's effective startup and KubeJS Startup run on/after the `ResourceKey[minecraft:root / minecraft:root]` freeze but before `minecraft:block` & similar. This [is corroborated by NeoForge unfreezing and refreezing the registries after Minecraft started freezing some of them as part of base game init](https://github.com/neoforged/NeoForge/blob/adfc138ca4290aa8d80f6e8bd865d7bd49883d09/src/main/java/net/neoforged/neoforge/internal/CommonModLoader.java#L53-L55), but that does not include the root registry itself; yet the `MappedRegistry::freeze()` hook runs on the frozen root and expects all content to have been registered by that point, which may not have happened yet, especially if any mod is listening for `RegisterEvent` with `@SubscribeEvent(priority = EventPriority.LOW)` or `EventPriority.LOWEST`, [like KubeJS does](https://github.com/KubeJS-Mods/KubeJS/blob/3dbc2589c629f61019228a3bdf2fc72dc8f5f3d2/src/main/java/dev/latvian/mods/kubejs/registry/RegistryEventHandler.java#L23). The general design of the mod seems to be based on the incorrect assumption[^1] that here exists a point in time where you can obtain a fully initialized picture of all of `BuiltInRegistries.BLOCK`, `ITEM`, `FLUID` and `ENTITY_TYPE` at once whilst none of those registries are frozen yet. This is fundamentally wrong and 1. registration may happen at *any time* before a registry is frozen * Some mods register content with mixin hooks and may not follow the expected init order 3. freezing happens whenever registrations are deemed to be over, and is not guaranteed to be synchronized across registries 4. both of those are up to the whims of the mod loader and optimization mods in use * All hell breaks loose if someone uses [DashLoader](https://modrinth.com/mod/dashloader) (Fabric) [^1]: As exhibited by `RemapState::finalizeIfPending()` and its "*only the first call performs resolution*" comment, and `RemapConfig` initialization being single-stage ### Steps to Reproduce 1. Create anything with KubeJS ```js StartupEvents.registry('block', e => { e.create('abc') }); ``` 2. Remap anything to it ```json { "remaps": [ { "source": "minecraft:oak_log", "target": "kubejs:abc", "types": ["block"] } ] } ``` 3. Observe RemapIDs be oblivious to what KubeJS made ### Other Mods Installed * KubeJS 2101.7.2 * its dependency Rhino 2101.2.7

TysonTheEmber commented

2026-04-24 16:29:33 -06:00

(Migrated from github.com)

Will look into this and prob revamp the system in the next update, looks like a similar issue to #5

👍 1