Guidefor players4 min read
FerriteCore crashes with Radium or Canary: the one config line that fixes it
FerriteCore and Radium both optimise blockstate allocation, and only one of them can. Set mixin.alloc.blockstate=false in radium.properties or canary.properties. Why the collision exists, and why Radium never shipped the fix.
The fix first
If FerriteCore is installed alongside Radium, Rubidium's optimisation addons, Radon or Canary, and the game either crashes on startup or throws a neighbor table exception, add one line to the other mod's config.
For Radium, in config/radium.properties:
mixin.alloc.blockstate=false
For Canary, the same line in config/canary.properties.
That is it. Create the file if your instance does not have one yet, restart, and the conflict is gone. FerriteCore keeps doing the optimisation, Radium stops trying to do it as well.
What the crash looks like
There are two faces to this. The first is the ugly one. The original report, from October 2022 on Minecraft 1.19.2, describes a client that "will not even launch after the Minecraft client menu that you press Play," with logs that "do not really indicate anything." No crash screen, no useful stack trace, just a launcher returning to itself. That happens because the collision occurs during mod construction, while the game is still assembling blockstates, before the crash reporter is in a position to write anything readable.
The second face is friendlier, because FerriteCore learned to detect it:
Caused by: java.lang.UnsupportedOperationException: A mod tried to access the state neighbor
table directly. Please report this at https://github.com/malte0811/FerriteCore/issues. As a
temporary workaround you can enable "populateNeighborTable" in the FerriteCore config
at [email protected]/malte0811.ferritecore.fastmap.table.CrashNeighborTable.crashOnAccess
at [email protected]/malte0811.ferritecore.fastmap.table.CrashNeighborTable.rowKeySet
at [email protected]/me.jellysquid.mods.lithium.common.state.FastImmutableTable.<init>
Read the third frame. Radium's FastImmutableTable is constructing itself and asking FerriteCore's replacement table for data that no longer exists in that form. Both mods are trying to own the same structure. Enabling populateNeighborTable does stop the crash, but it does so by making FerriteCore keep the table it was built to eliminate, which gives back the memory saving you installed it for. Turning Radium's copy off is the better trade.
Why they collide instead of combining
The interesting part is that this is not an accident. FerriteCore and Lithium both optimise blockstate allocation, and they know it. On Fabric, FerriteCore uses Lithium's own mod override mechanism to ask Lithium not to apply that particular change, on the grounds that FerriteCore's version saves more. Two mods, one negotiated handoff, no crash.
Radium is a Forge port of Lithium, and it deliberately deleted that mechanism. The relevant method in Radium's config class is commented out under the line // Overriding Mods on Forge? No. FerriteCore's author, malte0811, described the consequence in October 2022:
The problem here is Radium, one of their changes is incompatible with one of FCs. On Fabric (with Lithium) I solve this by specifying that Lithium should not apply that change (since my version is more effective). Radium intentionally removed that possibility. Instead they disable the feature when they detect that FC is installed, but that change was made a few days after the latest build on CurseForge was released. So it won't work "out of the box" until Asek3 publishes a new release of Radium. For now you can add
mixin.alloc.blockstate=falsetoconfig/radium.properties.
Radium's author did write a fix, in the form of detecting FerriteCore and switching the feature off. It landed in the repository after the last public build. That build, Radium 0.8.2, is still the one appearing in crash reports two years later. The repository was archived on 8 September 2023. When someone asked in August 2024 whether Radium should have released a new version by now, nobody answered, and by then nobody could. The config line is not a workaround waiting for a proper fix. It is the fix.
The Lithium side, for contrast
The same handshake did break on Fabric's side once, and the difference in outcome is the point. In October 2024, Lithium's NeoForge port renamed its packages, FerriteCore's override stopped matching, and the crash came back. malte0811 added the equivalent code for NeoForge within days and shipped a fixed 1.21.1 build. In 2025 the option disappeared from Lithium entirely, leaving only a harmless log line saying ferritecore tried to override an option that does not exist.
Two live projects, one broken handshake, fixed in a week. One archived project, same broken handshake, permanent.
This is not the generic optimiser-stacking problem
The site's guide on why performance mods crash when you stack too many of them covers the usual case: two mods rewrite the same method without knowing about each other, and the collision is emergent. This one is not that. FerriteCore and Lithium know about each other, and there is a documented protocol between them. What broke is that a fork removed the protocol and then went dormant before publishing its replacement.
Practically, that means the ordinary advice does not apply here. You do not need to binary search your mod list or pick one mod over the other. You need one line in one file, and the name of the file depends on which Lithium fork you happen to be running.
