How i see all this issues i reported lastly:
-
73840 - teleport(0,0). Fluid mixing is because "block fix" was performed when pipe is first removed and then inserted without details as to which fluid systems it should connect. Connect all regular connections first then perform all undergrounds, one would be blocked. Defer fix and after all, deferred action would just skip block fix as it cannot be safely done. Implemented solution: banned action
-
73819 - merge_forces. When moving pipe-to-ground from one force to another, first connect regular connectors (not underground). Defer undergrounds for later. After all entities are moved to new force, perform all deferred fixes. At most you could end up with two pipe-to-grounds touching itself and still being blocked. Implemented solution: wont fix
-
73890 - mixing by pipe upgrade. Issue is because "block fix" is performed in between of removing old pipe and inserting new pipe. Because regular pipes are always connected (no overworld pipe block) there are fluid mixing. By deferring block fix, upgraded pipe could be put to pipes that are almost as before removing old pipe. Implemented solution: banned action
-
74116 - mixing by building underground pipe. Issue is because "block fix" is performed in between of disconnecting old underground connection and creating new pipe-to-ground that would provide new path. Deferred block fix would prevent early block fix on left. Implemented solution: banned building undergrounds to fluid system with block. Later i describe that rotation works fine. This is because of scope lock that essentialy works as "deferred block fix" - it just prevents it happening where it should not and performs block fix in the end where scope lock is removed.
-
74614 - this is just abuse of not correctly preventing build action. Should be easy to fix with deferred block fix
-
74624 - this issue may be quite hard. With deferred block fix it should work quite nicely. First case would unfortunately lead to situation when one of undergrounds cannot be merged at time of overbuilding ghost or during removing ghosts, but this would be deferred and later decided that it really cannot be fixed.
-
74657 - this issue also works on early block fix. After test rotation there is fluid mixing and so furnace must be rotated back. Unfortunately this looses some information about to which system it was connected. Two undergrounds to connect, first passes, second one is blocked and so defer action so again one underground is blocked.
-
74746 - this issue also works on same principle. I just forced block fix to happen, but in between of removing fluid boxes of single entity. Because of this there are some block fixes that are performed and they change fluid system state (most likely root fluid box or something). With deferred block fix this entity would be just removed (no major changes in fluid systems) and after that deferred action would check for possible fixes. Here there may be that in deferred block fix queue there will be some objects that point to fluid boxes that are already removed. This case would need something interesting approach.
-- edit:
I may be wrong somewhere estimating how deferred block fix would help with above issues, but all of them are because core issue - early block fix - is still there, and all implemented fixes are just ways of preventing this issue to show up (instead of just fixing it)
-- edit:
-
74624 - second case may be somehow hard because of order. If first ghost is removed then J segment connects to crude oil, then placing pipe would create fluid mixing because regular connections are never blocked. Because of this, even regular undergrounds should be connected only in deferred, even when one side is not assigned. This would however lead to solution similar to how transport belts work - they merge into larger transport lines, but during any action the instantly split (~2 tile radius from point of action) to avoid weird cases. Then there is deferred (around 120 ticks) merge that joins them again into longer transport lines.