Addition to crafting recipes: tool groups

This has been suggested and planned on before, but I finally decided to try and implement it. What follows is the system as I’ve worked it out so far; feel free to point out any problems or make suggestions.
[hr]
I’ve added a new .json file called tool_groups.json, which has entries that look something like this:

{ "type":"tool_group", "id":"tool_pounding", "items":[ [ "rock", -1 ], [ "primitive_hammer", -1 ], [ "hammer", -1 ], [ "hatchet", -1 ], [ "toolset", -1 ] ] }
The basic idea is that instead of including all of those tools in a recipe entry, you can just include “tools_pounding”. Not only does this save space and time, but it standardizes the modding files: if you add in a new type of hammer, you just add it to the tool_group entry instead of adding it to every single recipe that uses it. This part of the system I think everyone can agree is more efficient, but there is one thing it doesn’t take into account.

Some recipes use a certain number of charges from their tools, and don’t use the same number of charges for each one. For instance, in recipes.json we have these tools that are used to make quikclot:

[ [ "hotplate", 18 ], [ "toolset", 1 ], [ "fire", -1 ] ]
If you use a hotplate it’s 18 charges, but the integrated toolset only uses one (since it uses your internal power storage). The solution I suggest would replace it with something like this:

[ [ "tool_heat_source", 1 ] ]

[code]MEANWHILE in tool_groups.json

{
“type”:“tool_group”,
“id”:“tool_heat_source”,
“items”:[
[ “hotplate”, 18 ],
[ “toolset”, 1 ],
[ “fire”, -1 ],
]
}[/code]
So, there are two values for charges: one in the recipe definition, and one for each tool in the tool_group. When a tool is chosen from the list, the given values are multiplied together. So here the hotplate uses 18 charges, but if the value was set to 2 in the recipe entry it would be 36.

This way we could standardize the effectiveness of tools that use charges, because they scale using the values in tool_groups.json instead of being defined for each recipe that uses them. Maybe forging a knife scales the number of charges by 1, but a sword would scale it by 3. This would also change nothing about the existing system, because you could still manually include tools in recipes rather than using tool groups.

Thoughts? Suggestions? Insults? (wow this turned out pretty long)

This is AWESOME!

I think it is excellent idea to keep recipes more standardized. And it can be extended even more…

When I was toying with recipes.json, I started to wonder if it would be possible to use some kind of variable to mark a quality of the used tool. Not the condition, just the quality of the current tool for the job. Ie. Stone vs. hammer while pounding your nails in the window frame. Sure, both can do the job, but other is better suited for the task, and thus you can finish job faster.

For Example:

{ "type":"tool_group", "id":"tool_pounding", "items":[ [ "rock", -1, 2.0], [ "primitive_hammer", -1, 1.4], [ "hammer", -1, 1.0], [ "hatchet", -1, 1.1], [ "toolset", -1, 1.0] ] }

so when you try to build muffler, that takes 10 minutes and need tool_pounding, using hammer for the job takes 10 minutes but using rock will take 20 minutes (10min * 2.0).

Implementing this will require the coding a part that checks your inventory for the best tool timewise. If the multiple tool groups are used for the job, largest found time multiplier could be used.

And if the tool condition is ever added to the calculation, it’s easy to add a damage_effect for the tool used in the wrong job. For example using your trusty frying pan for pounding or digging. After digging a few holes on the dirt you are left with a wrecked frying pan that is slow to use any job, digging or cooking, until it is completely destroyed. Currently only way to damage your tools is acid and tool condition has no effect on the speed of the job.

But that is just me hoping with my 2 cents.

Gatleos gets an internet.

Aye.

Alright, it’s in! There aren’t any tool groups defined yet, but they can be defined solely through the json files.

[quote=“VonCede, post:3, topic:3289”]I think it is excellent idea to keep recipes more standardized. And it can be extended even more…

When I was toying with recipes.json, I started to wonder if it would be possible to use some kind of variable to mark a quality of the used tool. Not the condition, just the quality of the current tool for the job. Ie. Stone vs. hammer while pounding your nails in the window frame. Sure, both can do the job, but other is better suited for the task, and thus you can finish job faster.

-snip-[/quote]
Exactly the kind of thing I want to use this for in the future. The only problem with giving different quality to different tools depending on the task is figuring out how to communicate the tool quality to the player.

Use asterisks for quality?

Like:

rock *
hatchet **
hammer ***

Use asterisks for quality?

Like:

rock *
hatchet **
hammer ***[/quote]

Great idea.

Rivet’s idea for asterisks is a good one, if they can be easily calculated from the tool quality. Or they can be presented in order of existing tools in inventory or nearby.

Other idea I had was highlighting the best tool in brighter green. But it can cause some problem for colorblind people. Also if the required time can be changed to show in the crafting menu, like “Time to complete: 17 (10) minutes”, it can give player some idea how well equipped s/he is for the current task.

Then there is that can of worms if player is allowed to choose the other than the best tool… Personally I would not implement it, because it will make crafting even more tedious than it currently is (Yes, I’m looking at you, mass battery production with all those different kind of cans, scrap metal and butter knifes, ammonia and lemons). If the player wants to save that precious hammer, it can be dropped far enough.

I’m torn on merging this, because while this is a step forward, when a new tool is added, you have to edit multiple places to make it happen, I think annotating each tool will be a better way to do this, like:

  {
    "id": "hammer",
    "type": "TOOL",
    "symbol": ";",
    "color": "brown",
    "name": "hammer",
    "description": "Use a hammer, with nails and two by fours in your inventory, to board up adjacent doors and windows.",
    "price": 70,
    "material": ["iron", "wood"],
    "weight": 566,
    "volume": 2,
    "bashing": 17,
    "cutting": 0,
    "to_hit": 1,
    "max_charges": 0,
    "initial_charges": 0,
    "charges_per_use": 0,
    "turns_per_charge": 0,
    "ammo": "NULL",
    "abilities": {"DRIVE":5, "PRY":3, "SMITH":3},
    "revert_to": "null",
    "use_action": "HAMMER"
  },

This also makes more sense because you’re just defining the properties of the items, and it gives you a straightforward place to put the different tool qualities.

This really needs to be done the other way around - this implementation makes effective mod management virtually impossible since you’ll have multiple contradictory definitions of each tool group.

Ugh, god damn I wish I hadn’t fucked up my own implementation of tool qualities. I think I need to just… go back and do that again. Kevin, don’t merge this just yet - I’m gonna try to get this done tonight and just power through. If I don’t get the implementation we agreed on way back in done correctly this time (I’ll try to avoid getting ambitious) maybe this is what we should do, but I’d like a chance to do it that way first.

I approve of this thread and everyone in it. (excepting recursion)

[quote=“Kevin Granade, post:10, topic:3289”]I’m torn on merging this, because while this is a step forward, when a new tool is added, you have to edit multiple places to make it happen, I think annotating each tool will be a better way to do this, like:

  {
    "id": "hammer",
    "type": "TOOL",
    "symbol": ";",
    "color": "brown",
    "name": "hammer",
    "description": "Use a hammer, with nails and two by fours in your inventory, to board up adjacent doors and windows.",
    "price": 70,
    "material": ["iron", "wood"],
    "weight": 566,
    "volume": 2,
    "bashing": 17,
    "cutting": 0,
    "to_hit": 1,
    "max_charges": 0,
    "initial_charges": 0,
    "charges_per_use": 0,
    "turns_per_charge": 0,
    "ammo": "NULL",
    "abilities": {"DRIVE":5, "PRY":3, "SMITH":3},
    "revert_to": "null",
    "use_action": "HAMMER"
  },

This also makes more sense because you’re just defining the properties of the items, and it gives you a straightforward place to put the different tool qualities.[/quote]
This does make more sense. I think I’ll do that.

EDIT: That is unless Gryph is working on it. I can get this done pretty quickly, but I don’t want to if someone else is working on the same thing and we end up stepping on each other’s toes.

Yeah, mostly done. Will finish up tonight - would have finished up last night if I didn’t keep getting distracted, heh.

I gotta say, in my previous experience watching different coders work on the the same ideas in a project:

Yall some civil-ass motherfuckas.

Right around now is when I would normally expect people to be at eachother’s throats trying to choke the life out of one another over the internet.

Instead you’re just getting it done.

Bravo.

Eh, I’m just glad to have helped lay down the framework. As long as it gets in more or less intact I’m good.

There are plenty of disagreements around here about features, most of them are just from people who can’t do anything about it. :stuck_out_tongue: