Friday Facts #312 - Fluid mixing saga & Landfill terrain

[Dominik]

One suggestion that could solve all the weirdness with prevented actions etc. that I haven't seen mentioned in this form is the following:

The basic idea is that there could be special pipes for each type of fluid which are placed by the player. This way, there would be no issues with any of the fluid mixing madness, since different types of pipes simply don't interact. Of course, this would be quite painful in terms of having many recipes and items, and would require replacing all of the pipes if the player wishes to change the fluid. So I would suggest the following alternative based on filters instead:

Suggested behavior

• Pipes can have a fluid filter set
• Pipes with different filters do not connect. Pipes without a filter set do not connect with filtered pipes
• Pipes can only contain the fluid matching their filter
• Unfiltered pipes cannot contain any fluid
• Changing filters deletes any fluids contained in the pipes
• Changing filters will cause any compatible systems to be connected, and any incompatible system (e.g. assemblers) will be disconnected
• Filters should be configurable for individual pipes and whole pipe systems
• Filters should be configurable via the circuit network (again single pipes and whole systems)

Some notes

• Setting up a new pipe connection is only marginally more complicated than it is currently: The workflow is essentially: Place pipes -> Configure the filter of the pipe system
• To simplify building, it would probably be nice to be able to add configured entities to the toolbar (but this is probably a separate suggestion...)
• This gives a straightforward way for having adjacent pipes that do not connect (although some players might miss the challenge )
• Setting filters via the circuit network should allow for all the advanced craziness of having one pipe carrying multiple fluids, without distracting new players
• Actions are never prevented, removing any confusion like "Why can I not rotate this!?"
• There is no way to get fluid mixing, so it should be way less of a headache implementation-wise. Also, since disconnected pipe systems are a natural state of the design, there is no potential for weird edge-cases with crazy placement orders. Pipes will simply not connect/disconnect as necessary
• This approach is a bit more manual, but this seems like a worthwhile tradeoff, given the reduction in automagic behavior, both for users and developers (see last two points)
• A small tutorial on pipe filters when the player places the first pipe should solve any potential confusion for new-comers
• Changing filters via the circuit network potentially provides a way to efficiently void fluids, such as petroleum. If this makes handling the multiple outputs from oil-processing too trivial, a threshold for how empty pipes need to be could be added to switching via the circuit network

tl;dr
Force manually configurable filters for pipes, removing the need for any automagic weirdness and associated edge-cases and bugs.

This sounds like it would work, but I think that it only makes it easier for us and harder for the player. In fact I just don't see how this helps the player at all.

[mrvn]

Why is this something you can't fix? Why is that happening at all?



Lets describe what I see going on:

1) The crude oil pipe is empty but locked by the assembler.
2) Placing a ghost disconnects part of the pipe making it unlocked.
3) Replacing the ghost does two things (in this order):
- connect the empty pipe to sulfuric acid (allowed)
- re-connect the empty pipe to crude oil because the ghost was emoved (mixing fluids)

It looks to me like you only check if placing a pipe is allowed but not if any side effect, like ghosts getting removed due to it, breaks things.

I know any action involving multiple steps (remove ghost, place pipe) can have many corner cases. But there would be two simple solutions I can see here:

1) reverse the order. First remove the ghost. This makes the empty pipe a crude oil pipe again. Then placing the new pipe becomes illegal and fails. If you can't do better the ghost will be gone but no fluids mixed.

But would it be impossible to undo the ghost removal? The game already has undo functionality which records how to reverse an action. At first glance I would think an undo should never fail if no fluid has flown because both the old new state of each performed sub-action was valid. So "all" you have to do if any action causes a fluid mixing is to call undo. If undo does fail leave the user in the state with no mixed fluids.

The drawback there is that there might be corner cases where removing the ghost makes placing the new pipe impossible. But with the new pipe placed the result would have been fine (no mixed fluids). Well, to bad. Deconstruct something temporarily to work around it. Should be rather rare and not too annoying.

2) Handle this as a transaction. If the end state does not validate then you reset to the start.

This would mean you do several actions while allowing fluid mixing and at the end you do an extra check if the result still has any mixed fluids. If any mixing is going on you undo all actions and recalculate the fluid locks. This would involve tons of code because every entity with fluids would have to be changed to allow mixing fluids temporarily and have a is_mixed() method. So I won't hold my breath.


Overall I love the fluid mixing prevention despite the corner cases where it doesn't allow things. Like changing a recipe in a row of chemical plants without first removing the old recipe in all of them first. There is only one thing missing now. Pipes with no lock from fluid box filters but minimal fluid (<0.1) should be considered empty. Setting a new fluid filter or pumping in new fluid should be allowed and destroy the remaining drops of wrong fluid.

The use case I have is for LTN depots where I want to remove left over fluids from returning trains. So I have 6 depot stops with pumps all connected to one provider stop. Normaly the pipes are empty. But if a train with fluid comes in the fluid is pumped to the provider stop and some other train will pick it up there and return it to the system. So far so good. Problem now is that the pumps don't manage to pump the pipe system 100% empty. All pipes show 0.0 fluids but some drops must remain somewhere. So the pipe system remains locked to the fluid and no other fluid can be remove from returning trains anymore. Result: It only woks once.

Of course it is theoretically fixable. But practically it is not worth it. The fluid mechanics and checks are contained in some fluid related parts of code and the entities and this would require it to overflow into more generic parts of code outside it. On the other side, this is a case that would not happen accidentally in a real game and if it did, it's not a big deal.

When building, the checks are done first, while affecting as little as possible of the game state. Because changing something, like placing an entity or removing a ghost, has many side effects spanning quite far into different places in the game. Undoing it is complicated and prone to errors so it is avoided as much as possible.

So issue in this case is that when building the pipe there is no mixing, but removing the ghost creates it and batching these two operations into one action makes it hard to detect before it is too late. It could be solved, yes, but it is just not worth the clutter and new issues.

1) If you batch them together why doesn't the check detect the mixing beforehand?
2) Why batch them together? If you leave them as two actions each step is simpler and already a solved and working problem. Problem solved.

I would rather have cases where doing a remove-ghost-and-build-X does not work because the intermediate state would mix fluids than have fluids mix because you can't manage to save guard the batch operation.

As for undoing being complicated: I was talking about undoing it like pressing ctrl-z. Not waving a magical wand that rests all state to before the operation. In pseudo code this would like this:

Code: Select all

-- user clicked to build underground pipe
ghosts = find_conflicting_ghosts()
undo_position = game.undo.current_index
try:
    for ghost in ghosts:
        remove(ghost)
    place(pipe)
except FluidMixing:
    try:
        while undo_position < game.undo.current_index:
            undo()
    except UndoFailed:
        pass

[eradicator]

This sounds like it would work, but I think that it only makes it easier for us and harder for the player. In fact I just don't see how this helps the player at all.

What about the idea of simply not connecting adjacent fluid boxes if their contents don't match? That way you don't have to "cancel" any build actions.

[mrvn]

This sounds like it would work, but I think that it only makes it easier for us and harder for the player. In fact I just don't see how this helps the player at all.

What about the idea of simply not connecting adjacent fluid boxes if their contents don't match? That way you don't have to "cancel" any build actions.

Also please don't connect fluid boxes of freshly placed entities to fluid boxes of entities marked for deconstruction.

Using ctrl-x to deconstruct a factory with fluids and then place it 1 tile offset will result in fluids from the old pipes to spill into new pipes and suddenly fluids would mix all over the place, half the new pipes can't be built and those build have to be deconstructed again.

[Dominik]

1) If you batch them together why doesn't the check detect the mixing beforehand?
2) Why batch them together? If you leave them as two actions each step is simpler and already a solved and working problem. Problem solved.

I would rather have cases where doing a remove-ghost-and-build-X does not work because the intermediate state would mix fluids than have fluids mix because you can't manage to save guard the batch operation.

As for undoing being complicated: I was talking about undoing it like pressing ctrl-z. Not waving a magical wand that rests all state to before the operation. In pseudo code this would like this:

Code: Select all

-- user clicked to build underground pipe
ghosts = find_conflicting_ghosts()
undo_position = game.undo.current_index
try:
    for ghost in ghosts:
        remove(ghost)
    place(pipe)
except FluidMixing:
    try:
        while undo_position < game.undo.current_index:
            undo()
    except UndoFailed:
        pass

One part is that you can't really disconnect the actions - replacing a ghost can transfer the settings to the new entity.
Adding yet another check after the ghost is gone but before the new entity is built might actually work, in some cases. I will think about it. But not in all, especially those I mentioned where the ghost is being revived and not removed.

Undo is much more complicated than that

[mrvn]

especially those I mentioned where the ghost is being revived and not removed.

Since the ghost already counts as pipes being connected I don't get that part either. Reviving an existing ghost shouldn't change the fluid filters at all since the ghost already did.

Did you show an example of that in the FFF I missed or something drowned in all the comments?

[Pompeij]

I would realy like to see Pipes explode if they mix Like Minecraft IC2 wrong power, unforgiving -.-'

"Just" check if the setting a fluid overrides a existing pipe filter -> Yes? -> EXPLOSION *wuhuuuuu*

[Mur]

Can you please look at the cost of landfill? I think it is a bit too high currently and makes it difficult to make mega projects that need to expand over water.

[BigTrains]

I've just read through the discussion of pipes and mixing, and it seems like trying to cope with this at construction time is going to be enormously problematic both from an implementation perspective as well as for players (esp. newcomers, blueprint users, etc.) The prior design, which made rounding-error amounts of liquids frustrating, was also problematic.

Ssilk's matter/anti-matter suggestion (rather than mixing, liquids destroy each other) is a good start, but creates the problem that malformed factories could operate with an ongoing mixing mess. A cleaner variant, which could be used with our without mixing, would be:

* If all inputs, outputs, and pipe contents are for the same material, then the pipe flows and everything works normally.
* If all inputs/outputs are the same material, but the pipe contents are wrong/varying, then the 'wrong' material gradually self-destructs (e.g., drains into the ground) until it is gone, then the factory starts to work.
* If inputs/output materials mismatch, then no material can enter/exit (or flow?) in the pipe system, and the pipe is in an error state until the user fixes the problem.

The "gradual" resolution should be slow enough that a momentary pipe goof won't quickly destroy a lot of material (e.g., storage tanks) but fast enough that problems will self-resolve without the user waiting too long.

Thoughts?

[Hlebuw3k]

One suggestion: Make a "disconnected underground pipe" graphic. Like a capped pipe going toward the ground or something. Used for any case where you've placed one end but not the other. Would be useful for detecting these pipe network changed because a pipe in the middle was destroyed cases. May also be useful for belts.

A lot of people seem to be suggesting that fluid mixing be allowed but behave differently. This strikes me as just as much work; you still have to detect all the ways that a pipe can have two fluids and display it accordingly. Whether it's allowing fluid mixing by having "fluid boxes" with multiple fluids or creating a blocked pipe graphic, or some tug of war system, the game needs to detect that multiple fluids could be mixed by a given action.

That said, I favor drawing a blocked pipe, because it would allow actions like rotating an assembler pipe from facing east to west, even when there's a wrong fluid north.

I think this is a healthy and necessary endeavor in making making player error clearly visible. Great work!

Maybe i just dont understand something, but why not ONLY allow placing fluid boxes when it doesnt mix fluids? And dont allow to place them in ANY other case?

That's the intent. The problem is in detecting what actions cause fluid boxes to mix.

Like in the oil and acid example: deleting a ghost while placing a pipe actually causes two fluid connections by the same user action.

You guys did not understand me. Just dont allow placing a fluid box, unless it is a known scenario, and doesnt mix fluids

[Oktokolo]

You guys did not understand me. Just dont allow placing a fluid box, unless it is a known scenario, and doesnt mix fluids

That is the naive solution, that the dev tried first. But then Boskid showed him, that the problem of prohibiting illegal fluid system layout changes is itself fractal (whenever the dev fixed a bug, Boskid found a more obscure bug contained in the same bug class as the one that just has been fixed). It has been mentioned in this FFF.

[Hlebuw3k]

You guys did not understand me. Just dont allow placing a fluid box, unless it is a known scenario, and doesnt mix fluids

That is the naive solution, that the dev tried first. But then Boskid showed him, that the problem of prohibiting illegal fluid system layout changes is itself fractal (whenever the dev fixed a bug, Boskid found a more obscure bug contained in the same bug class as the one that just has been fixed). It has been mentioned in this FFF.

Oh, okay. Thank you for explaining it to me. As i said earlier, i didnt quite understand the full story behind fluid mixing

[HurkWurk]

@Dominik

can you just prevent underground pipes from filling until they are connected on both sides?
if one side is disconnected, have them destroy their current content?

[mrvn]

@Dominik

can you just prevent underground pipes from filling until they are connected on both sides?
if one side is disconnected, have them destroy their current content?

How would that help if the straight pipes and tanks get filled?

[HurkWurk]

@Dominik

can you just prevent underground pipes from filling until they are connected on both sides?
if one side is disconnected, have them destroy their current content?

How would that help if the straight pipes and tanks get filled?

every example i saw of evil bob breaking the current anti-mix mechanics was done by tagging a pipe with content (placing a ghost, and the ghost gets a fluid type), then turning it to connect it to something else. so the intent is to prevent that tagging and turning. IE only real in place and connected underground pipes connect. not ghosts or unconnected underground pipes.

[DaleStan]

So that means that that in this case, the two outside (built) underground pipes would be connected, even though they should have different content. Is that what you meant to do?

[HurkWurk]

So that means that that in this case, the two outside (built) underground pipes would be connected, even though they should have different content. Is that what you meant to do?

the answer is no. let me walk through what i invision.

1. you have your setup you picture. no pipes are connected to both ends of the existing underground pipes so the existing underground pipe contains nothing and is not tagged yet.

2. ghosts still count. so even if you maliciously (in the example you posted) connected those outside undergrounds to existing pipe networks, they would not carry fluid because the ghosts between them exist. in short, they are still waiting. (for the ghosts to be connected)

3. if instead, you built the outside pipes first, then let them populate (ie the pipe currently contains water for example) the minute you place the ghosts, the underground pipe is split by the ghosts, causing them to destroy their current content and go to a waiting state. while in that waiting state to go from ghost to real, you would disallow actions that would create mixing. IE dont tag ghosts, and instead check on attempted placement. if it were construction bots, it would hover over the pipe with that invalid placement warning, if it were the player, when you try to place it would give you the fluid mixing warning, because at construction time is when we would check, not at ghost creation.


to list the changes im describing as I see them (no idea if this is accurate)

1. underground pipe segments do not activate (activation meaning check for a fluid type to bind to) until 2 real underground segments are built, and have pipes/machines attached on both sides.
2. underground to ghost pipes trigger the above, causing the underground pipe to destroy any existing content when a ghost is placed between active underground pipe segments.
3. removing a ghost triggers the building test. the pipe should detect that the "new" connection would cause fluid mixing and go to a yellow exclamation warning state waiting for the players attention to remove and rebuild things, but not allowing the underground pipe to complete its connection. This means that if you mess around and create an accidental mix by overlaying ghosts, etc, that the underground segment needs new code to go to that error state instead of just passing fluid.

almost forgot.
for PvP, i would change the rules and make it so each team had its own pipe network and that they would not connect. This would obviously require code to change pipes from different teams to behave differently, and i would also tint pipes by team. (assuming base game no mods)

[Inglonias]

I appreciate your struggles with fluid mixing. Based on FFF 211, it sounds like the line between ghost entities and real ones is rather blurry sometimes.

I wish you all the best of luck.

[TheTalkingKeyboard]

I quite like the new Landfill textures.

Just noticed that while the in-view visual differences (from default land to Landfill) are vast, Landfill just looks like regular grassland on the map. Petition to create a separate color for Landfill on the map.

[DanGio]

Just noticed that while the in-view visual differences (from default land to Landfill) are vast, Landfill just looks like regular grassland on the map. Petition to create a separate color for Landfill on the map.

viewtopic.php?f=30&t=75870