All versions
1.1.4-1.21.1
Release
Ender IO: Conduit Optimizer 1.1.4-1.21.12 months ago 345
Compatibility
Minecraft: Java Edition
1.21.1
Platform
NeoForge
Supported environments
Client and server
Required content
Any compatible version
Changes
📄 Ender IO: Conduit Optimizer Update Changelog
English
Fixes
- Extraction Could Get Stuck: Item, fluid and gas conduits no longer get permanently stuck when the target container only accepts certain contents (for example a drawer that only takes one kind of item). Previously, an earlier rejected item could keep the destination "waiting" forever, so the item the target actually wanted was never delivered — even though everything worked with a filter attached.
- Conduits Waking Up Too Slowly After Changes: When you rebuilt or changed your conduit network, connections now start working immediately again instead of idling for a short while first.
- Chemical Conduits Ignored Filters: Chemical conduits now respect the filters placed in them. Previously, filters on chemical conduits were silently ignored and everything was extracted.
- Chemical Conduits With Mixed Contents: Chemical conduits now handle containers holding several different chemicals correctly, instead of repeatedly drawing the same chemical from the first tank.
Performance Improvements
- Faster Extraction Scheduling: Idle conduits now sleep with a smoother schedule, lowering server load in large setups without slowing down active transfers.
- Less Pointless Work During Transfer: Inside a single transfer cycle, contents that a destination has already refused are skipped instead of being offered again and again. This noticeably speeds up moving mixed contents into selective containers.
- Lower Overall Overhead: Several heavily used internal routines were rebuilt to avoid creating large amounts of temporary objects every tick.
New Features
- Smart Sleep Toggle: A new "Smart Sleep" switch has been added to the conduit interface. When turned off, the connection runs every tick just like vanilla Ender IO — useful when the target container is only available from time to time and you need an instant response. The interface has also been rearranged for better clarity: extraction frequency on top, the switches below.
中文
修复
- 抽取可能永久卡住: 当目标容器只接受特定内容物(例如只收一种物品的抽屉)时,物品、流体和气体导管不再永久卡住。此前,排在前面被拒收的内容会一直让目标处于"等待"状态,导致目标真正想要的内容始终无法送入——尽管装上过滤器后一切正常。
- 导管在改动后唤醒过慢: 重建或更改导管网络后,连接现在会立即恢复工作,不再先空转一小段时间。
- 化学品导管无视过滤器: 化学品导管现在会遵守放入的过滤器。此前,化学品导管上的过滤器被静默忽略,所有内容都会被抽取。
- 化学品导管抽取混合内容异常: 化学品导管现在能正确处理存放多种不同化学品的容器,不再反复只从第一个储罐抽取同一种化学品。
性能优化
- 抽取调度更省力: 空闲导管现在以更平滑的节奏休眠,在不拖慢正常传输的情况下,降低大型工程的服务器负载。
- 传输过程中减少无用功: 在同一次传输周期内,已被目标拒收的内容会被直接跳过,不再被一次次重复尝试。向挑剔的容器输送混合内容时速度明显提升。
- 整体开销降低: 重写了导管运行中若干使用最频繁的内部流程,减少了每刻大量临时对象的产生。
新功能
- 智能休眠开关: 导管界面新增"智能休眠"开关。关闭后,连接将像原版末影接口一样每刻运行——适用于目标容器间歇可用、需要即时响应的场景。界面布局也重新调整:抽取频率在上,开关在下,更加清晰。
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:SgW9mQeM:ScrPUQOq"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:SgW9mQeM:ScrPUQOq"
}

