Log wall camp expansions require angle grinder
Describe the bug
Some camp expansions with log walls require angle grinder with charges. Currently noticed in modular camp version 2 main building during step 2 of initial shack construction and adding second room.
Attach save file
N/A
Steps to reproduce
- Get a follower.
- start modular camp
- Build first step of shack with log walls.
- Look at the tools requires to continue building shack walls with log wall.
Expected behavior
Angle grinder is not required to build log walls or wooden floor/roof.
Screenshots
Versions and configuration
Windows 10. Experimental 2024-06-03-2520
Additional context
My guess is the process of some expansions tries to tear down some previously built walls and then rebuild them, and fo that asks for a grinder.
/confirmed
It's caused by the selection of "t_floor" for the floor component, but I can't figure out why. I've hacked the palette to replace the various terrain components, and replacing "t_floor" with "t_dirt" in the palette causes the weird angle grinder requirement to go away. This is the recipe that should be used for the floor:
{
"type": "construction",
"id": "constr_floor",
"group": "build_floor_with_treated_roof",
"category": "CONSTRUCT",
"required_skills": [ [ "fabrication", 3 ] ],
"time": "120 m",
"qualities": [ [ { "id": "HAMMER", "level": 2 } ], [ { "id": "SAW_W", "level": 2 } ] ],
"components": [ [ [ "wood_sheet", 1 ], [ "wood_panel", 2 ] ], [ [ "2x4", 6 ] ], [ [ "nails", 40, "LIST" ] ] ],
"pre_note": "Must be supported on at least two sides.",
"pre_special": "check_support",
"post_terrain": "t_floor"
},
This is what my construction of storage expansion 2 first section requires when everything apart from the floor has been replaced by "t_dirt": Chiseling 2, Digging 3, Hammering 2, Prying 3, Angle grinder, 540 planks or 72 logs, 1080 nails Time: 1 week and one day. This for 36 floor tiles, so 15 planks or 2 logs, 30 nails per tile, and 5+ hours per tile.
This leads me to believe there's something wrong with the construction sequence logic such that it's not selecting the construction recipe for the floor, but rather a longer sequence involving prying, chipping, and angle grinder. The tools match what's in the "wall_floor_glass_removal_standard" tool set, so it appears the logic selects the construction of something and then removal of it to end up with a floor. There are lots of "remove" constructions that result in "floor".
Someone with insight into the code determining the steps to construct a specified end result would need to look into this, as the logic obviously selects a longer and more complicated path than the direct construction of the end result (several steps is the logical case for some things, such as e.g. suitable empty ground->pit->half log wall->log wall).
While working on #76980 I discovered bugs in the logic for recursing through blueprint recipes to add up costs. One of them is that it was choosing DECORATE recipes, like taking paint off a wall as the one true way to make a wall.
I suspect that this issue is another instance of that misbehavior, except in this case there's not the same easy fix (my PR excludes DECORATE recipes on the first pass).
The appropriate fix may be to move all the deconstruction.json construction recipes to a new category (DECONSTRUCT?) which could be filtered out, either completely like REPAIR recipes or based on priority like I've done for DECORATE recipes.
Does this sound like a likely cause? And a reasonable fix? What side effects may happen if those recipes get moved to a new category?
I don't have any idea of how the logic works, but ideally the cheapest route should be selected, as any logic built on lowering priorities for some steps together with a first find approach is likely to result in weird cases, and any reshuffling of priorities is likely to cause the unsuitable cases to be shifted elsewhere (although the number of oddities may decrease through the process).
However, I don't think deconstruction should ever be a path to construction (although you have to be careful: digging a hole might fit in both categories, for instance, depending on purpose), as opposed to decoration, which may be a valid finishing step (would there be any cases where more than one decoration step may ever be desirable, keeping in mind that "ever" is a mighty long time?).
If you need to go via deconstruction to construct something, you should probably be forced to do that in two steps. Decoration is a bit trickier, but building e.g. blue walls in a base camp can still be done by moving the decoration to a dedicated decoration upgrade, but I think the existing cases are something like white walls with no other alternatives.
The current logic, if I've followed it correctly, is that the first path is chosen. While I agree that an optimal solution would be good, I'd like to make more achievable incremental improvements. Decreasing the number of oddities is a worthwhile goal.
I might agree to completely exclude deconstruction, similar to how REPAIR constructions are currently excluded, but I would want a thorough audit to confirm this doesn't make any items impossible to include in blueprints.
I can imagine a construction with multiple DECORATE steps in a row, such as painting a wall a color then painting art on it, or halfway painting a wall the way we currently halfway build a wall.
What would "cheapest" mean if there are two routes using different base materials? e.g. if I can make something from X sticks or Y long sticks or Z planks, which is cheapest, and do we count labor time as well?
Given the difficulty of comparing the "value" of different materials, I would suggest basing the "price" of a construction firstly on the number of steps (so fewer steps is better), and then on time (faster being better). That would have some inherent risks, though, as some constructions are using more steps than other, but it ought to be rare for them to lead to the same result while using wildly different routes.
I don't have a faction camp that can build log walls. Can someone test #77163 to see if it fixes this problem? I've confirmed it fixes the similar problem for "board up windows" needing a paint chipper, but the root cause there is slightly different.