Tags
Creators
Details
Licensed MIT
Published 6 months ago
Updated last month
All versions
1.3.2
Beta
Create Optimized Trains 1.3.2last month 1,654
Compatibility
Minecraft: Java Edition
1.20.1–1.20.6
Platform
Forge
Supported environments
Client and server
Required content
Unavailable version
Changes
v1.3.2
Focus
- Fixes the remaining Copycats+ bit lag, a critical world-load freeze, and last-carriage movement stutter
- All fixes are follow-ups discovered while stress-testing v1.3.1 on maps with 40+ trains and Copycats+ bit-heavy contraptions
Bug Fixes
Copycats+ Periodic Lag (Bit Blocks with BlockEntity)
- Contraptions containing Copycats+ "bits" (sub-block sized pieces with a BlockEntity, unlike plain slabs/panels) caused periodic lag spikes every few seconds
- Root cause:
ContraptionWorlddoes not overridegetBlockEntity(), so it fell back toWrappedLevel.getBlockEntity(), which queried the real world using the contraption's local coordinates (e.g. 5,1,3) — forcing the server to load/query the chunk at real-world (0,0) on every call - Fix:
ContraptionWorldBlockEntityMixininterceptsgetBlockEntity()onLevel(filtered toContraptionWorldinstances) and always serves the BlockEntity fromcontraption.getBlocks(), with a lazy per-instance cache — never touching the real world with local coordinates
World Freeze on Startup (Memory Pressure)
- On some world loads, especially after the server had been running a while, the game would hang completely at the loading screen (no crash, just a full freeze)
- Root cause: heap memory pressure genuinely reaching 90%+ during startup, mainly from Distant Horizons' distant world generation competing with ~40 Create contraptions being assembled simultaneously — triggering long stop-the-world GC pauses (minutes-long in the worst case)
- Fix:
DistantHorizonsThrottletemporarily reduces DH's distant world generation and worker thread count for the firststartupThrottleTicks(default 200 ticks / 10s) after the server starts, giving vanilla terrain and contraption assembly priority. DH's original settings are restored automatically afterwards. Uses DH's public API via reflection — no hard dependency
Last-Carriage Movement Stutter
- Long trains (10+ carriages) without a player on board showed irregular movement — the stutter would noticeably improve once the rearmost carriage's entity finally loaded
- Root cause:
ChunkLoadManager's per-tick chunk load rate limit applied to every needed chunk indiscriminately, including the exact chunk each carriage physically occupies. On unoccupied trains, that chunk competed with lookahead/trailing chunks for the same 6-per-tick budget, so the last carriage in line could take several ticks just to get its own chunk loaded — delaying its entity creation - Fix: chunk requests are now split into critical (the exact chunk under each carriage — always loaded immediately, no rate limit, regardless of occupancy) and soft (LOD comfort radius, directional lookahead, trailing buffer — still rate-limited). No carriage, including the rearmost one, waits behind empty pre-load chunks anymore
Chunks Not Unloading When a Train Stops
- Chunks along a train's previous travel direction could remain force-loaded indefinitely after the train stopped, accumulating over a session and degrading performance over time
- Root cause: the anti-thrash "recently loaded" deque only advances when new chunks are loaded; once a train stops, nothing loads, so old lookahead chunks stayed protected from unloading forever
- Fix: the anti-thrash deque is cleared as soon as a train's speed drops below the movement threshold, letting unneeded chunks unload immediately
Improvements
Chunk Loading Tuning
- Adaptive lookahead margin increased from ~2s to ~5s of travel time, to reliably cover cold-terrain chunk generation (which can take 2-3s) — default cap raised from 10 to 20 chunks
- Per-tick chunk load budget reduced to 6 chunks with a 5ms time budget per train, preventing a single train's chunk update from blocking the whole server tick
- Non-occupied trains now have their chunk updates staggered across ticks (5 trains per batch, every 3 ticks) instead of all being processed every tick, reducing aggregate
setChunkForcedcalls per tick on maps with many trains
Diagnostics
- Added granular performance logging (
[COT/Perf],[COT] updateTrainChunks detalhe) to break down slow ticks by train and by phase (chunk calculation, unload, load) - Added
[COT/ContraptionWorldBE]activity counter to confirm the Copycats+ BlockEntity fix is intercepting calls as expected
Configuration
New config section in create_optimized_trains-common.toml:
[distant_horizons]—startupThrottleEnabled(defaulttrue),startupThrottleTicks(default200, range 20-1200)
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:lnuz740Q:qpTbANDv"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:lnuz740Q:qpTbANDv"
}

