Links
Tags
Creators
Details
0.4.1
Compatibility
Required content
Changes
0.4.1
-
Special thanks to flamemaster396 for suggesting this feature!
-
Factory Controller compatibility (optional): when Factory Controller 1.2.1+ is installed, its virtual connection wires become dyeable too. Older Factory Controller versions disable the integration cleanly — wires stay vanilla, nothing crashes.
-
Dye wires inside the Factory Controller GUI: pick a dye up onto the cursor and right-click a hovered logistics wire to color it — the same pick-up-and-apply gesture as on the world side (a dye in the main hand works as a fallback). Black dye clears the color, the dye is never consumed, and the client-side dyeing config option carries over.
-
The GUI rendering mirrors the world side: idle wires take the dye color over their whole line, active wires keep their vanilla status core and flash animations and gain a textured 2px dye border per side — the same border-to-core proportion as a dyed wall link, reusing Factory Controller's own connection textures.
-
Hovering keeps both: the dye look stays while Factory Controller's white highlight bar still marks the hovered wire.
The wire's hover tooltip (after Factory Controller's hover delay) gains a dye line showing the applied dye, its name rendered in the dye's own color. -
Blueprint import carries colors: scanning wall gauges with a blueprint and quill keeps their link colors when the board is imported into the Factory Controller GUI. Colors also survive saving a board as a blueprint and placing that blueprint into another controller.
-
Only logistics (ingredient) wires are dyeable — number and redstone wires are left fully vanilla, mirroring the world-side rule that status-semantic lines stay untouched.
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:s8chGgzt:EsnpcWLi"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:s8chGgzt:EsnpcWLi"
}

