Open jkomoros opened 5 years ago
Also have May
methods for the MoveAllTo
on stacks
Since StackPredicate doesn't receive the intended slots, it can't tell the final order of the stack, which means that ComponentInstance only needs a single MayMoveTo to cover all of the various MoveTo methods, since they're all effectively equivalent
Also need a MayMoveMulti
that assumes that the slots are continuously provided by NextSlot
. For example, DealCountComponents
checks SlotsRemaining, so needs multiple. And then Stack.MoveAllTo
would use MayMoveMulti under the covers
Stack.MoveAllTo, and any Multi variants, are really, really, REALLY finicky to do without actually doing the moves. Simple MayMoveTo ones can be done without attempting the move, since only one thing is changing.
But MayMoveMulti (which stack.MayMoveAllTo would be a thin wrapper around) cheats: it clones the state, actually does the moves on the cloned state, and then errors if any of the planned moved would have errored.
May...
canonicallyMay...
canonically
Originally discovered while exploring #736.
Stacks have a reasonable amount of logic that defines when it's legal to move a component within them. And most moves have ot check in Legal if the component move will be legal. Right now the Legal logic in various games does a half-assed manual check for whether the move will be illegal, but if you miss something it might be rejected in
Apply
.ComponentInstance's mutator methods should all gain a
MayMoveTo
and friends version that doesn't actually do the move, it just tests if it's legal. And everyMoveTo
first just checks thatMayMoveTo
returns a nil error before doing it.And then check all examples for where they should just be using the
May...
variants in their Moves.Legal