Better barrelling and stacking detection

[DaleStan]

Motivation

I decided I wanted "Iron plate (unstack)" and similar recipes to be treated as special sources of Iron plate, rather than being normal (ctrl+click candidate) sources. I also wanted Nullius's "Iron ore unboxing" and "Physics research boxing" to be flagged as special recipes, without flagging the reverse recipes or the boxed items. (There are recipe chains that use boxed iron ore, but if you're planning to unbox the iron ore, you were probably better off not boxing it in the first place. Conversely, the only source of physics research is unboxing, so you shouldn't ever re-box it.)

Changes

I basically reimplemented IsBarrelingRecipe from first principles to make this all work. As expected, there are changes. Some specific examples from Pyanodon:

• The caged-xeno and boric-acid-barrel items and their corresponding recipes are no longer special, because there are multiple ways to both produce and consume the items. A packing-related item must have exactly one production recipe or exactly one consumption recipe.
• Most of the rest of the caged-animal recipes and items are now normal, since there are good reasons to cage them. The uncaged-animal recipes are still special, since the only source of a caged animal is from the caging recipe. Likewise for all (I expect) the fuel-canister items and their recipes; unbarreling is still special, but barreling and the items aren't.
• I yeeted the check for fluid variants. I couldn't figure out why Shadow added them, and removing them means sweet-syrup-barrel and its recipes are now considered special. They were previously excluded because fill-sweet-syrup-barrel accepts both 0° and 10° syrup.
• Packing and unpacking recipes no longer have to match 1:1. A packing recipe that compresses 20 items to 4 can match an unpacking recipe that decompresses 1 item to 5. (Thanks, Nullius. I hate it.)

Here's a diff between the old special objects and the new ones for IR3, Nullius, Pyanodon, and SE. I also tested Angel-Bob-MadClown, but that one changed everything except the Voiding recipes so ... (Update: DSB confuses the original code pretty badly.)
changes.patch

Questions

A few questions before I work too much harder on this:

• Is this a desirable change of definitions? Sometimes X=>Y is a packing recipe, but Y=>X is not unpacking, and vice versa.
• Is the separation of types desirable? I currently distinguish between Barrelling, Stacking, and fluid Pressurization, which means that caged-animal and Deadlock's crating recipes are described as "Stacking". If desired, I could add a fourth type for those, or I could drop the all the distinctions and stick to the generic "Packing", "Packed", and "Unpacking" I used in the comments.
• What does it get wrong? Deadlock Stacked Recipes, for example, is a complete disaster.

[shpaass]

Is this a desirable change of definitions? Is the separation of types desirable? What does it get wrong?

Since I have no opinion on the matter yet, I'll share the general vision.
In the priorities for the YAFC project, first come developers, then the target audience. In other words, we want people to like the code so they come to contribute, and after we got that aspect to a decent shape, we focus on the usability. In essence, it means that if there are no responses in a week, then it's up to you to decide the balance between these two priorities for your PR.

• From the developer perspective, the desirable code is the one that can be quickly understood by reading either the docs or the code itself. I understand that it's a lot of hard work, so it's up to you how much of documentation and polishing to include.
• From the user perspective, you might want to describe how your solution improves main use-cases. That would help to make the change noticeable by the users in release notes.

[Dorus]

What worries me here, is that this change alone is needed. The cost calculation alone should be enough to figure out that wasting resources (buildings, power, recipes) on stacking and then unstacking is pointless.

Can you better explain how this marking of packing recipes affects YaFC? Does it affect cost calculation or solving? Does it affect the UI experience? (The latter would absolutely be nice)

[shpaass]

Can you better explain how this marking of packing recipes affects YaFC?

I have no knowledge to answer that. Eventually we, as a community, need to make a document on the system-design of YaFC, but it's yet to be done. Essentially, someone needs to read through nearly the whole codebase to understand it, and then to write down the class structure and answers to the questions like the one you asked. We can start from something simple and do it bit by bit, but it needs to be done. Not that I obligate you to do it, just mentioning.

[DaleStan]

Can you better explain how this marking of packing recipes affects YaFC? Does it affect the UI experience?

This only affects the UI as far as I'm aware. For the first two, the only normal versus special matters, and only for recipes; for the third and fourth, the type of special matter.

1. Special recipes are hidden by default in NEIE. To show them, you have to click "Show more recipes" under the "Show special recipes (barreling / voiding)" label.
2. When control-clicking an item or fluid in the production table, YAFC will automatically add a consumption or production recipe, as appropriate, if there is exactly one normal recipe accessible with the current milestones.
   For example, ctrl-clicking on iron ore as an ingredient or requested product will (at least in vanilla) add a row for the Mechanics.mining.basic-solid.iron-ore recipe. This change should prevent Deadlock's Beltboxes or Crating Machine from breaking that, assuming it worked without them.
3. Special items and recipes are sorted to the end of most display lists, and objects that are the same kind of special are sorted together.
4. When hovering over a special recipe or item, the tooltip will show something like "Special: FilledBarrel".

[Dorus]

Ah i see. For the UI it indeed makes sense that these types are marked separately, for sorting and grouping etc. In code it could make more sense to group them, but if all non-normal FactorioObjectSpecialType are treated the same, we already got an easy grouping with the check target.specialType != FactorioObjectSpecialType.Normal.

I also see the problem here, when mods add an stacked recipes as input or output somewhere, in that case it indeed makes sense to only mark the second half of the circular recipe that's not used in any real production.

I do wonder if you really need to split the pack and unpack recipes, are you planning to use this separation elsewhere?

[DaleStan]

I don't have any ideas for new places where the distinction between types of special objects would matter. I could just rename "barreling" to "packing", or, with the caveat that sorting and "Special: " displays will lose some granularity, it could even be reduced to just "Normal" and "Special".

[Dorus]

Just to be clear: I think the distinction between barreling and stacking and pressure is ok, but I wasn't sure on the distinction between the 3 (item, packing and unpacking) options. I'm not against the later if there's a usecase to distinct them.

[DaleStan]

Ah. Historical reasons? The only reason I see to distinguish between Verbing vs Verbed vs Unverbing is the sorting, and often only one of the three types will be shown anyway.

[shpaass]

Rebased on fresh master

[shpaass]

Since this is a large change, I will definitely need a changelog entry from you, so I don't misinterpret the feature.

[DaleStan]

I added a changelog entry; I don't like 5-line entries, but I wasn't sure how to make it shorter and still explain what changed. I could remove the "As before, ..." line, but that seems like it could be important for answering "Why do I care?"; I don't know how well-known the sorting and ctrl-click behaviors are.