fix issue where items clustered at the end of belt tiles

This commit is contained in:
2026-04-23 22:03:02 +02:00
parent ea30d2ab7b
commit eba8caac31
2 changed files with 34 additions and 2 deletions

View File

@@ -247,9 +247,9 @@ void BeltSystem::advanceProgress()
}
}
if (bt.back->progress > 1.0)
if (bt.back->progress > 0.5)
{
bt.back->progress = 1.0;
bt.back->progress = 0.5;
}
}
}

View File

@@ -226,6 +226,38 @@ TEST_CASE("BeltSystem: item stays blocked when next tile is full", "[belt]")
REQUIRE(bs.tryTakeItem(eastPort(tileA)).has_value());
}
TEST_CASE("BeltSystem: belt back slot is capped at progress 0.5", "[belt]")
{
// Use progress/tick = 0.4 so the cap is observable: without it, back would
// advance to 0.8 while front is stuck at 1.0, and then need only 1 more tick
// after being promoted. With the cap it stays at 0.5 and needs 2 more ticks.
const double medBeltSpeed = 0.4 * static_cast<double>(kTickRateHz);
BeltSystem bs(medBeltSpeed);
const QPoint tile(0, 0);
bs.placeBelt(tile, Rotation::East);
// Advance front item to the output edge; it stays there (no next tile).
bs.tryPutItem(tile, makeItem("front_item"));
bs.tick(); // front: 0.4
bs.tick(); // front: 0.8
bs.tick(); // front: 1.0 (capped, stuck)
// Place back item; front is at 1.0 and not blocking (back < 1.0).
bs.tryPutItem(tile, makeItem("back_item"));
bs.tick(); // back: 0.4
bs.tick(); // back would reach 0.8 — must be capped at 0.5
// Remove front; back (now promoted to front) must be at 0.5, not 0.8.
REQUIRE(bs.tryTakeItem(eastPort(tile)).has_value());
// At 0.4/tick, 0.5 → 0.9 after one tick — not at 1.0 yet.
bs.tick();
REQUIRE_FALSE(bs.tryTakeItem(eastPort(tile)).has_value());
// 0.9 → 1.0 after a second tick — now available.
bs.tick();
REQUIRE(bs.tryTakeItem(eastPort(tile)).has_value());
}
// ---------------------------------------------------------------------------
// clearTiles
// ---------------------------------------------------------------------------