Optional crafting tools

[mugling]

I'm considering some changes to the crafting system but would like opinions before I start.

The current quality requirements SCREW 2, HAMMER 1 would become the minimum requirement to craft an item. Where you exceed the requirements (eg. needs HAMMER 1 but you have HAMMER 3) you gain a proportional bonus to crafting speed ± success rate.

This would allow us to implement optional requirements, for example MULTIMETER 0 for some electronics. You can craft such items without a multimeter but it would be much easier and faster if you had one. More complex items could require the item with MULTIMETER 1.

This allows us to build upon tool qualities by providing a much greater range of tools. In the above example we could provide multimeter (quality 2) and an improvised multimeter (quality 1) with different trade-offs (item frequency, weight, volume etc).

Items like the multitool then become more interesting - do you carry around such an item and accept slower crafting speeds or haul around a much more weighty toolbox? Garages and electronics stores become more interesting and we could perhaps add a tool merchants store as well?

Recipes can be added or adjusted piecewise so it's more comments as to whether the mechanism itself sounds interesting and what the semantics of any implementation could be?

[Coolthulhu]

This requires few issues to be resolved:

• Currently recipes do not allow alternate tool qualities - the set of required qualities has to be a single set. So for now it would be easier to add "time" as an alternate tool rather than tool quality.
• Proper way of defining it in a json. Has to be readable and concise. I'd say that adding "TIME" as a fake quality would work best, assuming alternate tool qualities can be done easily. For example, to construct a brazier, you could need [HAMMER 2] or [HAMMER 1 and TIME 100].
• Displaying the new requirements. If the "time as tool" option was chosen, it should be quite simple

Exchanging tool qualities for time would be mostly useful early in the game, before finding/constructing the first cart. Or with unlucky item spawns.
Later on it could be about using charged tools to save time - for example a chainsaw vs. wood axe, circular saw vs. hacksaw, welder vs. soldering iron, sewing machine vs. sewing kit.

[kevingranade]

I really like the "tool OR time" approach, especially since it addresses my main concern, which is that different recipes need to vary in their time cost scaling. On general, something like this has always been the intended "phase II" of tool qualities.

[SeanMirrsen]

As far as defining it in the JSON - I think there should be both a minimum, and a maximum time that a given thing takes. No matter how good your boiling apparatus you're not going to get a thing cooked faster than the water can boil, you're not going to drive nails or screws at supersonic speeds no matter how good a hammer/screwdriver you have, etc. So an upper and a lower bound. Tool quality, then, could provide a modifier, either in percentage or a vague "ticks per time unit" value, I'm not sure what will be more useful. Either way, the modifier value would be optional, and it would have an effect of adding the specified amount of speed per each point of tool quality over the requirement.
This way, you can have tool requirements that don't affect the speed with level increase (containing quality, for instance), and you don't have to worry about stacked modifiers resulting in unrealistic crafting speeds (because you have a cap). It does mean you can potentially max out a recipe in such a way that you don't increase crafting speed despite using a better tool because another tool you have is ridiculously good, but that'd be a matter of tuning the recipe, not a fault of the system.

[Rivet-the-Zombie]

I'd love to see something like this.

[mugling]

I'm considering first implementing this for tool qualities as a capped percentage bonus reducing both required time and failure rate.

For each level above the minimum you get a bonus proportional to the number of qualities, with some qualities weighted more than others. The bonus for each level is applied consecutively so each extra level contributes less.

For example given requirements of SCREW 2, HAMMER 1 and MULTIMETER 0 and a bonus of 30% equally weighted (eg 10% per quality-level):

SCREW	HAMMER	MULTIMETER	Extra levels	Bonus
1	1	0		failure
2	1	0	0	0%
2	1	1	1	10%
2	2	1	2	19%
2	3	1	3	27%
2	3	2	4	34%
3	3	2	5	41%
3	3	0	3	27%

Now for MULTIMETER with a weight of 4 and the others at 1 each excess level of MULTIMETER is worth 20% and the others 5%:

SCREW	HAMMER	MULTIMETER	Extra levels	Bonus
1	1	0		failure
2	1	0	0	0%
2	1	1	1	20%
2	2	1	2	24%
2	3	1	3	28%
2	3	2	4	42%
3	3	2	5	45%
3	3	0	3	14%

In the second weighted example three excess levels of SCREW or HAMMER provides less bonus than a single level of MULTIMETER however when all qualities are available in excess there is little overall difference (compare last two lines of each table).

This algorithm is simple to implement needing only a weighting parameter for each required quality and a bonus_cap for each recipe, both of which could be be defaulted to 1 and 50% respectively.

Optional tools would be specified as being required at level 0 and in most cases should be given a larger weighting.

Thoughts?

[kevingranade]

I don't like the percentage plus weighting approach, it's rather confusing. Also I don't like the prospect of the addition of new optional tools causing the impact of existing tools to diminish. Finally, I'm not a fan of conflating speed and success rate. Also Sean has a good point, in a lot of cases we'll want behavior like "reduce the time to do 'prep', but don't change the cooking time", I don't see an easy way to enforce that with this system without implicitly factoring in the maximum tool quality level. What I'd like to see is an enumeration of quality levels and bonuses from providing them. It would be trivial for the bonuses to be either a raw time reduction, a percentage time reduction, an adjustment to failure rate, etc. This would lead to more verbose recipes, but they'd be easier to read and understand. I don't see a good reason to have the bonuses scale based on how many of them are applied, that makes it a lot more difficult to reason about outcomes.

[Coolthulhu]

I'm with Kevin here.

For many recipes you need just the ability to hammer stuff/turn bolts/boil water.
A frying pan will reduce boiling time compared to a can (larger surface area), but a pot won't help above that (unless your fire is huge).

Then there's the part where we'd probably want some recipes to be super-expensive without tools, but way more sane with them. For example, turning screws with just hands to dismantle a loosely bound machine.

Just a hardcoded percentage change to craft times would result in the whole deal being insignificant for "single-craft" items - 1 hour or 2 hours isn't much when you only craft survivor gloves once in a game. Changing it to "6 hours or go grab the tools" would make it matter.

Having tools contribute to success chance would require a rebalance of crafting difficulties. Currently they are only affected by a handful of factors - basically just difficulty and some hardcoded mutations.

[SeanMirrsen]

Having tools contribute to success chance would require a rebalance of crafting difficulties. Currently they are only affected by a handful of factors - basically just difficulty and some hardcoded mutations.

Hmm. Just throwing an idea out there, but - so long a we're on the subject of adding thresholds to recipes, what about having a difficulty threshold? As in, if you have a particular set of tool qualities available, the recipe becomes a different difficulty than if you don't.

And back to the boiling water thing -

a pot won't help above that (unless your fire is huge)

If this change does go in, it might be time to assign qualities to the heating items, plus a hardcoded quality to "a nearby fire". A lot of things that require heating also have the option of using a nearby fire, and for some of them (like melting plastics) using a fire is going to be much more difficult than using a hotplate.

[illi-kun]

This issue was closed as it appears inactive.

Reducing open issues to those which are (or will) be actively worked upon helps us focus our efforts. This issue has not been deleted - it still appears in searches and if it contains relevant information you are encouraged to continue to link to it.

If this issue was a bug

It should be reopened if it can be reproduced in the current build. You can obtain the most recent copy here. Please check there is not a more recent report of this bug before doing so. If no more recent report exists you should continue the discussion in this issue.

If this was a feature request

If the consensus was that the idea was good you could consider submitting an implementation via a PR. If you want to comment further please do so here as opposed to opening a new issue. Before posting check nobody has already made the same point and consider whether your comments are likely to lead to an implementation. If you have doubts about either consider instead voting for the issue

If you want to work on this issue

Then either assign it to yourself or if you are unable to do so claim it via adding a comment. Please don't assign others or make a general request for action.