Versions:
Sable: 2.0.5
Create: 6.0.10
Create Aeronautics: 1.3.0 (bundled)
Minecraft/Loader: 1.21.1, NeoForge 21.1.244
Environment: Singleplayer (integrated server)
Description:
After assembling a contraption with the Physics Assembler, the sub-level becomes completely unresponsive: no further blocks can be placed on or broken from it, and it cannot be disassembled again (right-clicking the assembler does nothing, no feedback to the player). The log repeats:
[Render thread/ERROR] [dev.ryanhcode.sable.Sable/]: Received a sub-level movement packet for a non-existent sub-level
Steps to reproduce:
Place a Physics Assembler on a sandstone block.
Assemble it.
Try to place/break blocks on the assembled structure, or disassemble it again.
Interaction silently fails; the error above appears in the log.
Correlation with tick lag:
Across multiple test sessions and logs, this error is consistently preceded (within ~1–20 seconds) by a Can't keep up! Is the server overloaded? warning, ranging from ~40 to ~520 ticks behind. This holds regardless of the underlying cause of the lag, which I've observed to vary between sessions:
A large modded world with heavy background chunk pregeneration (Chunky)
A minimal superflat redstone-testing world (no ocean biomes/mobs, no terrain generation)
A session with a single very large tick stall (474 entities teleported at once → single tick took 40001ms, caught by the ModernFix watchdog)
Ruled out as sole causes (error persists without them):
Create: Power Grid (initially suspected due to #1428) — removed, error persists
Third-party addon "Create Aeronautics: Gyroscope Stabilizers" — removed, error persists
Sable 2.0.3 → updated to 2.0.5 — error persists on both versions
Spark profiler findings (3 separate profiles across different sessions):
Sable's own code consistently accounts for only ~2–5% of total sampled server-thread time across all three profiles (528–2454 out of 10560–98268 total, depending on session). This suggests Sable itself is not the source of the lag — it appears to be a victim of general tick-time overrun from unrelated systems, which varied between sessions:
NaturalSpawner (mob spawn search — heavy with many mods adding mobs)
A third-party mod's block-collision/outline-shape mixin hooks (called extremely frequently, comparable in cost to all entity ticking combined)
In worlds with ocean mobs: Alex's Mobs' EntityCachalotWhale.aiStep → Entity.move → directly into dev.ryanhcode.sable.sublevel.entity_collision.SubLevelEntityCollision.collide (this was the only profile where a specific hot path led directly into Sable's own collision code, but it wasn't present/necessary in the other two profiles, so likely just one of several possible lag sources rather than a required trigger)
com.cobblemon...PokemonEntity / ShoulderRidingEntity
Heavy LockSupport/Unsafe (thread parking) time in one profile, suggesting possible thread contention alongside CPU-bound lag
Conclusion: The desync appears to be a race condition triggered whenever the server falls significantly behind on ticks while a sub-level exists/is being managed, independent of what specifically causes the lag. Given how many different large modpacks likely hit occasional tick lag for one reason or another, this could affect a wide range of users, not just this specific mod combination.
Related issues: #805, #402, #1428 — all describe the same or very similar symptoms; possibly the same underlying race condition in sub-level packet handling under load, just triggered by different lag sources in each report.
Logs and spark profiles from multiple reproduction attempts available on request.
Versions:
Sable: 2.0.5
Create: 6.0.10
Create Aeronautics: 1.3.0 (bundled)
Minecraft/Loader: 1.21.1, NeoForge 21.1.244
Environment: Singleplayer (integrated server)
Description:
After assembling a contraption with the Physics Assembler, the sub-level becomes completely unresponsive: no further blocks can be placed on or broken from it, and it cannot be disassembled again (right-clicking the assembler does nothing, no feedback to the player). The log repeats:
[Render thread/ERROR] [dev.ryanhcode.sable.Sable/]: Received a sub-level movement packet for a non-existent sub-level
Steps to reproduce:
Place a Physics Assembler on a sandstone block.
Assemble it.
Try to place/break blocks on the assembled structure, or disassemble it again.
Interaction silently fails; the error above appears in the log.
Correlation with tick lag:
Across multiple test sessions and logs, this error is consistently preceded (within ~1–20 seconds) by a Can't keep up! Is the server overloaded? warning, ranging from ~40 to ~520 ticks behind. This holds regardless of the underlying cause of the lag, which I've observed to vary between sessions:
A large modded world with heavy background chunk pregeneration (Chunky)
A minimal superflat redstone-testing world (no ocean biomes/mobs, no terrain generation)
A session with a single very large tick stall (474 entities teleported at once → single tick took 40001ms, caught by the ModernFix watchdog)
Ruled out as sole causes (error persists without them):
Create: Power Grid (initially suspected due to #1428) — removed, error persists
Third-party addon "Create Aeronautics: Gyroscope Stabilizers" — removed, error persists
Sable 2.0.3 → updated to 2.0.5 — error persists on both versions
Spark profiler findings (3 separate profiles across different sessions):
Sable's own code consistently accounts for only ~2–5% of total sampled server-thread time across all three profiles (528–2454 out of 10560–98268 total, depending on session). This suggests Sable itself is not the source of the lag — it appears to be a victim of general tick-time overrun from unrelated systems, which varied between sessions:
NaturalSpawner (mob spawn search — heavy with many mods adding mobs)
A third-party mod's block-collision/outline-shape mixin hooks (called extremely frequently, comparable in cost to all entity ticking combined)
In worlds with ocean mobs: Alex's Mobs' EntityCachalotWhale.aiStep → Entity.move → directly into dev.ryanhcode.sable.sublevel.entity_collision.SubLevelEntityCollision.collide (this was the only profile where a specific hot path led directly into Sable's own collision code, but it wasn't present/necessary in the other two profiles, so likely just one of several possible lag sources rather than a required trigger)
com.cobblemon...PokemonEntity / ShoulderRidingEntity
Heavy LockSupport/Unsafe (thread parking) time in one profile, suggesting possible thread contention alongside CPU-bound lag
Conclusion: The desync appears to be a race condition triggered whenever the server falls significantly behind on ticks while a sub-level exists/is being managed, independent of what specifically causes the lag. Given how many different large modpacks likely hit occasional tick lag for one reason or another, this could affect a wide range of users, not just this specific mod combination.
Related issues: #805, #402, #1428 — all describe the same or very similar symptoms; possibly the same underlying race condition in sub-level packet handling under load, just triggered by different lag sources in each report.
Logs and spark profiles from multiple reproduction attempts available on request.