Tags
Creators
Details
0.4.0.alpha
Compatibility
Changes
We finally implement fluid handling.
[Added]
-
Fluid Input and Fluid Output Nodes: Flowchart nodes designed to extract, deposit, and route liquids across network cables.
-
Vanilla Cauldron Support: Water, lava, and empty cauldrons are now recognized as valid fluid network terminals, allowing players to fill or drain them automatically.
-
Special Block Capability Registry: A developer API allowing third-party add-ons to bridge standard blocks that do not natively implement NeoForge capabilities to the physical cable network.
-
Ench and Damage settings overlays: Sub-panels inside the advanced item filter cards now feature custom configurations.
-
New unified execution logging channel to cleanly monitor flowchart triggers, item routing, and settings warnings in debug logs.
[Changed]
-
Topological Capability Registry: Hardcoded network checks have been migrated to a registry-based pattern, laying the groundwork for energy and chemical integration.
-
Submenu Layouts: Category hover menus are now wider, centering their columns and incorporating better vertical spacing.
-
Planning Safety: Asynchronous flowchart planning now runs against immutable thread-safe snapshots of scanned block configurations to prevent state desyncs.
-
Refactored core internal logic to completely separate flowchart data models from their pathfinding planners, making the codebase more modular.
-
Moved copy, delete, and movement canvas actions out of the main block controller into a dedicated canvas actions handler.
[Fixed]
- Symmetrical Grid Centering: Custom slot configuration popups now align and center their grids relative to the number of available slots.
[Removed]
- Hardcoded Capability Enums: Eliminated the legacy ConnectionBlockType enum to prevent system constraints on future capability additions.
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:LTva5BWN:qDvHRPZP"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:LTva5BWN:qDvHRPZP"
}

