Repository navigation
Fix Forge configurable type actions not always being set - #253
Merged
Merged
Conversation
ConfigurableTypesForge.load() was only called from CyclopsCoreForge's config registration. Since Forge constructs mods in parallel, dependent mods could register their configs before this ran, causing them to use the default actions. For GUIs, this meant menu types were not wrapped in an IContainerFactory, so the client received a null buffer when opening a menu with extra data. Closes CyclopsMC/EverlastingAbilities#329 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YMNuC5qun9MuBrCbBBhDBh
|
|
coverage: 31.409%. remained the same — fix-forge-configurable-types-race into master-26-lts |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes CyclopsMC/EverlastingAbilities#329
Problem
On Forge,
ConfigurableTypesForge.load()was only called fromCyclopsCoreForge.onConfigsRegister. Forge constructs mods in parallel, and dependents such as EverlastingAbilities declareordering="NONE"on cyclopscore. So a dependent mod could runloadModInit()before CyclopsCore had swapped in the Forge actions. Its configs then used the default actions instead ofGuiActionForge,ItemActionForge,BlockActionForgeandParticleActionForge.For GUIs this means the menu type is never wrapped in
ContainerFactoryWrapperForge. Forge'sOpenContainerthen falls back toMenuType.create(id, inv), which passes anullbuffer toIContainerFactoryCommon. The result is the NPE inItemLocation.readFromPacketBufferand a client disconnect (see the linked issue).This is a regression from the 1.21.6 update. That update moved the call out of
ModBaseForge's static initializer becauseload()needed the mod instance at the time. The 26.1 update dropped that parameter again but left the call where it was.Fix
Restore the
static { ConfigurableTypesForge.load(); }block inModBaseForge, matching 1.21-lts and the current NeoForge and Fabric loaders. The Forge action classes have no constructor arguments or static state, so creating them at class-load time is safe.Testing
./gradlew :loader-forge:buildpasses../gradlew :loader-forge:runGameTestServerpasses (4/4).🤖 Generated with Claude Code
https://claude.ai/code/session_01YMNuC5qun9MuBrCbBBhDBh
Generated by Claude Code