[0.18.32] LuaFluidBox::get_locked_fluid always returns nil
[0.18.32] LuaFluidBox::get_locked_fluid always returns nil
LuaFluidBox::get_locked_fluid always returns nil, even when there is fluid inside.
- Attachments
-
- locked_fluid_nil.png (592.85 KiB) Viewed 1200 times
Re: [0.18.32] LuaFluidBox::get_locked_fluid always returns nil
Thanks for the report however i am not considering this to be a bug.
Re: [0.18.32] LuaFluidBox::get_locked_fluid always returns nil
Not entirely sure how this is "not a bug", since https://lua-api.factorio.com/latest/Lua ... cked_fluid states the following:
In my example, in 0.18.31 it correctly returned "water" - now it always returns nil, even in cases the fluid box is locked to a fluid (the most obvious case being the fluidbox containing the fluid). Is this API being phased out? Since it changed without any notice on 0.18.32 and broke mods like https://mods.factorio.com/mod/pipelayerget_locked_fluid(index) → string
Returns the fluid the fluidbox is locked onto Returns 'nil' for no lock
Parameters
index :: uint
Re: [0.18.32] LuaFluidBox::get_locked_fluid always returns nil
Changelog for 0.18.32:
In 0.18.32 as there was simple fluid mixing implemented, there is no concept of fluid system filter (so empty pipes in fluid system do not draw system filter icon) computed for whole fluid system since we allow in some form multiple fluids in same fluid system to let player flush that system to fix it. Since there is no fluid system filter, there is now simpler routine for checking if building given pipe should be allowed, it does not need pipes with fluid content to have filters on them because it checks every pipe in fluid system if it has compatible fluid content or filter.
If you want to know what fluid is within pipe, there is array operator to read fluid box content.
Not a bug.
In 0.18.31, fluid volume had to set filter because fluid system's system filter was taken as filter from all fluid boxes - if in single fluid system there were 2 different filters, it would create consistency crash to detect if mixing happened. It was also used as condition for a fluid mixing check: if 2 fluid systems had different system filter, they were tried to be prevented from connecting.FactorioBot wrote: Tue Jun 16, 2020 9:31 am Features
- Changed fluid mixing to a simpler version that only checks when manually building most things.
- Added a flush fluids button to the pipe, underground pipe, and storage tank entity GUIs.
In 0.18.32 as there was simple fluid mixing implemented, there is no concept of fluid system filter (so empty pipes in fluid system do not draw system filter icon) computed for whole fluid system since we allow in some form multiple fluids in same fluid system to let player flush that system to fix it. Since there is no fluid system filter, there is now simpler routine for checking if building given pipe should be allowed, it does not need pipes with fluid content to have filters on them because it checks every pipe in fluid system if it has compatible fluid content or filter.
If you want to know what fluid is within pipe, there is array operator to read fluid box content.
Not a bug.
Re: [0.18.32] LuaFluidBox::get_locked_fluid always returns nil
Thank you for the clarification - I used filled pipes as an example because I thought they'd be the most obvious display of a bug.
LuaFluidBox::get_locked_fluid always yields null, also for empty yet filtered pipes - i.e. empty pipes I cant connect because of the fluid thats supposed to be in there, even though there never actually was any fluid in there.
See the attached example,the two pipes linked to different fluid outputs of a refinery are still filtered like they were in 0.18.31 (although you're right, they dont show an icon anymore as to which fluid is expected), I just cant ask the game which fluid should be in there and thus why they wont connect. Querying the fluid box content itself doesnt work either because of course they're empty and nil:
(command outputs were done while selecting the bottom most left and right pipe)
Your statement still makes me think it is a bug if empty pipes are supposed to be filtered?boskid wrote: Sun Jun 21, 2020 4:05 pm Since there is no fluid system filter, there is now simpler routine for checking if building given pipe should be allowed, it does not need pipes with fluid content to have filters on them because it checks every pipe in fluid system if it has compatible fluid content or filter.
LuaFluidBox::get_locked_fluid always yields null, also for empty yet filtered pipes - i.e. empty pipes I cant connect because of the fluid thats supposed to be in there, even though there never actually was any fluid in there.
See the attached example,the two pipes linked to different fluid outputs of a refinery are still filtered like they were in 0.18.31 (although you're right, they dont show an icon anymore as to which fluid is expected), I just cant ask the game which fluid should be in there and thus why they wont connect. Querying the fluid box content itself doesnt work either because of course they're empty and nil:
(command outputs were done while selecting the bottom most left and right pipe)
Re: [0.18.32] LuaFluidBox::get_locked_fluid always returns nil
Fluid filter means fluid box is forced to only take that fluid type into it. In this case, if you do get_locked_fluid over oil refinery you will get filters since it does not require any fluid volume to be present since it takes filters from a recipe. If you manually(by command) set filter on a pipe, other fluids will not flow into it and get_locked_fluid will return value you set. By script you are always able to place pipe so in most cases scripts are not affected by not knowing what fluid content is allowed in which pipe. Only player pipe building and couple of other entities are checked for fluid mixing.
Only things near fluid filters that i looked at that could be fixed is that get_locked_fluid will return fluid type based on fluid content in Fluid Wagon (in that sense it is a little inconsistent with a pipe behavior), and pump connected to take fluid out of Fluid Wagon will ignore its fluid filter (if set) and so may have different content than its filter.
Only things near fluid filters that i looked at that could be fixed is that get_locked_fluid will return fluid type based on fluid content in Fluid Wagon (in that sense it is a little inconsistent with a pipe behavior), and pump connected to take fluid out of Fluid Wagon will ignore its fluid filter (if set) and so may have different content than its filter.