[Bug] Remap targeting mod registry entries are silently discarded at load time #1
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
TysonTheEmber/RemapIDs#1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When configuring a remap from a vanilla id to a mod id (e.g. minecraft:iron_ingot -> create:andesite_alloy), the remap is silently discarded during initialization and never applied.
However, remaps between two vanilla ids work correctly.
I checked latest.log and found the snippet where the problem occurred:
Taking forge-1.20.1 for example, the mod initializes during the mod construction phase, before any mod registries have been populated.
At this point, ForgePlatformHelper.getAllRegistryIds() queries the game registries, which only contain vanilla entries:
This map is then passed to RemapLoader.load() , which calls RemapValidator.validateAndFilter() to remove any remap whose target id does not exist in the registry at that moment:
Since mod entries have not been registered yet, they are filtered out before being stored.
At last, by the time MappedRegistryMixin.freeze() runs, the remap rules have already been discarded, so nothing is injected.
I should open a tested pull request with minimal changes to the fixes later for this issue.
Hi, I tried the latest version (1.2.0) and this issue seems to be not fixed. This is the json file:
And this is the latest.log:
Since I have to go to work tomorrow, right now I don't have time to check the changes of the code so I can only provide a quick report. Could you try to review this issue again? Thank you!
I also noticed something is moved to render thread, just a quick reminder it may be influence the server (I don't know, need to check the source code)
Hi, it seems that for 1.2.1 this issue remains, and the latest.log is the same as above.
Seems to be fixed in 1.3.0. Thanks!