[2.0.28] Copy pasting (to) a pump does not copy their minimum and maximum temperature filters

Bugs that are actually features.
LeonSkills
Inserter
Inserter
Posts: 24
Joined: Mon Feb 11, 2019 12:37 pm
Contact:

[2.0.28] Copy pasting (to) a pump does not copy their minimum and maximum temperature filters

Post by LeonSkills »

Even though it's not supported yet through the GUI to set minimum and maximum temperature, the API does allow to do so.

Code: Select all

/c game.player.selected.fluidbox.set_filter(1, {name="steam", minimum_temperature=100, maximum_temperature=200})
However when you make a blueprint of the pump, and then paste it, the min and max temperature filters are reset to the default and max temperature respectively.
Same when deleting and undoing the deletion

Similarly copy pasting the settings (shift-right click, shift-left click) loses the filters.



(Minimum and maximum temperature text as shown in the video is using my Alternative Alt Mode mod)
User avatar
boskid
Factorio Staff
Factorio Staff
Posts: 3449
Joined: Thu Dec 14, 2017 6:56 pm
Contact:

Re: [2.0.28] Copy pasting (to) a pump does not copy their minimum and maximum temperature filters

Post by boskid »

Thanks for the report however that is not a bug. Copy settings is only supposed to copy settings that the player can change and so if your script changes fluidbox min and max temperature, that is not covered by copy settings.
LeonSkills
Inserter
Inserter
Posts: 24
Joined: Mon Feb 11, 2019 12:37 pm
Contact:

Re: [2.0.28] Copy pasting (to) a pump does not copy their minimum and maximum temperature filters

Post by LeonSkills »

boskid wrote: Mon Jan 13, 2025 7:54 pm Copy settings is only supposed to copy settings that the player can change.
If that's the policy then it isn't done consistently though.
The decider combinator output constant also can't be changed by players, hardcoded to be 1. But it can be set by script. Yet that one is copy pastable and blueprintable.

Code: Select all

decider_combinator.get_control_behavior().set_output(1,{copy_count_from_input=false, constant=10})
(That one is so secret, it isn't even documented, see also documentation request for that )

Now personally I don't care about those temperature filters too much. Just thought I'd report it for consistency.

Also I'd argue copy-pasting not working isn't the main issue. Not being able to blueprint them is.
I can see how a mod might add a UI to be able to filter temperatures on pumps. And then blueprints won't be consistent.
User avatar
boskid
Factorio Staff
Factorio Staff
Posts: 3449
Joined: Thu Dec 14, 2017 6:56 pm
Contact:

Re: [2.0.28] Copy pasting (to) a pump does not copy their minimum and maximum temperature filters

Post by boskid »

LeonSkills wrote: Mon Jan 13, 2025 10:46 pm The decider combinator output constant also can't be changed by players, hardcoded to be 1.
That is.... a tiny exception because i want the output constant to be changeable by players but i still cannot find a proper way to solve the gui. Complain about it more and it will be removed.

With fluid boxes, core of the issue is that when loading a save file, there are 2 sources of data: fluid box prototype, and saved fluid box values. Usually in such cases the values from prototype take precedence and we do not allow changing them in the save file however fluid boxes happened to be treated differently and when pump filters were added, a decision was made to keep the filter value from the existing save file and not overwrite it from the prototype. Not sure if this is reliably enforced but that is the core of the issue: prototype vs saved values. When modders would change pipes or pipe-to-ground filters on the prototype they may expect those new values to be propagated to existing entities which is the "use prototype value" approach, while with pump it would be "use saved value". I am not willing to extend this logic to apply to min and max temperatures because i would have to dig through this logic to verify if those filters are applied from prototype or not when mods are changing, and if they are that would be a mod breaking change.
Post Reply

Return to “Not a bug”