More analysis of issue:
First observation is that fixing unblocking underground is quite easy:
Code: Select all
fixUnderground(fb1, fb2) {
if(fb1.fluid == "not assigned" || fb2.fluid == "not assigned" || fb1.fluid == fb2.fluid) {
mergeFluidSystems(fb1, fb2);
mark undergrounds fb1, fb2 as not blocked
}
}
This action is however hard to revert: you loose information about which underground was blocked.
----
On the other end you have this case (as above):
- FB[acid] - FB[acid] - FB[acid]
where by removing middle fluidbox i would assume you can only go to this 3 states:
- FB[acid] - gap - FB[not assigned]
- FB[not assigned] - gap - FB[acid]
- FB[acid] - gap - FB[acid]
all of them have one thing in common: they are easy to revert. Just build middle fluidbox to get into state:
- FB[acid] - FB[acid] - FB[acid]
----
Now lets consider building underground as transaction. We want it to be atomic, so all actions are performed or none are performed.
If building underground from this issue is done like this (simplification for sake of reading):
Code: Select all
buildUnderground() {
// here is stable state A, before transaction
// building pipe-to-ground
disconnect overlapping existing underground connection;
fix blocked undergrounds // THIS action is hard to revert
put fluid box
connect it to nearby pipe-to-ground
if(fluid mixing detected) {
// fluid mixing detected.
// we need to revert all above actions to get back into state A
// but how to revert fixed undergrounds???
// we need state A, but we get state A with fluid mixing because fixed undergrounds are not reverted
} else {
// No mixing, we are done: stable state B
}
}
This fixing can be postponed (deferred) so it is performed when all actions in transaction are done.
----
For now there are clearly 2 actions that cannot be reverted:
- fixing blocked underground, because you loose information about which undergrounds were fixed
- removing pipe-to-ground which was blocked, because you loose details about which connectors were disconnected (in case of multiple undergrounds in all directions)
So preventing rotation of blocked underground is reasonable - cannot be easily reverted in case of fluid mixing. But upgrading steam engine into steam turbine should be allowed quite easily: when no underground fixing is performed, action can be reverted at any point of transaction.
Case from this bug report also should be easy to fix: when building pipe-to-ground, disconnecting existing underground would not trigger fixing blocked undergrounds, connecting new pipe-to-ground to existing pipe to ground on left would be performed as normal (it was not marked as itself being disconnected) and after confirmation of no fluid mixing with this new pipe (we know state B is reached or reachable, no more need to revert) we may perform fixing blocked undergrouns (no need to revert in this state)
