Radium Re Reforged

Radium Re-Reforged

Minecraft 1.20.1 / Forge: this page documents that build and its measurements. For the separate 205-control Minecraft 1.21.1 port, see Minecraft 1.21.1 NeoForge.

Eight controls for Radium Re-Reforged 0.14.3 (mod id radium). Radium disables some of its options when C2ME is installed, even where the C2ME module that overlaps is off. Two controls give such an option back while respecting explicit user settings, and one switches two of Radium's experimental options on (a deliberate change since 1.0.36: Lithium documents both as not exactly vanilla). One memo speeds up start-up. Four are fixes: chunks leaving a player's view are dropped through vanilla's updateChunkTracking so other mods' hooks see them, solid body parts of multipart mobs can be bumped into again, block entities keep following world border changes, and copied chunk sections take new blocks correctly. C2ME itself is inspected, not patched. Every switch checks the code it would change against the tested build; another build is left untouched with one WARN line (see How the patches are applied).

Key	Target	Side	Since	Kind
radium_c2me_chunk_access	Radium Re-Reforged 0.14.3 with C2ME 0.2.0+alpha.12	BOTH	1.0.22	opt
radium_c2me_player_chunk_tick	Radium Re-Reforged 0.14.3 with C2ME 0.2.0+alpha.12	BOTH	1.0.22	opt
radium_entity_touchable_memo	Radium Re-Reforged 0.14.3	BOTH	1.0.29	opt
radium_experimental_tickets_spawning	Radium Re-Reforged 0.14.3	BOTH	1.0.25	change
radium_hash_palette_copy	Radium Re-Reforged 0.14.3	BOTH	1.0.30	fix
radium_part_entity_collisions	Radium Re-Reforged 0.14.3	BOTH	1.0.30	fix
radium_untrack_chunk_hooks	Radium Re-Reforged 0.14.3	BOTH	1.0.22	fix
radium_world_border_keep_listeners	Radium Re-Reforged 0.14.3	BOTH	1.0.30	fix

How an option is given back

Radium and ModernFix decide their mixins from live option objects while Mixin prepares their configs. Our config bons_and_furious.c2me_compat.mixins.json has priority 900, so Mixin prepares it after every config plugin has loaded (that is when Radium and ModernFix build their options) and before theirs (default 1000). Its plugin, C2meCompatPlugin, flips an option back on only when all of these hold: C2ME was the only reason it was off, your own Radium or ModernFix config file does not set it, the C2ME module that replaces it really is off (read from C2ME's own module entry point), and every guarded method matches the tested builds. Each restore logs one INFO line (<key> switched Radium's <option> back on …); every other outcome logs why it left the option alone. With another C2ME version, or without C2ME, nothing changes.

---

radium_c2me_chunk_access

Since: 1.0.22 · Side: BOTH · Mixins: ChunkAccessOptionTrigger, RadiumChunkSchedulingMixin Patched: Radium's mixin.world.chunk_access option; Radium's ServerChunkManagerMixin.getChunkBlocking (three redirects to vanilla's ChunkHolder.getOrScheduleFuture)

What upstream did. Radium switches off its fast ServerChunkCache.getChunk / Level.getChunk path whenever C2ME's opts.chunk_access sub-mod is installed, because that C2ME module rewrites the same methods. The all-in-one C2ME jar always installs the sub-mod, also when c2me.toml sets generalOptimizations.optimizeAsyncChunkRequest = false, and then neither version runs.

What the patch does. While that C2ME module is off and C2ME was the only reason, Radium's option is switched back on. A chunk status that still has to be scheduled then goes through ChunkHolder.getOrScheduleFuture, as in vanilla, so C2ME's per-holder lock and parent-status ordering still apply. Nothing changes when C2ME's module is on, when C2ME is not installed or when Radium's own config sets the option.

What stays the same. The chunks returned: in every rig run 507 lookups returned the same chunk objects as the chunk holders, and far chunks still generated to FULL through the scheduling path. Radium's own methods merged with C2ME's beforeAwaitChunk redirect and our three redirects, with C2ME's return hooks at all three returns.

Measured. In game with C2ME installed (best of 5 × 1,000,000 calls, 3 runs per arm): getChunk(create=true) on loaded chunks 46 vs 81 ns, getBlockState 73 vs 133 ns. The replaced vanilla path was 1.2-1.7 % of the integrated server thread in a client profile.

---

radium_c2me_player_chunk_tick

Since: 1.0.22 · Side: BOTH · Mixin: PlayerChunkTickOptionTrigger Patched: Radium's mixin.world.player_chunk_tick option (no method of Radium's is changed)

What upstream did. Radium switches off its player chunk tracking whenever C2ME's notickvd sub-mod is installed, also when c2me.toml sets noTickViewDistance.enabled = false.

What the patch does. While that module is off, Radium's option is switched back on: a player who crosses into another chunk only visits the chunks that enter or leave their view, instead of calling updateChunkTracking (with a new ChunkPos and packet holder) for every chunk of both view squares.

What stays the same. Which chunks the client holds: no chunk the server tracks was missing on the client in the rig runs. (After a move the client keeps 74-78 chunks the server no longer tracks in both arms; that is vanilla 1.20.1's chunk-ring behaviour, not this switch.)

Measured. A 26-step move test called updateChunkTracking 75,394-85,946 times with vanilla code and 1,458 times with the option on (only the real changes); time in ChunkMap.move about 10-20 % lower, the rest is packet work. move was 0.8 % of the server thread and 1.4 % of its allocations during flight in the JFR.

---

radium_untrack_chunk_hooks

Since: 1.0.22 · Side: BOTH · Mixin: RadiumUntrackHookMixin Patched: Radium's ThreadedAnvilChunkStorageMixin.stopWatchingChunk (one redirect to vanilla's ChunkMap.updateChunkTracking)

What upstream did. Radium's player chunk tracking drops a chunk that leaves a player's view with ServerPlayer.untrackChunk directly and skips ChunkMap.updateChunkTracking, which other mods hook: SecurityCraft 1.10.1 keeps a chunk tracked while a camera shown on a frame still needs it, so that hook never saw Radium's drops.

What the patch does. The drop goes through updateChunkTracking(player, pos, packet cache, wasLoaded = true, load = false), which calls untrackChunk exactly as before when no mod cancels it. Applies whenever Radium's mixin.world.player_chunk_tick applies, with or without C2ME. This is a [FIX]: it changes which hook sees a drop, not what is dropped.

What stays the same. Every drop that no mod cancels: in game all 1,458 chunk drops of the move test went through updateChunkTracking and reached untrackChunk.

Measured. No timing claim; the extra call is one method hop per dropped chunk.

---

radium_experimental_tickets_spawning

Since: 1.0.25 · Target: Radium Re-Reforged 0.14.3 · Side: BOTH · Kind: change

Mixins: RadiumExperimentalOptionTrigger, RadiumExpiringTicketNullGuardMixin

Radium's mixin.experimental.chunk_tickets (ticket expiry looks only at chunks with expiring tickets) and mixin.experimental.spawning (the mob cap count walks the entity sections in chunk order) are both on by default in later Lithium versions. lithium.properties cannot switch on just these two: Radium copies a user-set parent's value onto every child option, so mixin.experimental=true also switches on the experimental entity block caching, whatever the child lines say, and its block_touching part skips Valkyrien Skies', Bumblezone's and Dimensional Doors' block-contact hooks. This switch sets Radium's live options after that copy: the experimental group on, its entity part off. Nothing changes when lithium.properties or another mod sets any of these options. No mod in this pack removes the timed tickets that make chunk_tickets throw (Lithium #535/#571). Deliberate change (described as one since 1.0.36): Lithium's documentation lists both options under minimal_nonvanilla, not as exact: expiring chunk tickets "Can cause reordering of chunks unloading", and spawning "Might differ slightly from vanilla due to floating point associativity differences when summing the spawning potential of density controlled spawns". With this key false both options stay off, as Radium ships them.

Measured: in the client and server rigs Radium applied its chunk_tickets and spawning mixins and none of its entity block caching. The code they replace was 0.9-1.7% (ticket expiry) and 0.4-0.8% (mob cap count) of the integrated server thread in the 2026-10-01 client recordings, 0.24% and 0.35% of busy time in a dedicated-server profile.

Since 1.0.34. Radium's experimental chunk ticket code is protected against the missing ticket set that makes it crash in some packs (a known Radium issue). The protection applies only while Radium's experimental option is on.

---

radium_entity_touchable_memo

Since: 1.0.29 · Target: Radium Re-Reforged 0.14.3 · Side: BOTH · Kind: opt

Mixin: EntityTouchableMemoMixin

Radium: the entity-touchable block flag is worked out once per block class instead of once per block state. Radium marks every block state whose block reacts to entities walking into it. For each STATE it searched the block's class and its parents by reflection for that method, and on a dedicated server, for blocks whose methods mention client-only classes, wrote a "Radium Class Analysis Error" warning each time (about 38,800 per boot in this pack, hidden by the log filter but still produced). The answer depends only on the block's class, so the first state of each class asks Radium and every other state of that class gets the same answer. The warning now appears once per class.

Measured: offline on Radium's own class, all 24,135 vanilla block states (234 block classes) plus synthetic hierarchies and the missing-class fallback gave identical answers; 3.3 us -> 65 ns per state. In this pack's server boot the flag took about half of the server thread's time (some 6-7 s) while Valkyrien Skies built every block state's cache.

---

radium_world_border_keep_listeners

Since: 1.0.30 · Target: Radium Re-Reforged 0.14.3 · Side: BOTH · Kind: fix

Mixin: WorldBorderKeepListenersMixin

Radium: block entities keep following world border changes after /worldborder damage or warning. Radium remembers for every ticking block entity whether it is inside the world border and updates that when the border moves. A border change that does not move it (/worldborder damage amount or buffer, warning distance or time) made Radium drop every block entity's subscription while keeping the remembered answer, so after the next real border change, block entities now outside kept ticking and ones the border grew over never ticked again. Those four changes now keep the subscriptions, so the remembered answer always equals vanilla's border test. Our worlds use the default border, so this matters only once the border is made smaller.

Idea: Lithium 0.14.5 release notes, idea text only

Measured: offline on Radium's own classes (real block-entity tickers, real border): 40 random sequences of 60 border changes with 441 block entities: without the fix 158,315 of 546,763 answers differed from vanilla, with it 0; sequences without those four changes behave identically with the switch on and off.

---

radium_part_entity_collisions

Since: 1.0.30 · Target: Radium Re-Reforged 0.14.3 · Side: BOTH · Kind: fix

Mixin: PartEntityCollisionsMixin

Radium: solid body parts of multipart mobs can be bumped into again. some mobs are built from several part entities. When a player or mob moves, Forge also checks the level's part entities for solid boxes; Radium's faster lookup reads only the normal entity lists, so solid parts could be walked through: Untamed Wilds' whale shark, baleen whale and anaconda bodies, Cataclysm's old Netherite Monstrosity, Alex's Mobs' giant squid and Unusual Prehistory's Brachiosaurus. The switch adds the solid part entities in reach to Radium's result with the same tests and in the same order as Forge's lookup, so moving and "is there room" checks see them as in vanilla Forge. Turn it off to keep Radium's walk-through bodies.

Idea: Lithium 0.25.2 release notes, idea text only

Measured: offline on Radium's own classes with a real entity store and Forge's part-entity list, 300 random scenes x 40 lookups: without the fix 522 of 12,000 collision lists and 463 of 12,000 "is there room" answers differed from Forge, with it 0 and 0; scenes without part entities identical. Cost like Forge's own loop: one box test per part entity of the level per lookup (about 5-8 ns each), nothing measurable with no part entities, no extra allocation.

---

radium_hash_palette_copy

Since: 1.0.30 · Target: Radium Re-Reforged 0.14.3 · Side: BOTH · Kind: fix

Mixins: HashPaletteCopyMixin, HashPaletteTableAccessor

Radium: copied chunk sections take new blocks correctly. Radium keeps the block and biome lists of chunk sections in its own palette. A COPY of that palette lost the marker for "not in the list yet", so writing a new block into a copied section silently stored the list's first entry (usually air) instead. The copy now keeps the marker and works exactly like the original and like vanilla. In this pack only render snapshots copy sections and they never write into the copy, so nothing visible changes here; it protects mods that edit copied sections.

Idea: Lithium 0.14.8 release notes, idea text only

Measured: 4,000 random palettes of 3-8 bits: index sequences on copies differed from vanilla's palette in 2,953 cases without the fix and in 0 with it; a copied section given an oak sign read back air without the fix and the oak sign with it. copy() costs the same within noise (about 0.8-0.9 us and 880 bytes either way).