Create: Beyond the Skies Fixes

Create: Beyond the Skies Fixes is a lightweight Forge mod for Minecraft 1.20.1 that patches several crashes, mixin incompatibilities, and performance issues present in the Create: Beyond the Skies modpack.

Fixes 1–3 are client-side only. Fix 4 must be installed on the server (and optionally the client) to be effective. Fixes 5, 7, and Feature 6 benefit from installation on both sides.

Fixes Included

1 — Flywheel null model NPE (Create Frogport / Chain Conveyor)

Symptom: Game crashes with a NullPointerException inside Flywheel's rendering engine whenever a Frogport or Chain Conveyor handles an item with no registered visual model (occurs when Create Mobile Packages fails to register its package-item models).

Fix: Three Mixins guard the item-rendering loops in FrogportVisual and ChainConveyorVisual. Any item whose model lookup returns null is silently skipped instead of crashing.

2 — Valkyrien Skies / create_hypertube mixin conflict

Symptom: On startup, Valkyrien Skies 2.4.10's MixinBezierTextureRenderer injects into BezierTextureRenderer.renderBezierConnection() from create_hypertube 0.4.0 using MixinExtras @Local to capture Vec3 and Level locals. The method does not expose these locals at the expected injection point, so VS's mixin fails with:

InvalidImplicitDiscriminatorException: Found 0 candidate variables
→ SugarApplicationException → InjectionError → MixinTransformerError

This propagates through the resource-reload pipeline and prevents the game from loading.

Fix: BezierTextureRendererMixin (priority 500, applied before VS's default priority 1000) rewrites renderBezierConnection to add a Vec3 renderOrigin local and to declare level as Level (supertype) — exactly matching what VS's injection expects. VS's mixin then finds both locals and injects cleanly, so BezierTextureRenderer loads without error and hypertube rendering works normally.

3 — EntityRenderDispatcher null renderer NPE (VS world-exit race condition)

Symptom: On world exit, Valkyrien Skies tears down its physics pipeline before the render thread finishes its current frame. VS's modified renderer-lookup returns null for entities whose VS context has already been destroyed. Vanilla code then calls shouldRender() on the null renderer, crashing:

NullPointerException: Cannot invoke "EntityRenderer.shouldRender(...)"
  at EntityRenderDispatcher.shouldRender(...)

Fix: EntityRenderDispatcherMixin wraps the shouldRender() call with a null check. A null renderer causes the entity to be silently skipped (returns false) instead of crashing.

4 — RecipeEssentials integer overflow → permanent blaze burner failure

Symptom: RecipeEssentials 1.20.1-4.0 subclasses RecipeManager and overrides getRecipeFor() with a probabilistic stale-cache check:

rand.nextInt(cachedList.useCount * 30)  // throws when useCount * 30 overflows

useCount is a plain int that is incremented on every cache hit and never reset. All LiquidBlazeBurnerBlockEntity instances share the same cache entry — their hash collapses to RecipeType.hashCode() because the block entity has no item slots and no hashCode() override. With a typical server running 70–80 blaze burners at 20 ticks/second, useCount reaches Integer.MAX_VALUE / 30 in 12–14 hours. At that point useCount * 30 overflows to a negative number and every call throws:

IllegalArgumentException: bound must be positive
  at Random.nextInt(Random.java:388)
  at RecipeManager.getRecipeFor(...)  ← RecipeEssentials override
  at LiquidBlazeBurnerBlockEntity.find(...)

Because all burners share one cache entry, the overflow affects all of them simultaneously — including any newly placed after the failure onset. Spark profiler analysis confirmed this overhead consumes 47–58% of server CPU during the failure window.

Fix (1.4.0): RecipeEssentialsOverflowMixin redirects the GETFIELD CachedRecipeList.useCount read at bytecode ordinal 1 — the operand of the useCount * 30 multiplication — in each of the three overridden methods (m_44015_, m_220248_, m_44056_). The redirect receives the live CachedRecipeList object. When useCount > Integer.MAX_VALUE / 30 (71,582,788), the field is immediately reset to 1 and 1 is returned, making the multiplication 1 * 30 = 30 and nextInt(30) safe. The reset happens on the same call in which the overflow would have occurred — no additional ticks, no waiting. An INFO log entry is written when the fix triggers (once per ~13-hour cycle). The overflow will be caught again ~13 hours later if the server runs continuously without restart.

LiquidBlazeBurnerMixin remains as secondary defence; with the root-cause fix active it should never fire.

Installation note: Must be installed on the dedicated server. Client installation is harmless.

5 — Periodic GC to mitigate Valkyrien Skies chunk heap accumulation

Symptom: Over a play session, the JVM heap gradually bloats with leaked LevelChunk and PalettedContainer objects retained by Valkyrien Skies' physics engine (ChunkAllocatorProvider). VS tracks nearby terrain chunks for ship collision geometry; when Minecraft unloads those chunks, VS does not immediately release its references. Over time this fills the heap and eventually triggers a stop-the-world garbage collection, causing the game to freeze for tens of seconds or longer.

Fix: Both the client tick handler (Dist.CLIENT) and the server tick handler (Dist.DEDICATED_SERVER) spawn a daemon background thread every 5 minutes that calls System.gc(). This requests a JVM garbage collection pass before the heap has time to bloat to stop-the-world proportions. Running on a background thread ensures the tick thread is never blocked by the collection.

This fix mitigates the symptom (GC pause) rather than the root cause (VS chunk retention). It is most effective when combined with a low-pause GC such as ZGC (-XX:+UseZGC), but provides meaningful improvement on the default G1GC as well. The GC call is a no-op if the JVM has been started with -XX:+DisableExplicitGC.

Installation note: Install on both client and server. On the dedicated server it protects the server tick thread. On the client it protects the integrated server (single-player) and the client render heap.

6 — Contraption fluid and item storage compat

What this does: Create 6 uses a registry system (MountedFluidStorageType / MountedItemStorageType) to declare which blocks can carry fluid or items on a contraption. Any block not in these registries cannot move fluid or items while mounted — Mechanical Pumps will ignore it, and items inside will not move with the contraption.

The following mod storage blocks are not registered by their respective mods and would silently lose their contents when mounted. This mod registers them all:

Ender Storage behaviour: Ender chests and tanks on contraptions stay connected to the shared ender frequency network. Any fluid or items inserted into them while the contraption is moving go to the correct ender frequency — the same network all other ender chests and tanks on that frequency share. The frequency is serialized with the contraption so it reconnects correctly after a world reload.

TrashCans behaviour: Trash can blocks on contraptions accept and void all fluid and items inserted into them. They behave identically to their stationary equivalents.

All compat entries are loaded conditionally — if a mod is not installed, its compat is silently skipped. Installing this mod without any of the above mods present has no effect.

Installation note: All compat registrations apply on both sides. Install on both client and server.

7 — Create: Drill Drain fluid amount tied to liquid type

Symptom: Create: Drill Drain drains different amounts of fluid depending on the type of liquid. Lava yields 3× the mB of water per block drained at the same fluidPickupModifier setting. This makes lava effectively much easier to collect than water and causes tanks to fill at unpredictable rates depending on what fluid the drill is draining.

Root cause: DrillMovementBehaviourReplacement.getFluidFromFluidBlock() scales the collected amount by FluidType.getDensity(). Forge's default density for water is 1000 and for lava is 3000, so the formula level × density × modifier produces 3× the result for lava regardless of the configured modifier value.

Fix: DrillDrainDensityMixin redirects both FluidType.getDensity() calls in getFluidFromFluidBlock to always return 1000. All fluids now yield the same mB per block at a given fluidPickupModifier, making collection rates consistent and predictable across fluid types.

Installation note: Install on both client and server. Contraption movement behaviour runs server-side; client installation is harmless.

Compatibility

Fixes 1–3 require installation on the client only. Fix 4 requires installation on the server (client installation optional but harmless). Fixes 5, 7, and Feature 6 benefit from installation on both sides.

Author

TheDarkAce — created as a targeted fix collection for the Create: Beyond the Skies modpack.