Factorio Forums

Tl;dr: `LuaFluidBox::get_prototype()` is known to be broken and can access neither the full fluidbox prototype data nor the actual state of the fluidboxes for the current recipe. It would be nice to give it the full functionality.

What I want to accomplish
I want to read an entity and find the position of each fluidbox of this entity that has a valid connection to a neighbor. This way, I can delete the original entity and place pipes wherever it was connected.

What I tried so far
On Entity A, `LuaFluidBox::get_connected(x)` returns a list of LuaFluidBox objects that have a connection to Entity A's x'th fluidbox. Say A's #1 fluidbox is connected to B's #1 fluidbox, and both have multiple pipe connections. I can determine the location of the actual connection by computing the world coordinate of all the connection points using `fluidbox.get_prototype(1).pipe_connections` of both A[1] and B[1] and see which ones match up.

This breaks with assembly machines, where the fluidboxes are modified at runtime to disable or merge the pipe connections into fewer fluidboxes, so they no longer match the prototypes. There is no way to determine the location on an assembly machine of a particular pipe connection. LuaFluidBox::get_prototype() cannot retrieve all the prototypes as defined in the Data stage because its input index is erroneously limited to the number of dynamically-assigned fluidboxes, which is usually less than the number of actual prototypes.

This behavior was identified in a 2018 interface request and a 2020 "won't fix" bug report with an acknowledgement of the problem but no resolution.

Potential resolutions

1. The first intuitive solution that would be to add a method LuaFluidBox::get_pipe_connections() to return runtime-assigned pipe connections for this runtime-assigned fluidbox. I.e., when a chemical plant is set to Sulfuric Acid, get_pipe_connections(1) would return an array with two pipe_connections corresponding to the two inputs that have been merged.

2. The simplest solution may be to fix LuaFluidBox::get_prototype() so that it actually can return the complete data-stage prototype data. I.e., when a chemical plant is set to Sulfuric Acid and has two fluidboxes, get_prototype(3) and get_prototype(4) would still return the two output port definitions as they were originally defined. Then a mod could also retrieve the recipe in use, and determine for itself which prototype fluidboxes have been merged at runtime, and thus which pipe connections go to each runtime fluidbox.

3. The most comprehensive solution would be for the results of LuaFluidBox::get_connected() to include the indexes and/or location offsets of the pipe connection(s) where the two fluidboxes join.

Thank you for your consideration.

Have you seen entity.prototype.fluidbox_prototypes?

After some discussions, robot256 and I came to some conclusions:
1) there are no pipe *positions* directly available from the entity
2) Although one can use entity.fluidbox.get_connections(i) to see {an array of connected fluidboxes} connected to {this fluidbox}, this does not indicate *which* connection on the other entity to which this is connected. There is a very round-about way of seeing if the fluidbox which fluidboxes returned by the other entities connections are connected to this fluidbox (yes it it confusing, and can return multiple connections are connected if the entities have more than one connection of each respective fluidbox touching, that is, two connections or more for one pair of fluidboxes)

3) relating to Potential resolutions 1) recipes merge prototypes and the index passed to get_prototype(i) is not the same as the fluidbox index. At a minimum, get_prototype is broken in this respect, because it always will accept/return 1-N of the prototype fluidboxes, but not the ones in use that are merged (which are not a single pre-accessible thing). If it is to be "kept" then it should probably be changed to get_prototype*s*(i) which returns a table (preferably not array) where each index actually corresponds to the prototype fluidboxes. If it were an array, there are .index's in each prototype so that's not exactly an issue.

I have this same issue, and I really like the resolution of modifying get_prototype to get_prototypes which would return the table of fluidbox_protptypes that are connected to the fluidbox.