[boskid][1.1.82] Recipe pasting incorrectly assigns in-out connections based on target's currently selected recipe

[Black_Noise]

Mods used: Nullius and Editor Extensions only (+dependencies), reproducible in a new editor extensions testing scenario (see attached save with replay record).

The bug is seen here, pasting from the top chem plant onto the 2 bottom ones before (left) and after (right):


Tested both shift+left/right click and ctrl+c (which shows an incorrect preview when pasting on the left). The misbehaving input orientation is functional (factory works).

In addition, copy-pasting the affected building leads to the correct i/o orientation when pasted:

Which also applies if the offending building is deconstructed then reconstructed via ctrl+z.

[boskid]

Thanks for the report. This is obviously a bug, however a fix for this is really annoying to implement, it requires basically rewriting half of the FluidBoxManager logic used by CraftingMachines. I was already fixing exactly that issue during one of refactorings for 1.2.0 around 6 months ago and i know this exact issue is already fixed here. Today i tried to backport core of the fix from 1.2.0 to 1.1.83 however there were various desyncs showing around entity ghosts and in order to fix them i would have to bring more of the changes from 1.2.0 branch which i am not willing to do. That means the issue will not be fixed in 1.1.x but it is already fixed for 1.2.0.

Core of the issue here is related to a check a FluidBoxManager is doing in order to decide if it can "reuse" existing fluidboxes when setting a new recipe. I cannot simply make it never reuse fluidboxes because that check is important during some of the loading stages, and the logic has multiple flaws when old recipe was using custom fluid box indexes while new recipe is not using custom fluid box indexes. In this specific case new recipe is not using custom fluidbox indexes so it only requests "i want X inputs and Y outputs", it sees the amount of input and output fluidboxes matches the requested amount and so it reuses existing fluidboxes even if their compound prototypes are different.

[Black_Noise]

Thanks for the detailed reply, nice to know even small and niche bugs like this get sorted eventually.

[boskid]

Ok, i somehow managed to backport the fix from 1.2.0 back to 1.1.83 without bringing other unrelated changes with it, i was just missing one bit of knowledge i completly ignored 6 months since it was not required for me back then.