Cataclysm-dda: Crafts can be started with missing components if a single component satisfies multiple requirements

[Ravor9933]

Describe the bug

Certain recipes constantly "missing components" and continuously prompt for more. No matter how many times I accept the dialogue, it will keep on asking for the missing components

Update: I have tried crafting a clay crucible as well, and the same bug appears, however this time it's constantly asking for water. Since this time I was crafting it near a river and had access to a practically unlimited amount of the asked for ingredient, I can just hold Y and spam it. This results in crafting percentage actually proceeding when I hit N again. It then consumes an amount of time and percentage advances.

Steps To Reproduce

Steps to reproduce the behavior:

1. Try crafting certain recipies, know items so far are the Can Forge asking for clay and the Bow Scope which asked for high quality lenses

Expected behavior

To start the crafting for the item with the available ingredients

Screenshots

Note the number of used ingredients

Versions and configuration

- OS: Windows
- OS Version: 10.0 1903

• Game Version: 0.D-5491-g54a24dd [64-bit]
• Graphics Version: Tiles
• Mods loaded: [
  Dark Days Ahead [dda],
  Disable NPC Needs [no_npc_food],
  C.R.I.T Expansion Mod [crt_expansion],
  Garden Pots [growable-pots],
  Makeshift Items Mod [makeshift],
  More Survival Tools [More_Survival_Tools],
  Mythological Replicas [nw_pack],
  Packaging [Packaging],
  Modular Turrets [modular_turrets],
  Salvaged Robots [Salvaged_Robots],
  Draco's Dog Mod [DracoDogMod],
  Cataclysm++ [Cata++],
  Crazy Cataclysm [crazy_cataclysm],
  Fast Healing [fast_healing],
  Mining Mod [Mining_Mod],
  Mutant NPCs [mutant_npcs],
  Folding Parts pack [deoxymod],
  Vehicle Additions Pack [blazemod],
  Tanks and Other Vehicles [Tanks],
  Jury-Rigged Robots [jury_rigged_robots],
  No Acid Zombies [No_Acid_Zombies],
  Bionic Slots [cbm_slots],
  Classes and Scenarios Mod [more_classes_scenarios],
  Classic Roguelike Classes [RL_Classes],
  No Filthy Clothing [no_filthy_clothing],
  Simplified Nutrition [novitamins],
  Sleep Deprivation [sleepdeprivation],
  StatsThroughSkills [StatsThroughSkills]

Additional context

Using an integrated toolset and kitchen unit hotplate as the crafting tools

[glenmack]

I've found picking up the components is a workaround while the issue is being solved.

[TechyBen]

Moving also helps. I'm not sure if items under the character are not registering, or if it's items slightly out of reach.

[Ivan-Shestakov]

Yep, seen this happen with survivor telescope, would add more and more lenses, without actually completing. I was crafting near my base vehicle with installed workbench.

[floodie24]

i think it is about ingredients range check, it pass the check for having the ingredient near enough for crafting, but it checks for a different range when the crafting begins. or something else affects the ingredient available when the crafting starts. (line of sight or something similar)

in this case i try to cook water placed outside the wall. It shows as a valid craft to make but gives you missing component once the crafting starts

after opening the window you can craft with no error

[Ravor9933]

I think Floodie has it, because I was crafting with ingredients stashed in my vehicle using equipment in it

[Denniz-Dal]

I am seeing this too with the survivor telescope. It takes the required components then asks for another lens.

[Edgar-cy-Lee]

Tested with version 9302.
Hopefully this will clear what floodie24 stated.
It is line of sight. To be exact:
Crafting menu displays all ingredients in range regardless of sight
Actual act of crafting requires ingredients to be in range and in sight.

Before testing, let's confirm that we do not have ingredient in the first place.

Testing character location:

I will also show that I will be testing with this recipe of Sheet Metal:

After those screenshot, I have dropped 144 small metal sheet in tile marked red:

Crafting window After putting small sheet metal in blind spot:

Crafting in this state will cause an "component missing":

P.S: It has to be your natural sight. Any sight gained from clairvoyance artifact, inbound mirrors or cameras from your deathmobile does not count and will cause this same error.

How to reproduce this issue:
Put crafting component outside your natural sight(sight that isn't gained from clairvoyance artifact, inbound mirrors or cameras) but within 4 tiles or so.
Start crafting.

[pjf]

Just linking in #32614 as a possible instance of this bug.

[pjf]

I think there's actually two bugs in here. The one where an error is caused by ingredients that are nearby-but-not-visible should be fixed as of #32693.

The bug where high quality lenses cause an error with the survivor telescope (and possibly other items) appears to be ongoing (I hit it yesterday).

[ghost]

Perhaps it is caused by duplicate 'high-quality lens' ingredient? I get this prompt while trying to craft using 1 lens and 1 small lens:

I think the game should not prompt here, as the normal lens are used as another mandatory ingredient.
Crafting using 'lens + small lens' works as expected, but 'lens + lens' (after spawning additional lens) gives this prompt:

While consuming 2 normal-sized lens. All ingredients were in my inventory.
The 'bow scope' mentioned in the post has the 'small lens + lens' vs 'lens + lens' recipe options as well, don't know about can forge

• OS: Windows
  
  
  
  • OS Version: 10.0 1809
  
  
• Game Version: 0.D-6277-g87276a7 [64-bit]
• Graphics Version: Tiles
• Mods loaded: [
  Dark Days Ahead [dda],
  Disable NPC Needs [no_npc_food],
  Makeshift Items Mod [makeshift],
  More Survival Tools [More_Survival_Tools],
  C.R.I.T Expansion Mod [crt_expansion]
  ]

[ghost]

Given the latest updates, I cannot reproduce on latest master, with crafting a survivor telescope with the components as 2 high-quality lenses, it crafts fine.

[ifreund]

I can confirm this, to be more explicit the steps to reproduce are as follows:

1. spawn exactly 1 high quality lens and 1 small high quality lens
2. spawn the rest of the ingredients
3. initiate the craft
4. when prompted which lens to use for the high quality or small high quality requirement choose to use the normal high quality lens, not the small one.
5. the craft then fails as described as there is only 1 high quality lens available.

The bug here is that the option is given to use the single high quality lens for two separate requirements resulting in a broken in progress craft. I'm not sure exactly what a proper fix would look like, I don't see a way to do it cleanly without some significant restructuring of the current code.

One simpler way to patch over this issue would be to detect and patch recipes that have the potential to trigger this issue, but that is fragile and undesirable in the long term.

[jbytheway]

Solving this in general requires using a SAT solver (or actually probably an ILP solver), and I'm pretty sure we don't want to have that embedded in the game (especially not before 0.E).

For the specific situation of the survivor telescope, I think it is solvable. I'd suggest the following approach:

• Introduce a finalization step that looks for recipes with requirements where one requirement is a subset of another, and ensures that the more specific requirement (in this case the high-quality lens) is first.
• When searching for items to satisfy requirements track a std::unordered_map<item*, int> that counts the number of charges already allocated for each item in the available inventory, and don't allow reuse.
• When only one item is available to satisfy a requirement, count that in the map.

That's not too bad, but it fails in a situation which is only slightly more complex. For example, if the requirements were:

1 high-quality lens
2 high-quality lens

and you have 2 high-quality lenses on hand, then this algorithm wouldn't catch that case.

So, I'm leaning more towards @ifreund's other solution of detecting and forbidding problematic recipes. The issue can always be worked around by introducing a new intermediate item. For example, add a "survivor eyepiece" item which uses one of either lens and a plastic chunk.

Alternatively (or additionally), as a workaround, I propose making it possible to disassemble an in-progress craft with 0% progress, so that players don't end up unexpectedly losing their components when they're in this situation. That seems like a reasonable short-term fix to make this not a 0.E blocker.

[jbytheway]

After further thought, I think there might be a feasible way to solve this in general. It's bad because it's super-exponentially slow O(2^n(n-1)) in the worst case, but probably wouldn't be too bad in practice. It is effectively implementing our own SAT solver (a really terrible one). The basic idea is to detect recipes with overlapping requirements and refactor them into a set of alternative requirements, each of which is internally non-overlapping, then try each of these in turn.

So, for example, the survivor telescope recipe would internally be changed to have two sets of requirements:

2 high-quality lens
OR
1 high-quality lens AND 1 small high-quality lens

Implementation-wise, this would manifest as recipe having a vector of requirement_data objects, rather than just one.

The vegetable soup recipe (as discussed in #32554) is a bit more complex. Currently it looks like (simplifying somewhat):

eggs OR wild veggies
AND
other veggies OR wild veggies

this would be transformed into

eggs AND other veggies
OR
eggs AND wild veggies
OR
wild veggies AND other veggies
OR
2 wild veggies

With more overlapping requirements or more items in the overlap the number of alternatives rises fast, but probably we can detect any recipe that gets too ridiculous and just forbid it.

It's unclear to me how this would be best to display to the player in the crafting GUI. Easiest solution is just to mark it uncraftable, but don't change the current component display, which will be potentially confusing, because all the requirements will be green. I guess we could just add a extra message along the lines of "this cannot be crafted because the same item is required for multiple components".

The implementation of the requirements refactoring algorithm will be nasty, but it will be localized to one spot. I think the changes elsewhere would be minimal.

[ifreund]

I think that your second solution using the vector of requirement_data should work perfectly well for our use case. It's certainly a lot more straightforward that anything I came up with while trying to brainstorm an effective way to solve this in general.

A simple message stating why the recipe can't be crafted would IMO be totally fine for the UI. Maybe it's not really needed though as we do display that you have, for example, 1/1 rags for both requirements. It seems fairly clear to me that you shouldn't be able to use the same rag to fufil both requirements, but at the same time I feel like @esotericist would tell me that's bad UI.

[jbytheway]

Agreed. That solution has been growing on me since I suggested it. I've now implemented the requirements refactoring algorithm, which is hopefully the hard part. I'll now try integrating it with the crafting code.

I have realised one more problem with this solution, however: it will make it difficult to give players full control over the ingredients they use. When in one of these corner cases we will have to pick one of the feasible requirement_data alternatives arbitrarily, and use that for component selection. This will make some decision for the player.

For example, in particular for the survivor telescope, when you have sufficient lenses for either recipe, it will end up just using one alternative or the other without offering a choice.

The only solution I can think of is, when multiple requirement_data are feasible, to first offer a choice between them. But this choice will be a bit overwhelming, since each requirement_data is potentially a huge list (such as it is for woods soup, which is so long it scrolls on my default window size). I suppose it could be simplified by removing items not in the inventory, but that's additional complexity...

[ifreund]

Ok, here's another slightly different approach to consider that I believe solves the player choice side of things. Instead of storing the requirement_data objects in a vector we could build a sort of decision tree based on what components are available and the (arbitrary) order they are listed in the recipe json.

Perhaps this is best explained with an example using the same vegetable soup recipe from above:

              ___ req1 ___
             /            \
           eggs        wild veggies
           /                \
       _ req2 _           _ req2 _
      /        \         /        \ 
    wild      other    wild     other
   veggies   veggies  veggies  veggies
   /             \     /            \
leaf1         leaf2   leaf3        leaf4

leaf1: requirement_data with eggs and wild veggies
leaf2: requirement_data with eggs and other veggies
leaf3: etc.

This is effectively a way of organizing the requirement_data objects created by your method in a way that we can then use to give the player choice exactly when there are multiple options possible.

Once it has been determined which requirement_datas can be fulfilled we can prune the tree by removing those leaves and corresponding decision nodes. Then, we offer a UI prompt for each remaining decision node and use the requirement_data at the leaf we reach

I'm not quite sure what an implementation of this would look like yet, but as far as I can tell it should theoretically solve the issue regarding player choice.