you can find the web tools in github link

# GGG: ModuleWorks

`GGG: ModuleWorks` is a toolkit mod focused on modular factory trials, certification, duplication, and deployment, currently built for `NeoForge 1.21.1`.

Its goal is not simply to reduce lag, and not to turn automation into a generic black-box machine. Instead, it builds a full workflow around designing a factory module inside a compact room, validating it through a controlled trial, locking it in as a template, and deploying it later as a reusable unit.

If you enjoy:

- building standardized factories inside compact spaces
- testing production lines under controlled conditions
- reusing finished modules instead of rebuilding them every time
- creating a factory system that is configurable, balanceable, and expandable for modpacks

then this mod is built for that style of gameplay.

---

## Core Idea

In the current version, players do not start with a pre-defined factory block that already knows its recipe and production rate.

Instead, the player builds a real factory inside a compact room first, then runs a trial to certify that setup into a template.

That means templates are not predefined assets. They are created from player-built factories.

The overall loop looks like this:

1. Certify a target output item
2. Build machines, logistics, and power inside a compact room
3. Enter build mode and adjust the factory
4. Enter trial mode for warmup and formal measurement
5. Generate a Factory Master Template that records output, materials, inputs, and energy usage
6. Duplicate that template into a Deployable Factory Template by paying the required material cost
7. Use a Template Producer to simulate the certified factory at its recorded production rate

In other words, this mod is closer to a factory module workflow system than a normal "more machines" content mod.

---

## Main Features

### 1. Compact Room Factory Trials

You can place a `Trial Item Inputter` inside a compact room and let it detect the room boundary automatically.

This block acts as the main controller for the entire trial process. It is responsible for:

- switching between build mode and trial mode
- defining the target output item
- receiving the tested output through automation
- generating the final factory template when the run is complete

### 2. Separate Build Mode and Trial Mode

The current version keeps factory construction and production measurement strictly separate.

In build mode:

- players can keep building and adjusting the factory
- selected block entities are heavily slowed down to prevent stockpiling output before the real run starts

In trial mode:

- the player is switched to spectator mode
- the factory runs under controlled conditions
- only this phase counts toward the certified output

This separation is meant to reduce easy abuse, such as building up large hidden buffers during setup and cashing them out during the measured run.

### 3. Warmup Phase and Formal Counting Phase

Trials do not start counting final output immediately.

Each run is split into two phases:

- a warmup phase
- a formal counting phase

The warmup phase allows the line to stabilize before the actual production count begins.

Current default timing:

- warmup: `10` seconds
- formal counting: `30` seconds

If no first output arrives during warmup, the trial automatically stops and performs cleanup, so players are not left stuck in spectator mode waiting forever.

### 4. Automatic Factory Material Scanning

When a trial finishes, the mod scans the entire compact room and builds a material list for the tested factory.

This is not meant to be a structure blueprint printer. Its main purpose is to support a "materials for template duplication" workflow.

That means once a player has built and certified a good module once, they do not need to manually reconstruct the same machine every time. They can:

- certify the original setup
- pay the required material cost
- duplicate the factory template for later deployment

This makes the system much more about modular factory reproduction than structure replay.

### 5. Automatic Input and Throughput Scanning

The current version does not only measure final output. It also scans the factory's required item inputs.

Together with the `Trial Item Outputter`, this lets you simulate:

- what input items the module needs
- how fast those items must be supplied

As a result, the final certified template does not only know what it produces. It also knows what input conditions are required to sustain that output.

### 6. FE Power Requirement Scanning

The current version also scans FE power demand.

If a factory actually consumes power during its trial, the resulting template records:

- how much FE per tick it needs

Later, if that template is placed into a Template Producer, it will only run correctly when external power is provided.

### 7. Two Types of Factory Templates

To prevent freshly certified room data from being used as an immediate deployable production template, the system splits factory templates into two layers:

#### Factory Master Template

- created directly when a trial finishes
- stores the full certified factory data
- cannot be used directly in a Template Producer

#### Deployable Factory Template

- created by duplicating a Factory Master Template in a Template Copier
- can be used in a Template Producer

The reason is straightforward:

After a trial ends, the original factory setup usually still exists and may still need further adjustment. If the first generated template could be deployed immediately, the logic would be much looser and easier to exploit.

So the current version uses a stricter flow:

Master Template -> Duplication -> Deployable Template

### 8. Template Copier

The `Template Copier` reads the material list stored on a factory template and checks nearby containers for the required items.

If enough materials are present, it consumes them and outputs a new Deployable Factory Template.

It also supports:

- renaming the produced template
- duplicating already-deployable templates again

This makes templates behave more like a production asset pipeline than a one-time reward item.

### 9. Template Producer

The `Template Producer` is the block that turns a certified template into an active production simulator.

It currently supports:

- accepting Deployable Factory Templates
- providing output at the recorded production rate
- consuming required input items from adjacent input containers
- requiring external FE power when the template was certified with energy usage
- recursively accounting for nested Template Producers

That means if a larger module already depends on another template-based submodule, the resulting template can still carry that dependency chain forward.

### 10. Debt-Based Item and Energy Consumption

Many production rates are not clean integers.

For example, a template may effectively correspond to:

- `19.3` items per minute of input consumption
- or a rare, expensive ingredient that should only be charged occasionally

If the system simply rounded everything up each time, the ratio would be distorted badly. If it produced first and charged later, it would create easy free-output abuse.

So the current version uses a debt-style remainder system for both:

- item consumption
- energy consumption

This keeps long-term consumption much closer to the original trial data and avoids easy exploitation of low-frequency, high-value inputs.

### 11. Trial Item and Energy Sources

To make building and testing factories more controlled, the current version also provides two dedicated support blocks:

#### Trial Item Outputter

- accepts a Certified Item Template
- lets you define an output rate
- provides the corresponding item during active trial runtime

Current rate controls support both:

- per minute
- per second

#### Trial Energy Outputter

- lets you define FE output per tick
- provides power to adjacent blocks during active trial runtime

This is mainly intended for stable testing of powered factories.

### 12. In-Game Configuration Tools and Web Workflow

The current version already includes a full configuration editing workflow.

This includes:

- the `Config Editor` block
- the `Config Debugger` item
- `/ggg explore` to export a snapshot
- `/ggg reload` to reload from a snapshot
- external web-based configuration tools

This allows modpack authors to:

- make quick in-game fixes for individual items
- browse rule assignments in table form
- export the current instance state to JSON
- edit large rule sets externally
- reload the results back into the game

---

## Main Blocks and Items

### Blocks

- `Trial Item Inputter`
- `Template Copier`
- `Template Producer`
- `Item Template Manager`
- `Trial Item Outputter`
- `Trial Energy Outputter`
- `Config Editor`

### Items

- `Factory Master Template`
- `Deployable Factory Template`
- `Certified Item Template`
- `Config Debugger`

---

## Who This Mod Is For

This mod is best suited for players who enjoy:

### 1. Modular Factory Design

If you do not want every automation line to be a one-off build, and instead want to turn a successful setup into a repeatable module, this mod fits that mindset well.

### 2. Compact Room Automation

If you already enjoy building inside `Compact Machines`, the current version is heavily centered around that environment.

### 3. Real Trial-Based Validation

This mod does not rely on static spreadsheet math alone.

You build the factory, warm it up, run it, measure it, and certify it through actual in-world behavior.

If you prefer "build it and test it" over "calculate it in advance," this system should feel much more satisfying.

---

## Why Modpack Authors May Care

For modpack authors, the most valuable part of the current version is that it turns player-built factories into reusable, balanceable template assets.

This allows you to build progression, economy, quests, or module systems around:

- certified factory modules
- room-restricted automation
- configurable item and block behavior rules

The current rule system already lets you configure whether an item or block:

- can be brought into compact rooms
- can be simulated as an output
- is slowed during build mode
- is excluded from material cost scanning
- is cleaned during warmup cleanup
- is cleaned during strong cleanup

That gives modpack authors a fairly precise way to shape the system instead of accepting a fixed hardcoded ruleset.

In addition, because full snapshots can be exported and edited externally, larger packs are much more manageable than they would be with manual JSON maintenance alone.

---

## Configuration and Commands

### Config Directory

On first run, the mod automatically creates its own config directory:

- `config/ggg_moduleworks/`

Main files currently include:

- `ggg_moduleworks.properties`
- `ggg_moduleworks_item_config.json`
- `ggg_moduleworks_registry_cache.json`
- snapshot and runtime log files inside the `exports/` folder

### Important Config Options

The main adjustable values currently include:

- warmup duration
- formal counting duration
- output rounding tolerance
- build-mode slow tick factor

### Commands

The current command root is:

- `/ggg`

Important subcommands:

#### `/ggg explore`

Exports the current configuration snapshot.

#### `/ggg reload`

Reloads configuration from an exported snapshot.

Supports:

- loading the latest snapshot automatically
- loading a specific snapshot file by name

#### `/ggg trial_seconds <warmup> <counting>`

Changes warmup duration and formal counting duration.

---

## Current Dependencies

### Required

- `NeoForge 21.1.219+`
- `Minecraft 1.21.1`

### Current Functional Dependency

- `Compact Machines 7.0.81+`

The current version still runs around the compact room environment provided by `Compact Machines`.

Future versions may decouple the room system, but this release is still designed around that dependency.

---

## Design Notes for the Current Version

### 1. This Is Not a Simple "Place It and It Produces" Box

The intended loop is:

- design
- trial
- certify
- duplicate
- deploy

So the mod is much more about factory module workflows than ready-made automation boxes.

### 2. This Is Not a Traditional Structure Blueprint Clone

The current template system stores:

- material requirements
- input requirements
- energy requirements
- output results

It is not primarily a full coordinate-by-coordinate structure replay system.

The focus is factory modularization, not direct scene printing.

### 3. The Current Balance Focus Is Preventing Build-Phase and Warmup-Buffer Abuse

That is why the system includes:

- build-mode slow ticking
- warmup cleanup
- strong cleanup
- spectator-based trial mode
- debt-based item and energy accounting

All of these are there to keep trial results more trustworthy.

---

## Suggested Use

If you are a regular player, the recommended flow is:

1. certify a target output item
2. build a module inside a compact room
3. complete a trial with the Trial Item Inputter
4. duplicate the resulting Master Template
5. use the Deployable Template in a Template Producer

If you are a modpack author, a good workflow is:

1. start with the default rules
2. fix edge cases with the in-game config tools
3. export a full snapshot with `/ggg explore`
4. batch-edit the rules with the web tool
5. reload them with `/ggg reload`

---

## Short Release Description

`GGG: ModuleWorks` is a modular factory toolkit for compact-room trials, certification, duplication, and deployment on `NeoForge 1.21.1`.

---

## Current Version Summary

- The current version is centered around modular factory gameplay inside compact rooms
- It already includes in-game config tools and an external web-based configuration workflow
- It already supports scanning factory materials, item inputs, power usage, and nested template dependencies

If you plan to build a modpack around it, it is strongly recommended to tune the whitelist and cleanup rules for your own content set so the system stays predictable and stable.

All of the above are AI-translated, and I can't understand them either. This is the video tutorial I made on Bilibiliviod

------以下是中文，我真不会英语我求你了------

# GGG: ModuleWorks

`GGG: ModuleWorks` 是一个面向模块化工厂试炼、认证、复制与部署的工具模组，当前适用于 `NeoForge 1.21.1`。

它的核心目标不是单纯降低负载，也不是把自动化流程直接抽象成一个“黑盒机器”，而是把玩家在压缩空间里亲手设计一套工厂模块，再把它验证、定型、复制、部署的整套过程做成一条完整工具链。

如果你喜欢：

- 在压缩空间里搭建标准化工厂
- 给工厂做限条件试炼
- 把设计好的模块复制到别处继续用
- 为整合包制作一套可控、可平衡、可扩展的工厂模块体系

那么这个模组就是为这类玩法准备的。

---

## 模组的核心思路

在当前版本里，玩家不是直接拿到一个“已经定义好配方和产量的工厂方块”，而是先自己在压缩空间中搭建工厂，再通过试炼把这套结构认证成模板。

也就是说，模板不是预设出来的，而是玩家自己设计出来的。

这套流程大致是：

1. 先认证一个目标产物
2. 在压缩空间里摆放机器、物流和供能
3. 进入建造态调整工厂
4. 进入试炼态进行暖机和正式统计
5. 得到一份记录了产量、材料、输入和耗电信息的工厂母版模板
6. 消耗对应材料，把它复制成可部署工厂模板
7. 用模板产出器按认证后的结果持续模拟这套工厂的产物输出

换句话说，这个模组更接近“工厂模块设计与部署系统”，而不是普通意义上的“再加几台机器”。

---

## 当前版本的主要功能

### 1. 压缩空间工厂试炼

你可以在压缩空间中放置 `试炼物品输入器`，让它识别所在房间的边界，并作为这次试炼的核心控制方块。

它负责：

- 控制建造态与试炼态的切换
- 识别目标产物
- 接收自动化物流送入的目标物品
- 在试炼结束后生成工厂模板

### 2. 建造态与试炼态分离

这个模组当前把“搭机器”和“正式统计产量”严格分开。

在建造态：

- 玩家可以继续搭建和调整工厂
- 但受控方块会进入慢 tick 状态，避免提前大量囤产物

在试炼态：

- 玩家会切换到旁观者模式
- 工厂开始正式运行
- 统计逻辑只在这个阶段生效

这个设计的目的，是尽量减少“建造阶段提前囤货，试炼阶段瞬间冲分”的作弊空间。

### 3. 暖机阶段与正式统计阶段分离

当前版本的试炼流程不是一按按钮就直接开始记最终产量，而是分成两个阶段：

- 暖机阶段
- 正式统计阶段

暖机阶段的意义是让整条生产线先进入稳定状态，再开始真正计数。

目前默认时长为：

- 暖机 `10` 秒
- 正式统计 `30` 秒

如果暖机时间内没有接收到首个目标物品，试炼会自动终止并清理现场，避免玩家被卡在旁观模式里干等。

### 4. 自动扫描工厂材料

试炼结束后，模组会扫描整个压缩空间内的工厂设备，并整理出一份材料清单。

这份清单不是为了做结构蓝图复刻，而是为了支持“材料换模板复制”的玩法。

也就是说，玩家第一次认真搭完一个模块以后，不需要每次再手工重复摆同样一套机器，而是可以：

- 先通过试炼认证
- 再用材料去复制这份工厂模板

这个方向更偏向“模块化工厂量产”，而不是“结构摆放推演”。

### 5. 自动扫描输入物与输入速率

当前版本不只统计最终产物，也会扫描工厂运行需要的原料输入。

配合 `试炼物品输出器`，你可以在压缩空间里模拟：

- 这个模块需要吃什么原料
- 这些原料需要多快的输入速度

这意味着最终生成出来的工厂模板，不仅知道“它能产什么”，还知道“为了产出这些东西，它需要什么输入条件”。

### 6. 自动扫描 FE 耗电

当前版本已经支持扫描工厂的 FE 耗电需求。

如果某个模块在试炼过程中确实需要电力，那么生成出来的模板会记录：

- 每 tick 需要多少 FE

之后把这份模板放进模板产出器时，如果没有满足供电条件，它就不会正常工作。

### 7. 工厂模板分成两种

为了避免玩家刚试炼完就直接把“原始现场模板”塞进模拟生产器，当前版本把工厂模板分成了两层：

#### 工厂母版模板

- 由试炼结束后直接生成
- 记录整套工厂认证数据
- 不能直接投入模板产出器

#### 可部署工厂模板

- 由模板复制机复制工厂母版后得到
- 才能真正投入模板产出器使用

这个设计的原因很简单：

试炼结束后，玩家原本搭的那套工厂并不会立刻消失，往往还要继续调试和修改。如果让刚生成的模板直接就能投入使用，逻辑上会比较松散，也更容易出现利用现场状态直接绕过成本的情况。

因此当前版本采用了“母版 -> 复制 -> 部署”的结构。

### 8. 模板复制机

`模板复制机` 用来读取工厂母版模板的材料清单，并从周围容器中检查材料是否足够。

当材料足够时，它会消耗对应物品并输出一份新的可部署工厂模板。

同时：

- 支持给模板改名字
- 支持继续复制已经部署过的模板

这个机制让工厂模板更接近“模块设计稿 -> 实际部署件”的关系。

### 9. 模板产出器

`模板产出器` 是最终把模板变成可运行模拟产线的核心方块。

它当前支持：

- 放入可部署工厂模板
- 按模板记录的速率提供产物
- 根据模板记录，从相邻输入容器扣除所需物品
- 根据模板记录，要求外部提供 FE 电力
- 递归处理嵌套模板产出器

也就是说，如果一个大模块内部本来就用了另一个模板产出器，那么最终模板也会把这部分需求继续纳入计算。

### 10. 债务式输入/耗电扣除

很多自动化系统里，真实速率并不总是整数。

比如某个模板理论上可能对应：

- 每分钟消耗 `19.3` 个原料
- 或者某个高价值原料是较低频次消耗

如果简单粗暴地每次都上取整，就会把比例扭曲得很厉害；如果先产出后扣除，又容易变成白嫖。

所以当前版本对：

- 输入物消耗
- 耗电

都用了带余数的债务机制。

这能让长时间运行下的消耗更接近真实试炼统计结果，也尽量避免因为低频高价值输入而被轻易钻空子。

### 11. 试炼用物品输入与能量输入

为了让玩家或整合包作者能更稳定地搭建和测试工厂，当前版本还提供了两个专门的辅助方块：

#### 试炼物品输出器

- 放入认证物品模板
- 设定输出速度
- 在试炼运行态持续提供该物品

当前支持按：

- 每分钟
- 每秒

两种单位调整输出速率。

#### 试炼能量输出器

- 设定每 tick 输出多少 FE
- 在试炼运行态向周围方块供能

这个方块主要是给需要电力的工厂做稳定供能测试。

### 12. 游戏内配置工具与 Web 配置工作流

当前版本已经带有完整的配置编辑支持。

包括：

- `配置编辑器` 方块
- `配置调试器` 物品
- `/ggg explore` 导出快照
- `/ggg reload` 读取快照
- 外部 Web 配置工具

这意味着整合包作者可以：

- 在游戏内快速修单个物品
- 用表格浏览全物品规则
- 把当前实例的物品状态导出为 JSON
- 在外部 Web 工具中大批量编辑
- 再导回游戏实例应用

---

## 当前版本中有哪些主要方块和物品

### 方块

- `试炼物品输入器`
- `模板复制机`
- `模板产出器`
- `物品认证机`
- `试炼物品输出器`
- `试炼能量输出器`
- `配置编辑器`

### 物品

- `工厂母版模板`
- `可部署工厂模板`
- `认证物品模板`
- `配置调试器`

---

## 适合什么样的玩家

这个模组更适合以下几类玩家：

### 1. 喜欢把工厂“模块化”设计的人

如果你不满足于做一条单机式、一次性的生产线，而是想把某一套结构做成可认证、可复制、可部署的标准模块，那么这个模组会很对路。

### 2. 喜欢在压缩空间中做精细自动化的人

如果你本来就喜欢在 `Compact Machines` 里搭工厂，当前版本基本就是围绕这种玩法展开的。

### 3. 喜欢对产线做真实测试的人

这个模组不是静态表格推演，而是真让你把机器搭出来、暖机、运行、统计、认证。

如果你更喜欢“做出来再测”，而不是“拿公式先算出来”，这个方向会更合适。

---

## 适合什么样的整合包作者

对于整合包作者来说，这个模组当前最有价值的地方在于：

### 1. 可以把“玩家亲手设计出来的工厂”转化成可重复使用的模板资产

这意味着你可以围绕“模块工厂”去做任务、经济、限制和进阶系统。

### 2. 可以通过配置白名单和黑名单控制玩法边界

当前版本已经支持针对物品和方块配置：

- 是否可带进压缩空间
- 是否可作为模拟产物
- 是否在建造态慢 tick
- 是否不计入材料
- 是否属于暖机清理
- 是否属于强清理

因此你可以比较细地约束整套系统，而不必接受一个写死的玩法框架。

### 3. 可以导出全实例快照并做外部配置

如果你的整合包物品很多，靠手写 JSON 不现实。当前版本提供的导出和 Web 配置流程，正是为了这种规模准备的。

---

## 当前版本的配置与指令

### 配置目录

模组首次运行后，会自动生成自己的配置目录：

- `config/ggg_moduleworks/`

主要文件包括：

- `ggg_moduleworks.properties`
- `ggg_moduleworks_item_config.json`
- `ggg_moduleworks_registry_cache.json`
- `exports/` 目录下的快照与日志文件

### 当前重要配置项

主要可调参数包括：

- 暖机时间
- 正式统计时间
- 产量补偿容忍百分比
- 建造态慢 tick 倍数

### 指令

当前版本的主要指令是：

#### `/ggg explore`

导出当前实例的配置快照。

#### `/ggg reload`

重新读取导出的配置快照。

支持：

- 直接读取最新快照
- 指定文件名读取

#### `/ggg trial_seconds <warmup> <counting>`

修改试炼暖机时间和正式统计时间。

---

## 当前版本的运行依赖

### 必需

- `NeoForge 21.1.219+`
- `Minecraft 1.21.1`

### 当前版本配套依赖

- `Compact Machines 7.0.81+`

当前版本仍然建立在 `Compact Machines` 的压缩空间环境上运行。

后续版本不排除将空间实现从现有依赖中抽离，但目前这一版仍按压缩空间玩法设计。

---

## 当前版本的一些设计说明

### 1. 这不是“放下就产”的黑箱工厂

这个模组强调的是：

- 玩家先设计
- 再试炼
- 再认证
- 再复制
- 再部署

所以它更偏向工厂模块工作流，而不是现成机器合集。

### 2. 这也不是传统结构蓝图复制

当前模板系统记录的是：

- 材料清单
- 输入需求
- 耗电需求
- 产量结果

而不是简单记录所有方块坐标再直接还原一份完整结构。

重点是“模块资产化”，而不是“把原场景原封不动打印出来”。

### 3. 当前版本的平衡重点是“避免通过建造态和暖机缓存作弊”

因此你会看到：

- 建造态慢 tick
- 暖机清理
- 强清理
- 旁观者试炼态
- 输入/能耗债务机制

这些设计都是围绕试炼可信度服务的。

---

## 当前版本适合怎么用

如果你是普通玩家，推荐的玩法是：

1. 用物品认证机选定目标产物
2. 在压缩空间中搭一套模块
3. 用试炼物品输入器完成认证
4. 用模板复制机做出可部署模板
5. 用模板产出器把这套模块投入正式使用

如果你是整合包作者，推荐的玩法是：

1. 先用默认规则跑通基本流程
2. 用配置调试器或配置编辑器修局部规则
3. 用 `/ggg explore` 导出完整快照
4. 用 Web 工具批量调整物品和方块规则
5. 用 `/ggg reload` 回载测试

---

## 当前版本说明

- 当前主要围绕压缩空间中的模块工厂玩法设计
- 当前版本已经包含游戏内配置工具和外部 Web 配置工作流
- 当前版本已经支持工厂材料、输入速率、耗电和嵌套模板的扫描与模板化