1.1.1
Compatibility
Required content
Changes
Stability and performance update, for large-scale setups.
Performance
-
Long lines of cables and components no longer cause server freezes. On a long chain, each pulse could freeze the server for over a second while everything recalculated. The mod constantly monitors setups that loop infinitely without stabilizing, as they would otherwise crash the game. The issue was that it re-checked this condition at every powered component, re-scanning the entire circuit each time. It was like re-reading a book from page one every time you turn a page: twice as many components meant four times the work for the mod. However, this condition only depends on how your blocks are connected, not on the current running through them. It is now calculated just once for the entire circuit and cached until you modify a connection. On a test setup of 320 diodes, the mod drops from 4.4 million checks down to 47,000.
-
Closing a loop no longer freezes the server. Placing the last connection of a loop — whether valid or not — used to freeze the game for nearly a second. When a component changes state, it updates its neighbors. In a loop, A updates B, which updates C, which updates D, which updates A again, indefinitely. The mod did have a failsafe against this, but it was ineffective: Minecraft doesn't send these messages immediately; it queues them up for later processing, meaning the failsafe never saw the message loop back. The freeze was simply the game processing the 1 million messages it allows itself before giving up. Each component is now capped at eight neighbor updates per tick. That million messages drops below 200. A standard setup never uses more than three, so your usual circuits remain unaffected.
Bug Fixes
-
Unstable loops with adjacent components are now properly detected. A cycle without any cables — a 2x2 square of four components, for instance — was ignored by all systems because detection only triggered from a cable network. A component toggling state without powering a cable now triggers the detection check itself.
-
Unstable loops containing two consecutive components now open correctly. Detection worked, but the loop breaker only targeted the input cable of the identified component. When that component was powered directly by another, no cable was present to be broken, so nothing happened. Three inverters in a row would thus loop indefinitely. The breaker now traces inputs back to the cycle's first cable.
-
Cable-less cycles are broken by sacrificing a component. With no cable to break, a diode or a Delayer in the cycle is destroyed instead — never an inverter — and drops on the ground just like a cable would.
-
Setting a Delayer to 0 ticks triggers a loop re-evaluation. At zero ticks, a Delayer acts like a diode and no longer stabilizes a loop; however, the mod previously continued to treat it as safe.
-
Detection no longer breaks during frozen ticks. It relied on the world clock — which
/tick freezestops — and could end up retaining outdated states.
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:uehpQpsS:fkOWAEGR"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:uehpQpsS:fkOWAEGR"
}

