Acquire graph

[Brambor]

Is your feature request related to a problem? Please describe.

I am frustrated when I need an item for crafting and I don't know that I could just disassemble something. Or smash something. Or craft it.

I am also frustrated when I needlessly spend many in-game hours crafting something I should have just disassembled a random TV that is lying around and have it in 1h5m rather than 8 hours.

Solution you would like.

Level 1: first implementation
Graph of obtainment. (wiki for item obtainment)
Input is the desired item (or furniture if we don't want just items). It will show all* (see alternatives) ways of obtaining that item, namely:

1. crafting recipes
2. disassembly recipes
3. Cut up things
4. things I can smash (a big rock -> small rocks)
5. items I can find (described by spawn pools)
6. construction (constructing furniture)
7. animals laying eggs or producing other produce
8. butchery
9. harvesting crops (need to know about planting crops)
10. cutting trees
11. ? fishing - I never did it in CDDA, is it just kill and butcher with extra steps?
12. ? mining - is it smashing?
13. ??? what did I forget?

Level 2: recursion
Show multiple steps: find item X OR cut Y to get item X, then deconstruct item X.
Yes, this is going to be slow, but it is not a background task that needs to be run constantly but rather only whenever the player asks, like searching in the crafting menu. It provides value despite heavy CPU usage.

GUI:
Entry point (after we select the desired item) is like Crafting-GUI, where tabs are ways of obtainment (listed above, e.g. crafting, disassembly, butchery), it lists "recipes".
Every "recipe" in that GUI has requirements. If the requirement is an item, we should be able to easily show the obtainment graph for that item. It notably has a time requirement (mainly used for crafting & disassembly).

Level 3: consider surroundings
Like in crafting menu, which shows which recipes can be crafted, highlight obtainment paths that are possible. Additional input is the surroundings the player can see.

Example: Namely cut up curtains in a room with windows.

Additional features:
Save a graph with potentially hidden branches (so that they don't clutter). This would serve as a TODO list for the player - get 7 rags and 6 plastic chunks, then I can craft all the way to this step, obtain a hammer and I can make the survival gear.

I would very much like to have a menu, where I can explore the items in-game by expanding each node to see all ways it can be obtained, shown in a graphical way that would keep everything. And save that when I am satisfied to come back to it. Tick of individual branches. I did this on paper when playing CDDA to track my goals. Also add text nodes, so people can combine generated and custom-made nodes.

Time per item:
I have 100 things I hoarded and I don't care about. I don't want to calculate in my head what I need to disassemble to get most of item X per least of time. I want to say "obtain copper wire" and it shows me a list of ways I can do it with a column "time per first item" which I can sort by. Also a column "amortized time per item", for when I need 500 copper wire, not just one.

Describe alternatives you have considered.

*all ways an item can be obtained - this could reveal things to the player that shouldn't be revealed, I have two solutions:

1. A checkbox that disables this feature, or makes it debug menu only.
   Or some other, but practically equal way of disabling this feature.

2. Hide everything until the player discovers it.

   • Crafting recipes are hidden until the character sees them for the first time.
   • Disassembly recipes are hidden until the player sees that item.
   • Cut a thing up to show what it cuts into.
   • Smashing is hidden until the player smashes that thing (unblock only the discovered results - only things that dropped?)
   • Item find - bit more complicated - lock it until I discover that place with that loot?

Since there are so many ways to obtain, the GUI would show the 3 or 4 tabs that have "recipes" and one more tab saying "11 more tabs inactive" That tab can be selected and will show disabled categories, if we want that show somewhere, otherwise it cannot be selected.

Additional context

I proposed this as my bachelor's work.

This sort of includes taking on the "disassembly crafting menu", or at least exploring the entries it would have.

Personal todo list

• persistent TODO graph (Tree)
  • place to save the graph
    • member var in acquire_graph_impl: vector of head nodes
    • make it persistent
      • test persistence on int
      • persistence on Node
  • display it
    • (tmp) display vector as TEXT
    • proper tree structure
    • ?graphical
  • tree nodes
    • expand node - add children to node
    • unique_ptr
  • code tree nodes
    • AbstractN
    • ?ObtainN- remove
    • CraftN
      • name
      • expand
      • iterate_children
    • ItemN
      • name
      • expand
      • iterate_children
    • AndN
      • name
      • expanded = true - some parent?
      • iterate_children
      • label
    • OrN
      • name
      • expanded = true - some parent?
      • iterate_children
      • this branch is selected QoL
      • label
    • RecipeN
      • name - "Craft" + item.name() + "as a byproduct of" + recipe item name
      • expand
      • iterate_children
      • implement
        • tools
        • components
        • qualities, ??
    • FindN
      • name
      • expand
      • iterate_children
    • FurnitureN
      • obtainable by (building, placing down, ..?)
    • QualityN
      • children are Items or Furniture with given Quality
    • CustomN
    • CustomAndN
    • CustomOrN
    • ?butcher
    • ?smash furniture
  • button "add Node"
    • add selected node (to display)
  • make tree interactive
    • trigger expand
    • walk the tree
    • mark node as satisfied
  • QoL
    • don't show cycles that will produce equal, or less, of the desired item
      • 2 water from acids that require 2 water and have 1 water as a byproduct
      • metal sheet from a lump of steel from a metal sheet
    • press KEY LEFT on closed item ports cursor to father
    • OrN default - like nearby fire, hide the others
    • failure rate
      • assume failure of x% rounded up, this increases components(+) required

[ZhilkinSerg]

It sounds a bit like HHG - https://cdda-guide.nornagon.net/

[CoroNaut]

I specifically like the to-do list, perhaps there could be a "Gather nearby items" button that could put them into your inventory (only within reach like how far the crafting menu goes to find components).

I also kinda like the "Item find" thing. My thinking is that it could record for example, how many gun stores you've walked into and can say something like "Contains ammunition, guns" maybe? Then as you visit more gun stores, the loot table gets more refined as you get to 10-20 visited?

When looking at an item, having a specific window to open for showing "you could use it to craft..." and disassembly would be nice. Currently, I find that the "you can use it to craft..." section inside the examine window of all items adds bloat to the window.

The "obtainment graph" might need more explaining or pictures, I'm not sure I follow your plan here exactly. Is it more like a flow chart, and you navigate through a flow chart with the selection cursor? Personally, I like the inventory system that essentially lists items, and has an expansion for items inside containers. Perhaps the listing contains all the items in your inventory, and you can expand each item into its disassembly components? Then as you go through the list and expand more items, you can select items to add them to a to-do list?

I made a couple features requests about disassembly with this as the inspiration.

[Brambor]

It sounds a bit like HHG - https://cdda-guide.nornagon.net/

Well... ... ... it is kinda exactly like that. At least the traversing. It doesn't contain the TODO list aka. obtainment graph.
Edit: In other words, it shows only one step, whilst I would like to construct a graph with multiple steps.
Also make it in-game and potentially spoiler-free, preferably based on the player's past experiences, if it doesn't consume too much CPU.

Edit: it is missing the disassembly info for some reason (can be disassembled into). Edit: The fork cannot be disassembled into scrap, huh

Looking at examples, it spoils some stuff I didn't want to know :/

[Brambor]

The obtainment graph (when I want something)
The current graphical representation in my mind is just a graph

Google pic of oriented graph

Distilled into text is probably a nested checklist (with AND and OR capability).
As it needs to support AND branches as well as OR branches.

Now each node is expendable. Let's say you start with pair of survivor boots
https://cdda-guide.nornagon.net/item/boots_survivor - I am using that now.

• The boots are the only node in a new graph of obtainment. You wanted them so you made a new graph with only those.
• You want to obtain the boots, so you expand the boots node.
• The graph expands, adds two nodes
• • one I consider a spoiler, (see the link above if you want to know) It will show this node if you discovered that option
• • one for crafting the boots.
• You can Expand the option of crafting the boots.
• Now this node will spawn (around it) a node for each requirement.
• Nodes with items, like welding_rod_steel behave the same as boots.
• Node with tools tool with glare protection of 1 or more. can be expanded to give tools (or furniture) that satisfy that.

Combining nodes where possible (tools) is possible but that might be counterproductive (contra to simple visuals and simple implementation).

(when I want to know what something is for)
You could also explore the other way (what can I craft from this), but that is not TODO-related, it just tells you, what the fork is for.

The idea is crystalizing in my head, so it differs from the previous iteration.

[Brambor]

I would also like to get a "list of tools I can craft that have at least one quality better than any tool in my surroundings". But that might be for a different issue/system. It is only a nice-to-have.

[PatrikLundell]

I'd suggest the words Acquire/Acquisition.

[Brambor]

What I didn't mention - there should be automatic Expansion, which will expand nodes as needed until a solution is found, ideally with items on hand. This might be slow and some sort of heuristic is needed to compare for example looking for an item outside vs crafting an item for a very long time. These decisions are usually for the player to decide, the decision is equivalent to the heuristics. I don't need to find a good heuristic but I need the system to be able to accept one. Possibly, the player could provide heuristics such as "don't try to search for rare items, preferably craft them" for some definition of "rare item" based on loot pools.

[Brambor]

Note: further down the line, an add-on to the sidebar could be made to track todo.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not bump or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.

[Brambor]

I will slowly work on it. Don't close it yet, bot.

It will become my bachelor's work. There is still time, thought.

[PatrikLundell]

It doesn't matter what the bot does or doesn't. What's important is the merging of PR(s), regardless of how many, if any, suggestions may have preceded them and regardless of their status. The bot just hides the suggestion so it won't be found with normal search profiles.

[Brambor]

It doesn't matter what the bot does or doesn't. What's important is the merging of PR(s), regardless of how many, if any, suggestions may have preceded them and regardless of their status. The bot just hides the suggestion so it won't be found with normal search profiles.

I wanted to make it clear to everyone, that I will work on it, not just bot. But it will take a couple of months.

[Brambor]

This is my latest iteration of the idea:

Use case

The player wants to craft something, they have an item snapshot (IS) ready as a source.

Implementation

Let's define:

• positive(IS) - shows only items from IS that have a positive count
• negative(IS) - shows only items from IS that have a negative count
• "total items" (not shown): IS - want + intermediate - used

The following are (can be) displayed in the layout:

• "missing items": negative(total)
• "available items": positive(total)
• "used items": items used for crafting
• "intermediate items": what player will craft
• "recipes": what recipes in what amount are to be executed
• "want": items the player wants, don't include intermediate recipes
• "time": estimated total time needed to finish all crafts

Want phase:

1. The player clicks what they want to have - this adds the item to "want".

Equalize phase:

1. They select a crafting recipe (and count), then the components used to craft it.
   • add recipe to recipes. recipes can be changed/added/removed
   • add result to intermediate
   • add used components to "used items"
   • add tools needed
   • add total time
2. If there are no missing items, the plan is marked as ready
3. The player can go back to step 1. or quit and save / not save the plan.
4. QoL if there are any unneeded recipes, warn the player, the player can remove them.
5. Find a craft order that would work.

[IdleSol]

Determine in advance how your graph will respond to feedback loops. Just an example, creating a hammer with quality 3 requires a tool with hammering quality 3. And this is either the hammer itself or its bronze version.

For more complex examples, you can look here: #72208 (comment) Variant for steel anvil

[Brambor]

Thanks for the example! I want to cut branches of the graph for some loops.

Tools example

1. obtain hammer > obtain by crafting hammer > need hammering 3

2. craft hammering 3 tool

   • don't allow any recipe that needs hammering >= 3
   • allow finding any hammer

3. if we allowed bronze hammer, to craft it, now we cannot allow any recipe requiring hammering >= 3 in this branch.

I wanted to post a screenshot but noticed hammering 3 is missing in my tool requirement for the recipe for a hammer 🐛.

Component example, I want to find loops where we get C from crafting with recipe R recursively getting back to requiring component C. If this loop doesn't produce any extra C, then don't include this loop at all.
There is some water example:

1. to obtain water
2. make potassium hydroxide which has 1 water as a byproduct
3. use 3 clean water to use it
4. craft 1 clean water from 1 water

This is a negative loop, but stable loops are not acceptable either. (Craft 1 A from 1 B, 1 B from 1 A, 1 A from 1 B...).

However, positive loops are definitely acceptable. But they need some stopping condition so that it doesn't get stuck in a while loop. (Craft 2 A from 1 B, Craft 1 B from 1 A, 2 A from 1 B...)

For automatic Node expansion loops definitely should be solved. For manual Node expansion it is a QoL, but I definitely want to solve it.