This issue was brought to my attention here, but my two mods, mini machines and micro machines (which create smaller versions of vanilla entities, such as oil refinery and chemical plant) appear to be incompatible with this one simply due to load order.

If this mod loads first, then it doesn't catch the new mini/micro machines, which are created during data-final-fixes (in order to properly copy item/entity/recipe stats, after all other mods have modified the base machines). I was able to fix the issue by forcing this mod to load afterwards (having the other two as optional dependencies to this one)

I think I know where the issue lies. When you copy entities over, do you ever reference the original fluidboxes, or do you recreate them from scratch?

I copy them over using a variation of deepcopy (the one from stdlib), and then modify the fluidboxes afterwards. I currently have it hardcoded, depending on the entity being copied (oil refinery, chemical plant, assembling machine, etc), to change the pipe_connections for each entry in their fluidbox table, since the locations have to be modified from the base entity (due to the smaller dimensions)

Specifically, here's an example from the oil refinery part of the code, where "self" is the mini variation of the base entity:

self.fluid_boxes[1].pipe_connections = {{ flow_direction="input", direction = defines.direction.south, position = {-1, 1} }}

I believe it was only the oil refinery and chemical plants which didn't work, and I know the mini tank was still working just fine (though that one uses a different kind of fluid box, so it goes through a slightly different logic). I think the mini assembler might have been working? The user only ever mentioned the mini refinery and chemplants though, and I forgot to test the mini assemblers myself (but they go through the same modifications as the other 2 entities, so I dunno...)

NPT works by modifying pipe_connections[i].connection_category. I presume your mod does it's work in data-final-fixes, right?

Ahh, I see, yeah that makes sense (and I did mention that in the first message, about data-final-fixes). So I can actually fix this from my end by copying that value, if it exists, I assume; good to know!

I presume yes, guessing here but i think my mod by default loads before yours. So either you can update the logic on your end, or i can soft require on my end so that my mod loads after. Whatever's easier for you, I think adding the soft requirement will probably be simpler in the long run

It would be faster/simpler, but it would only solve the issue for our two mods; if any other mod were to do something similar, or earlier in the loading process (before -final-fixes), then the same issue would arise for me. I think for the long term, it would be better for me to fix it from my end.

alright. i just added a bunch of compatibility hooks, but i dont think they'd help here. Let me know if there's anything i need to do on my end to get it working