fix bug where buildings could not output directly on splitters
This commit is contained in:
@@ -629,6 +629,24 @@ TEST_CASE("BeltSystem: splitter accepts new items after building pulls from fron
|
||||
REQUIRE(bs.peekItem(Port{tileSpl, Rotation::South}).has_value());
|
||||
}
|
||||
|
||||
TEST_CASE("BeltSystem: tryPutItem succeeds directly on a splitter tile", "[belt]")
|
||||
{
|
||||
// Regression: buildings outputting onto a splitter tile were silently dropped
|
||||
// because tryPutItem had no splitter case and returned false.
|
||||
BeltSystem bs(kFastBeltSpeed);
|
||||
|
||||
const QPoint tileSpl(0, 0);
|
||||
bs.placeSplitter(tileSpl, Rotation::North, Rotation::South);
|
||||
|
||||
REQUIRE(bs.tryPutItem(tileSpl, makeItem("iron_ore"), Rotation::East));
|
||||
|
||||
// Item should arrive at one of the output fronts after the splitter ticks through.
|
||||
bs.tick(); // back advances to 0.5, routes to frontA
|
||||
bs.tick(); // frontA reaches 1.0
|
||||
|
||||
REQUIRE(bs.peekItem(Port{tileSpl, Rotation::North}).has_value());
|
||||
}
|
||||
|
||||
TEST_CASE("BeltSystem: splitter alternates between two unregistered outputs (building inputs)", "[belt]")
|
||||
{
|
||||
BeltSystem bs(kFastBeltSpeed);
|
||||
|
||||
Reference in New Issue
Block a user