Living Engineering

Living Engineering

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.

Up to 1.0.19 this mod carried three controls for Living Engineering 3.0.1 (mod id biomancy_engineering), a Bons addon from the same author's pack. In 1.0.20 those three optimizations moved into Living Engineering itself (3.0.2), which no longer depends on Bons and Furious: the engineering_* keys are gone from config/bons_and_furious.properties (a leftover key is ignored with one warning line) and this mod no longer patches that addon. The sections below describe what the controls did, for the record; the helper classes they name left with them. Version history explains why the version number still stays below 1.1.0.

Key	Patched	Since	Result
engineering_industry_recipe_index	IndustryEntity.advance, IndustryScreen.render, BiologyProcess.list	1.0.3	−47.8 % client, −38.5 % server
engineering_culture_controls	CultureEnvironment.advance	1.0.3	−49.4 %, 96 → 0 B
engineering_vat_growth_reuse	GrowthProgram.stage, VatRenderer.render	1.0.3	32 → 0 B per stage call

---

engineering_industry_recipe_index

Scripts (1.0.19 and earlier): furious3-IndustryEntity.js, furious3-IndustryScreen.js, furious3-BiologyProcess.js · Helpers: agentcraft.pure.more.IndustryLists, agentcraft.pure.mixin.RecipeManagerAccess

What upstream did. Vats, sequencers, cryobanks, culture machines and their screen collected every recipe in the recipe manager, filtered by kind and sorted, on each update.

What the patch does. Reads the recipe manager's existing per-type index through the RecipeManagerAccess invoker. The fast path requires the native manager, final IndustryRecipe entries, consistent keys and ordinary ids; custom managers, foreign entries, textual sort ties and the four machines that accept other recipe types keep the original collect/filter/sort path. Wrappers stay fresh and no recipe result is cached.

What stays the same. Selection order, recipe identity, immutable output lists, reload behaviour and every machine's production; all eleven machine kinds equal across reloads.

Measured. Industrial recipe library: client 489,202.7 → 255,605.3 ns (−47.8 %) and 212,672 → 49,768 B; server 293,255.8 → 180,332.7 ns (−38.5 %) and 138,216 → 30,000 B.

---

engineering_culture_controls

Script (1.0.19 and earlier): furious3-CultureEnvironment.js

What upstream did. CultureEnvironment.advance rebuilt the fixed heater/aerator/buffer control tables and an internal profile object on every state advance.

What the patch does. Keeps those constants in static fields and reuses immutable internal profiles; the public profile factory still returns fresh objects.

What stays the same. Native array bounds checks, machine state-update order, saved NBT, heat values and exception classes; 240,000 paired state advances equal.

Measured. Culture controls 20.3 → 10.3 ns (−49.4 %) and 96 → 0 B; internal profile 25.1 → 21.8 ns and 40 → 0 B.

---

engineering_vat_growth_reuse

Scripts (1.0.19 and earlier): furious3-GrowthProgram.js, furious3-VatRenderer.js

What upstream did. GrowthProgram.stage rebuilt its fixed growth-threshold arrays for every internal call, and VatRenderer recomputed the specimen bounding-box centre several times per render.

What the patch does. Shares the thresholds internally (the public array-returning method still returns fresh mutable arrays) and reuses the centre within one render.

What stays the same. Geometry, stages, poses, culling and rendering detail: 1,766,976 vertices plus colours, materials and draw transforms compared equal across 576 native render cases.

Measured. Growth stage 9.3 → 9.0 ns and 32 → 0 B; vat render 32/112 fewer bytes per render with equal output; render wall time −5.1 % for the specimen stage and neutral for the early stage, so no rendering-throughput gain is claimed.