[2.0.10] Fluidbox temperature
Posted: Thu Oct 24, 2024 5:12 pm
Currently fluid boxes have a minimum and maximum temperature, but only when filtered to allow a single fluid. Now that fluids have been completely reimplemented, is this constraint on these parameters still necessary for the new implementation? Could the fluid segment inherit the highest minimum and lowest maximum of any pipe used within it, similar to extent size, and then fluid can't flow into the segment outside of that temperature range? Or can't connect to the pipe segment if it's a completely non-overlapping temperature range. They currently default to specific temperatures, but if this is changed they could just default to nil when filter isn't set, and the temperature checks skipped unless someone has set them to non-nil.
This seems very relevant now that we have molten metal, cryogenics, etc, on planets with vastly different climates. It would be nice for mods to be able to have special pipes that can handle these extremes. While a single pipe type makes sense in vanilla, mods trying for more complexity might dislike treating molten metal as a completely normal fluid.
Currently Exotic Industries supports a similar constraint that you need special pipes for certain fluids. However it does so in a way that adds a lot of overhead. It maintains a list of all fluid entities and cycles through one per tick checking if it should be destroyed. I haven't measured how overhead this adds on a base with lots of fluids and pipes, but it seems like a lot compared to the alternative of trying to generalize the existing fields in fluidbox.
This seems very relevant now that we have molten metal, cryogenics, etc, on planets with vastly different climates. It would be nice for mods to be able to have special pipes that can handle these extremes. While a single pipe type makes sense in vanilla, mods trying for more complexity might dislike treating molten metal as a completely normal fluid.
Currently Exotic Industries supports a similar constraint that you need special pipes for certain fluids. However it does so in a way that adds a lot of overhead. It maintains a list of all fluid entities and cycles through one per tick checking if it should be destroyed. I haven't measured how overhead this adds on a base with lots of fluids and pipes, but it seems like a lot compared to the alternative of trying to generalize the existing fields in fluidbox.