Mekanism‘s Modern Industrialization

Changelog / 更新日志 1.2.1 - 2026-09-19 Mekmi now consumes the shared Parallel API instead of owning the parallelism interface. The old icu.kudikan.mekmi.api package is gone, so an accelerator addon depends on parallelapi rather than on this mod.

English Added Declared parallelapi [1.0.0,) as a required dependency. Its types appear directly in Mekmi's public signatures, so a missing mod is a load-time failure rather than a graceful fallback. Changed The parallelism seam moved from owned to consumed. Deleted the icu.kudikan.mekmi.api package (MekmiParallelismSource, ParallelismProvider, MekAbsoluteInteger) and migrated every use to icu.kudikan.parallelapi. This removes the possibility of two competing copies of the same interface existing at runtime, where an accelerator registers with one and a machine queries the other — a mismatch that compiles, loads, runs, and silently leaves the multiplier at 1. CompactCompressionMachine.applyExternalParallelism / externalParallelismMultiplier now call ParallelismRegistry. 98 MekAbsoluteInteger call sites became ParallelNumbers, across 22 main sources and 7 test files. ParallelNumbers intentionally provides no subtract, so the 5 in-place decrements now call Flux's instance method directly: remaining.subtract(ParallelNumbers.valueOf(n)). remaining is a freshly produced object at every one of those sites (the result of multiply or copy), so mutating it in place is safe. The API omitting subtract is the point: an operation that looks harmless but modifies its argument should not spread across a module boundary. Notes ParallelNumbers.one() returns a fresh instance per call; the old MekAbsoluteInteger.one() returned a shared constant. That is a safety improvement rather than a behaviour change, and none of the 3 call sites depended on the shared identity. ParallelNumbers.fromBigInteger rejects a negative input, which is stricter than the old implementation; every call site passes a non-negative value. Verified at the bytecode level that Mekmi's 22 classes and the accelerator's 3 classes reference the same icu.kudikan.parallelapi package, and that the accelerator jar contains no reference to Mekmi. 中文 新增 将 parallelapi [1.0.0,) 声明为必需前置。它的类型直接出现在 Mekmi 的公开签名中，因此缺类会是加载期失败，而不是优雅降级。 变更 并行接口从"自持"改为"消费"。删除 icu.kudikan.mekmi.api 包（MekmiParallelismSource、ParallelismProvider、MekAbsoluteInteger），全部迁移到 icu.kudikan.parallelapi。这从结构上消除了"同一接口存在两份实现"的可能 —— 那种情况下加速件注册到一份、机器查询另一份，编译能过、游戏能启动、运行不报错，而倍率永远是 1。 CompactCompressionMachine.applyExternalParallelism / externalParallelismMultiplier 现在调用 ParallelismRegistry。 98 处 MekAbsoluteInteger 调用点改为 ParallelNumbers，涉及 22 个主源文件与 7 个测试文件。 ParallelNumbers 有意不提供 subtract，因此 5 处就地减法改为直接调用 Flux 的实例方法：remaining.subtract(ParallelNumbers.valueOf(n))。这 5 处的 remaining 都是刚生成的对象（multiply 或 copy 的结果），就地修改是安全的。API 不提供 subtract 正是要点：一个"看起来无害、实际修改入参"的运算不应跨模块边界扩散。 备注 ParallelNumbers.one() 每次返回新实例；旧的 MekAbsoluteInteger.one() 返回共享常量。这是安全性改进而非行为变更，且 3 个调用点都不依赖共享身份。 ParallelNumbers.fromBigInteger 会拒绝负值，比旧实现更严格；所有调用点传入的都是非负值。 已用字节码验证：Mekmi 的 22 个 class 与加速件的 3 个 class 引用同一个 icu.kudikan.parallelapi 包，且加速件 jar 中不含任何对 Mekmi 的引用。 1.1.16 Changes Since 1.1.14 - 2026-09-19 English Added Added the exact parallelism provider API (ParallelismProvider, MekmiParallelismSource) and the MekAbsoluteInteger hot-path helpers. External mods can register a source whose multiplier is multiplied into a machine's own compression parallelism and stays exact until a legacy boundary is reached. Compact machine families now apply registered external parallelism through applyExternalParallelism, so an addon such as paralleltorch multiplies into the same exact count instead of replacing it. Item and fluid slot capacities are now carried as exact AbsoluteInteger values through MekCompressionProfile and CompactTierVariant, including a slotCapacity(perLane) helper and saturating *Long() views for legacy callers. MekCompressionProfile.fromBase gained an external-parallelism overload, and the compact machines now fold the registered external multiplier into their slot capacities as well as their process count. An external source scales what the machine produces per tick, so the storage lanes have to grow with it. CompactFactorySlotCapacity now keeps two channels: an exact, mekmi-owned capacity that is persisted under its own NBT key (putString decimal alongside the legacy putLong), and a saturating long view used only for MI's getCapacity() / getRemainingCapacityFor() / getTotalCapacityFor() contract. The exact value is authoritative and a saturated view is never written back. CompactItemAmountFormatter gained AbsoluteInteger and BigInteger overloads and a longer lower-case suffix ladder, so an amount above the last named tier no longer collapses into a single long t string. The existing k/m/b/t output is unchanged. Declared fluxnetworks_ultimate_addon as a required dependency. AbsoluteInteger is injected by that addon's embedded Flux overlay, and it appears directly in mekmi's public signatures, so a missing class would be a load-time NoClassDefFoundError rather than a graceful fallback. Changed Every tier enum now implements CompactTierVariant; CompactEbfVariant and CompactImplosionCompressorVariant keep their existing factoryProcesses() name and gain batchProcesses() as an alias, so existing callers are unaffected. Fixed Fluid tanks no longer lose their contents when capacity is recomputed. ConfigurableFluidStack.setCapacity(long) silently clamps the stored amount down to the new capacity, and setAmount(long) throws IllegalStateException("amount > capacity in the fluid stack") when the amount would exceed it, so MI's own API cannot express a safe in-place shrink in either order. Because capacity is now derived from the compression ratio and the external parallelism multiplier, and is recomputed on onLoad and readNbt, removing an external source would shrink a tank on the next load and destroy everything above the new figure. All six compression-driven tank capacity writes now go through CompactFluidSlotCapacity.setWithoutClipping, which applies capacity = max(requested, stored): a shrink is deferred until the tank has drained below the new figure, so no fluid is destroyed and the ceiling still falls back on its own as the contents are consumed. Replaced Math.multiplyExact / Math.addExact on paths that can now reach saturation. These ran from the tick loop and from recipe settlement, where an ArithmeticException would abort the tick: the EBF factory-lane balancing, the implosion compressor's shared slot capacity, and the crafter's item/fluid insert loops now saturate at the boundary instead. Fixed ceilDivide wrapping negative: quotient + 1 overflowed when the input was a saturated output ceiling. Fixed in both the JEI recipe and the steam machine (the steam copy already guarded negative input but not the wrap). Fixed the EBF lane redistribution computing (total + remainingSlots - 1) / remainingSlots, which could overflow before the division. Fixed the compilation of CompactEbfCompressionCrafterMixin: the fluid input loop compared an AbsoluteInteger against int with remaining > 0, which AbsoluteInteger does not support. It now uses !remaining.isZero(), matching every other loop in the file. Removed a duplicated @Unique annotation on mekmi$multiplierExact. Notes The built-in compression tiers alone stay inside long: the highest ratio (x68157440) with a 16,000 mB fluid lane reaches about 1.09e12. Reaching an above-long value requires an external parallelism source, which is exactly what the exact channel exists for. With the compressed-torch addon's top tier (172,186,884x) in range, a single 16,000 mB fluid lane passes Long.MAX_VALUE from compression tier x4259840 upward (about 1.17e19 at that tier and 1.88e20 at x68157440). Two stacked torches overflow long at every tier, including x532480. A 64-per-lane item budget stays inside long even at the top tier with one torch (about 7.5e17), though it is far past int. Both lanes use the same exact path, so the item lane is correct either way. Because an external source multiplies the process count, it also multiplies what one tick produces. Folding it into the slot capacities is what keeps a torch-accelerated machine from producing more than its slots can hold. Tests MekAbsoluteCapacityTest and CompactTierExactCapacityTest prove the exact channel really holds values past Long.MAX_VALUE, that the unbounded Long.MAX_VALUE item sentinel survives every ratio and every tier without being scaled, that the saturating long view differs from the exact value, and that add does not mutate its operands. Both classes were checked for falsifiability by injecting mutations into the implementation. ExternalParallelismCapacityTest uses the real shipped numbers (the torch addon's 172,186,884x, not a synthetic value) to pin where a fluid lane actually crosses Long.MAX_VALUE, and to pin where it does not: a single torch crosses at compression tier x4259840, while x532480 stays below long even with a torch and only overflows once torches stack. CompactFluidSlotCapacityTest covers the capacity rule and includes a regression guard that scans the machine sources: any file computing compressionProfile().fluidSlotCapacityLong() without routing it through CompactFluidSlotCapacity fails the build. All three were verified falsifiable by mutation — removing the floor, dropping the non-positive guard, and reverting one machine to a bare setCapacity each produced failures. 中文 新增 新增精确并行来源 API（ParallelismProvider、MekmiParallelismSource）与 MekAbsoluteInteger 热路径助手。外部模组可以注册并行来源，其倍率会与机器自身的压缩并行数相乘，并在到达 legacy 边界前保持精确。 紧凑机器系列现在通过 applyExternalParallelism 应用已注册的外部并行来源，因此 paralleltorch 这类附属模组是乘入同一个精确计数，而不是替换它。 物品槽与流体槽容量现在以精确 AbsoluteInteger 贯穿 MekCompressionProfile 与 CompactTierVariant，并新增 slotCapacity(perLane) 辅助方法与供旧调用方使用的饱和 *Long() 视图。 CompactFactorySlotCapacity 现在维护双通道：mekmi 自有的精确容量（用独立 NBT 键持久化，十进制 putString 与旧的 putLong 并存），以及仅用于 MI 的 getCapacity() / getRemainingCapacityFor() / getTotalCapacityFor() 契约的饱和 long 视图。精确值权威，饱和值绝不回写。 CompactItemAmountFormatter 新增 AbsoluteInteger 与 BigInteger 重载，并延长了小写后缀阶梯，因此超过最后一档的数值不再坍缩成一个 long 的 t 字符串。既有 k/m/b/t 输出保持不变。 将 fluxnetworks_ultimate_addon 声明为必需前置。AbsoluteInteger 由该附属内嵌的 Flux overlay 注入，且直接出现在 mekmi 的公开签名中，缺类会是加载期 NoClassDefFoundError，而不是优雅降级。 变更 所有等级枚举现在都实现 CompactTierVariant；CompactEbfVariant 与 CompactImplosionCompressorVariant 保留原有 factoryProcesses() 名称，并新增 batchProcesses() 别名，既有调用方不受影响。 修复 流体槽在容量重算时不再丢失存量。ConfigurableFluidStack.setCapacity(long) 会把存量静默砍到新容量，而 setAmount(long) 在存量超过容量时会抛 IllegalStateException("amount > capacity in the fluid stack") —— 也就是说 MI 的 API 无论以何种顺序都无法安全地表达"就地缩容"。由于容量现在由压缩倍率与外部并行倍率共同决定，并在 onLoad / readNbt 时重算，移除外部来源会导致下次加载时缩容并销毁超出新容量的全部存量。现在全部 6 处由压缩驱动的流体容量写入都经过 CompactFluidSlotCapacity.setWithoutClipping，规则为 容量 = max(请求值, 存量)：缩容会推迟到存量降到新值以下才生效，因此不会销毁任何流体，而上限仍会随存量消耗自然回落。 替换了可能触及饱和的路径上的 Math.multiplyExact / Math.addExact。这些代码运行在 tick 循环与配方结算中，抛出的 ArithmeticException 会中断 tick：EBF 的工厂通道均衡、内爆压缩机的共享槽位容量、以及配方桥的物品/流体插入循环，现在都在边界处饱和。 修复 ceilDivide 回绕成负数：当输入是饱和的输出上限时，quotient + 1 会溢出。JEI 配方与蒸汽机两处都已修复（蒸汽机那份原本只挡了负数，没挡回绕）。 修复 EBF 通道重分配的 (total + remainingSlots - 1) / remainingSlots，它在除法之前就可能溢出。 修复 CompactEbfCompressionCrafterMixin 的编译错误：流体输入循环使用 remaining > 0 将 AbsoluteInteger 与 int 比较，而 AbsoluteInteger 不支持该运算。现改为 !remaining.isZero()，与文件内其他循环保持一致。 移除 mekmi$multiplierExact 上重复的 @Unique 注解。 备注 仅靠内建压缩档位不会超过 long：最高倍率（x68157440）下单条 16,000 mB 流体通道约为 1.09e12。要达到超过 long 的值需要外部并行来源，而这正是精确通道存在的意义。 在压缩火炬附属的最高档（172,186,884x）范围内，单条 16,000 mB 流体通道从压缩档 x4259840 起超过 Long.MAX_VALUE（该档约 1.17e19，x68157440 时约 1.88e20）。两支火炬叠加则在所有档位都溢出 long，包括最低的 x532480。 物品通道每 lane 只有 64，即使最高档配一支火炬仍在 long 以内（约 7.5e17），但已远超 int。两条通道走同一套精确路径，因此物品通道两种情况都正确。 由于外部来源是乘入并行数，它同时放大了机器每 tick 的产出。把该倍率一并计入槽位容量，才能避免被火炬加速的机器产出超过槽位可容纳的量。 测试 MekAbsoluteCapacityTest 与 CompactTierExactCapacityTest 证明了精确通道确实能承载超过 Long.MAX_VALUE 的值、无界的 Long.MAX_VALUE 物品哨兵在所有倍率与所有等级下都不会被放大、饱和 long 视图与精确值不同、以及 add 不会修改其入参。两个测试类都通过向实现注入变异验证过可证伪性。 ExternalParallelismCapacityTest 使用真实出货数值（火炬附属的 172,186,884x，而非虚构值）锁定流体通道究竟在何处越过 Long.MAX_VALUE，也锁定它不越过的地方：单支火炬在压缩档 x4259840 越过，而 x532480 即使配一支火炬仍在 long 以内，只有叠加火炬才会溢出。 CompactFluidSlotCapacityTest 覆盖容量规则，并包含一条回归防护：扫描机器源码，任何计算 compressionProfile().fluidSlotCapacityLong() 却未经过 CompactFluidSlotCapacity 的文件都会导致构建失败。三个测试类都通过变异验证过可证伪性——移除 floor、去掉非正数守卫、把一台机器改回裸 setCapacity，各自都产生了失败。