Add `on_pre_marked_for_deconstruction`, or fire `on_marked_for_deconstruction` before any entity changes

[Wiwiweb]

In 2.0, marking an entity for deconstruction instantly pushes out the fluids it contains into the connected fluid segments, and then disconnects the entity from the fluid segments. Only after this, `on_marked_for_deconstruction` is fired.

As part of my mod Undeletable Fluids, I need to know how much fluid a storage tank contained before it was marked for deconstruction. Because of the current timing of the event, this isn't possible. A handler for `on_marked_for_deconstruction` will always show an empty storage tank.

01-31-2025, 18-29-24.png (128.31 KiB) Viewed 988 times

Thanks for considering!

[micromario]

Great suggestion, I love this mod and can't wait for it to be ported

[protocol_1903]

On the topic... why are fluids pushed out of entities that are queued for deconstruction? Why not when they are actually removed? That would fix the issue here, and also prevent exploitation by having effectively 0 volume pipes that allow fluid flow by just connecting things. And, it makes more sense anyway. Marking something for deconstruction doesn't stop it in its tracks... it just tells robots to go pick it up. Even if it did, it makes no sense to stop a fluid pipe from being a fluid pipe while it exists.

[Muche]

why are fluids pushed out of entities that are queued for deconstruction? Why not when they are actually removed?

Lets say you have a 100-tiles long pipeline with a storage tank at one end containing 10k of fluid.
Currently there is 7.2k of it in the tank, and each pipe segment has 28.8.
You deconstruct the 100 pipes.
What is your expectation of the fluid amount in the storage tank after it completes?
Currently all 10k fluid returns to the storage tank.
If you expect the fluid in individual pipes to be lost and the tank to keep having only 7.2k, then yes, you are right in expecting the fluids be flushed out upon actual pipe removal, not deconstruction.

[protocol_1903]

If you expect the fluid in individual pipes to be lost and the tank to keep having only 7.2k, then yes, you are right in expecting the fluids be flushed out upon actual pipe removal, not deconstruction.

The question was rather the decision to make the fluid movement when the entity is marked for deconstruction instead of being when it was removed. I understand it going to connected entities; I don't understand the logic of when it goes to connected entities.

[Muche]

If you expect the fluid in individual pipes to be lost and the tank to keep having only 7.2k, then yes, you are right in expecting the fluids be flushed out upon actual pipe removal, not deconstruction.

The question was rather the decision to make the fluid movement when the entity is marked for deconstruction instead of being when it was removed. I understand it going to connected entities; I don't understand the logic of when it goes to connected entities.

1. Assuming the storage tank is on east, manually mine all pipes starting from west towards east. All fluid will be flushed to the tank.
2. Start mining pipes from next to the storage tank towards west. Most of the pipes' fluid will be lost.
Thus the logic might have been to make deconstruction consistent.
The alternative is "random" final fluid amount.

[protocol_1903]

If you expect the fluid in individual pipes to be lost and the tank to keep having only 7.2k, then yes, you are right in expecting the fluids be flushed out upon actual pipe removal, not deconstruction.

The question was rather the decision to make the fluid movement when the entity is marked for deconstruction instead of being when it was removed. I understand it going to connected entities; I don't understand the logic of when it goes to connected entities.

1. Assuming the storage tank is on east, manually mine all pipes starting from west towards east. All fluid will be flushed to the tank.
2. Start mining pipes from next to the storage tank towards west. Most of the pipes' fluid will be lost.
Thus the logic might have been to make deconstruction consistent.
The alternative is "random" final fluid amount.

Not really. It makes sense. Its the same way it worked in 1.1. The order bots pick things up matters. If it really matters to the player, then they will move it all into the tank. More likely than not, the player doesn't care so will just mine it in any order.

[curiosity]

1. Assuming the storage tank is on east, manually mine all pipes starting from west towards east. All fluid will be flushed to the tank.
2. Start mining pipes from next to the storage tank towards west. Most of the pipes' fluid will be lost.
Thus the logic might have been to make deconstruction consistent.
The alternative is "random" final fluid amount.

The fluid has nowhere to go and is therefore lost. It makes sense to me. But in this case there is no deconstruction happening, the player just mines the pipes.

[protocol_1903]

Exactly. There's nothing random about it, it just completely depends on the order in which the entities are mined.

[protocol_1903]

A few discussion thoughts from discord:

> Imagine playing ultracube and trying to reassemble the ghost cube with fluids but oops you accidentally deconstructed something and lost 15 fluid so now your game is softlocked.

> [Fluids being deleted on marked for deconstruction] not important for vanilla since even space age fluids are cheap as dirt, but imagine losing some of the end game fluids in pY or SE

It's a gameplay affecting decision to have fluids move when an entity is marked for deconstruction. Players could lose potentially tens of hours of production in a single click.

[curiosity]

A few discussion thoughts from discord:

> Imagine playing ultracube and trying to reassemble the ghost cube with fluids but oops you accidentally deconstructed something and lost 15 fluid so now your game is softlocked.

> [Fluids being deleted on marked for deconstruction] not important for vanilla since even space age fluids are cheap as dirt, but imagine losing some of the end game fluids in pY or SE

It's a gameplay affecting decision to have fluids move when an entity is marked for deconstruction. Players could lose potentially tens of hours of production in a single click.

That is utterly irrelevant. If the fluid is valuable, you will not deconstruct pipes. You'll mine them manually one by one, in the most predictable and controllable way. The deconstruction behavior does not factor into this in any way.

[protocol_1903]

That is utterly irrelevant. If the fluid is valuable, you will not deconstruct pipes. You'll mine them manually one by one, in the most predictable and controllable way. The deconstruction behavior does not factor into this in any way.

So then why does it happen when marked for deconstruction? You can accidentally right click on a tank while in map view, or mark a few too many entities for deconstruction. Flushing entities when marked for deconstruction makes less sense than doing it when actually deconstructed. I see no reason as to why it would be done in the current order.

[torne]

So then why does it happen when marked for deconstruction? You can accidentally right click on a tank while in map view, or mark a few too many entities for deconstruction. Flushing entities when marked for deconstruction makes less sense than doing it when actually deconstructed. I see no reason as to why it would be done in the current order.

Imagine you have two tanks separated by several pipes, and you mark all the pipes (but not the tanks) for deconstruction at once. The current behavior means that all of the fluid is immediately pushed into the tanks if there is room for it: no fluid is lost unless there is absolutely nowhere for it to go. If the fluid was only pushed out when each piece of pipe was actually deconstructed, it would be possible for the bots to remove two pieces of pipe near each end and entirely disconnect all the remaining pipes in the middle, and then when those pipes were removed the fluid in them is guaranteed to be lost.

The current system is trying to preserve as much fluid as possible in the case of the player issuing deconstruction orders that cover multiple entities which the bots will then remove in an arbitrary order. You are correct that if you then cancel some/all of the deconstruction orders before the entities are removed, it's possible for fluid to be lost if there wasn't room to push it elsewhere, but waiting until each entity is actually removed makes it quite likely that you will lose fluid unnecessarily even though there may have been plenty of room to keep it.

To do better it seems like the game would have to carefully control the exact order that bots deconstructed individual entities, which is something the developers have rejected repeatedly in other contexts for performance reasons.

[protocol_1903]

The current behavior means that all of the fluid is immediately pushed into the tanks if there is room for it: no fluid is lost unless there is absolutely nowhere for it to go. If the fluid was only pushed out when each piece of pipe was actually deconstructed, it would be possible for the bots to remove two pieces of pipe near each end and entirely disconnect all the remaining pipes in the middle, and then when those pipes were removed the fluid in them is guaranteed to be lost.

You still lose excess fluid that can't go into the tanks. It gets deleted, even if you cancel the deconstruction. If you mark the whole thing for deconstruction by accident you lose it all. Why does it have to get deleted in the first place?

The current system is trying to preserve as much fluid as possible in the case of the player issuing deconstruction orders that cover multiple entities which the bots will then remove in an arbitrary order. You are correct that if you then cancel some/all of the deconstruction orders before the entities are removed, it's possible for fluid to be lost if there wasn't room to push it elsewhere, but waiting until each entity is actually removed makes it quite likely that you will lose fluid unnecessarily even though there may have been plenty of room to keep it.

You can still lose fluid in either scenario. If the player really cares then they would do it manually and not mark it for deconstruction for bots to take care of it. Forcing this, even if the player doesn't care if they lose fluid, doesn't make sense

[curiosity]

So then why does it happen when marked for deconstruction? You can accidentally right click on a tank while in map view, or mark a few too many entities for deconstruction. Flushing entities when marked for deconstruction makes less sense than doing it when actually deconstructed. I see no reason as to why it would be done in the current order.

That's what I'm saying: the fluid saving can't be the explanation for this new behavior. Or if it really is, then the change was misguided.

Imagine you have two tanks separated by several pipes, and you mark all the pipes (but not the tanks) for deconstruction at once. The current behavior means that all of the fluid is immediately pushed into the tanks if there is room for it: no fluid is lost unless there is absolutely nowhere for it to go. If the fluid was only pushed out when each piece of pipe was actually deconstructed, it would be possible for the bots to remove two pieces of pipe near each end and entirely disconnect all the remaining pipes in the middle, and then when those pipes were removed the fluid in them is guaranteed to be lost.

The current system is trying to preserve as much fluid as possible in the case of the player issuing deconstruction orders that cover multiple entities which the bots will then remove in an arbitrary order. You are correct that if you then cancel some/all of the deconstruction orders before the entities are removed, it's possible for fluid to be lost if there wasn't room to push it elsewhere, but waiting until each entity is actually removed makes it quite likely that you will lose fluid unnecessarily even though there may have been plenty of room to keep it.

To do better it seems like the game would have to carefully control the exact order that bots deconstructed individual entities, which is something the developers have rejected repeatedly in other contexts for performance reasons.

It's not the game's job, in my opinion, to be concerned with preserving fluid on deconstruction.

[torne]

There's only a few meaningfully different scenarios here:

1. The fluid system has enough spare space to hold all the fluid in the marked-for-deconstruction entities. With the current system no fluid is lost in this case, regardless of whether the deconstruction is cancelled or goes ahead. With the alternative you propose, fluid can be lost if the deconstruction goes ahead, depending on the order the bots happen to remove the entities.

2. The fluid system is too full to contain all the fluid in the marked-for-deconstruction entities, and the deconstruction goes ahead as planned. Fluid is lost in this case no matter what system you use, but with the current system the *minimum* possible amount of fluid is lost: the rest of the system will be filled to maximum before anything is lost. With the alternative you propose, it's possible for *additional* fluid to be lost beyond the minimum, depending on the removal order.

3. The fluid system is too full to contain all the fluid in the marked-for-deconstruction entities, and the deconstruction is cancelled before the entities are actually removed. With the current system this will indeed lose the excess fluid, and with the alternative you propose no fluid would be lost.

You seem to be much more concerned with the case where the deconstruction is cancelled, and if that's your primary concern then yes, the current system isn't ideal. I'm more concerned about the case where the deconstruction goes ahead as planned, which the current system already handles just fine and your alternative would be worse.

If you are in a modded game where a fluid is particularly precious, then I would usually expect that it's also being produced slowly and there's usually going to be spare space in tanks to avoid large amounts of fluid loss from an accidental deconstruction. I've played a number of overhaul mods where this is the case and I haven't ever felt the need to avoid using the deconstruction planner on pipes/tanks or unintentionally lost any significant amount of fluid by doing so, but maybe I just didn't get unlucky.

It's entirely possible that some mod I haven't played (or not played far enough) has fluids that are produced in very large volumes compared to the size of pipes/tanks but are still very valuable on a per unit basis, and this would be much more of a concern in that case, but if you have large volume of a very precious fluid then you need to be very careful about deconstructing parts of that fluid system even if you *don't* make a mistake, and as you mentioned it'd be better to always mine the entities one at a time manually.

I would guess that the developers are also more concerned about the case where deconstruction is intentional, and that even though the fluids in the vanilla game aren't particularly precious, they likely wanted to avoid cases like "two roughly half-full tanks connected by a pipe, deconstruct one tank and the pipes, end up with a single roughly half-full tank, instead of a single roughly full tank", because that seems likely to result in new players being confused/annoyed/reporting bugs, especially if they do not yet realise that half a tank of light oil (or whatever) is not really worth worrying about at all.

[curiosity]

I would guess that the developers are also more concerned about the case where deconstruction is intentional, and that even though the fluids in the vanilla game aren't particularly precious, they likely wanted to avoid cases like "two roughly half-full tanks connected by a pipe, deconstruct one tank and the pipes, end up with a single roughly half-full tank, instead of a single roughly full tank", because that seems likely to result in new players being confused/annoyed/reporting bugs, especially if they do not yet realise that half a tank of light oil (or whatever) is not really worth worrying about at all.

The whole fluid expelling thing is relatively new. If it really is done with the situation you describe in mind, then the devs went down a slippery slope. The mechanics will grow more and more overcomplicated to the point of unpredictability.

Besides, with the 2.0 fluid system rework it would never happen anyway. The remaining fluid system will be able to accept half a tank of fluid regardless of pipe capacity.

[torne]

It would still happen if a pipe in between happened to get removed first; once that happens there are two separate fluid systems and it doesn't matter how the fluid flow works. Pushing the fluid out when marked for deconstruction avoids that.

[Rseding91]

I’m not really sure if it was answered but the fluid is pushed out on deconstruction being ordered because pipes are disconnected when marked for deconstruction so fluid doesn’t keep flowing through things to be deconstructed. Once disconnected they can’t push anything anywhere.

[Wiwiweb]

That's a great design discussion, but I don't want the heat to get my modding interface request overlooked or deleted