Proficiencies.

[I-am-Erk]

Is your feature request related to a problem? Please describe.
Skill gain is both too fast and too general currently. Building a house teaches you what you need to take up glassblowing, and within a short time you can master every skill in the game.

Describe the solution you'd like
A proficiency system would allow skills to be broken up into different subspecialties, with crossover between related fields handled by overall skill level. It would also provide something to learn and advance in with slower level progression: yeah, fabrication 8 might take three months of game time, but on the way you can learn all kinds of different proficiencies, so you won't feel stagnant.

A proficiency entry in JSON might look like this:

"id": "lockpicking",
"name": "lockpicking",
"description": "You are proficient in picking a mechanical lock using a lockpick.",
"skill": mechanics",
"min_level": 1, //cannot even attempt below this level, don't know where to start.
"learn_level": 3, //cannot learn it until this level but can attempt it with a book
"untrained_multiplier": 10, //time to complete is x10, likelihood of success is /10. The XP gained is divided by this too, so if you spend 100 minutes on a lock because you don't know what you're doing you still only get 10 mins of XP.
"book_multiplier": 5, //as above but you have a book to guide you
"NPC_multiplier": 3, //as above but a mentor NPC is guiding you.
"related": [ "hotwiring": 1.05 ] //experience towards a related proficiency will be multiplied by this factor if you know this proficiency. So knowing lockpicking makes you learn hotwiring 5% faster. Related also reduces the untrained and book multiplier effect by this amount. Lockpicking and hotwiring share very little  but some proficiencies, such as "canning" and "pickling" for example, might share a lot, so if you know how to can food you're much better equipped to work your way through pickling on your own.
"requires": "null", //lockpicking doesn't require an existing proficiency to learn, but some proficiencies might. This would allow us to have "better versions" of proficiencies at higher levels potentially, particularly thinking of combat moves here. It could also allow us to have some low level proficiencies like "basic spectroscopy" that are required to learn "mass spectrometry" later.

If a recipe/action requires two proficiencies and the player is not proficient in either, use the harshest penalty of the two. If the player is proficient in one, half the penalty of the other.

XP: all skill XP is expressed in hours of learning here, although the game should measure it in seconds. For crafting skills this is simply the time spent crafting/doing actions related to the skill. Combat skills will need a different conversion that I'm ignoring at the moment.

L1 5 hours
L2 15 hours (20 total)
L3 100 hours (120 total)
L4 200 hours (320 total)
L5 350 hours (670 total)
L6 600 hours (1270 total)
L7 1000 hours (2270 total)
L8 1500 hours (3770 total)
L9 2200 hours (5970 total)
L10 3000 hours (8970 total)

To learn a new proficiency requires an amount of XP equal to (learn_level)² in hours, spent using that specific proficiency.

You start the game with a number of proficiencies equal to the number of skill points you've invested.

List of some suggested skills and proficiencies (skipping combat for now)
Computers
-programming
-hacking
Cooking
-canning
-baking
Electronics
-hotwiring
Fabrication
-carpentry
-knapping
-pottery
-glassmaking
Health (formerly first aid)
-wound care
-suturing
-soft tissue infection
--sepsis
-anatomy
Mechanics
-welding
-lockpicking
Science
-basic chemistry
--biochemistry
--basic spectrometry (req basic chem or basic physics)
---mass spectrometry
---nuclear magnetic resonance
-basic physics
Speech
-barter
-persuasion
-intimidation
Survival
-animal trapping
-booby traps
-military traps
-makeshift shelters
-plant identification

the overall list would be a dependency tree, this is just to give a quick idea.

Describe alternatives you've considered
Splitting skills up is inelegant for crossover... but a single master crafting skill with subskills for each crafting type is conceivable (fabrication - blacksmithing).much like marksmanship - archery. I don't think this is easier or better than the boolean "knows blacksmithing".

Additional context
This would require lots of json editing.

This post not done.

[Inglonias]

In addition to the JSON editing you pointed out, this would require some UI work to ensure that the character sheet doesn't get cluttered and difficult to use.

[I-am-Erk]

I think you'd move the cursor over a skill to see a list of what proficiencies you have in that skill, or have partly learned and maybe press a key like "P" to examine the individual proficiencies and their descriptions.

That or we split the @ menu into tabs, which might be just about due

[Amoebka]

Crafting currently increments time with a step of 5 minutes and takes 1-2 seconds real time per tick on average. That's ~15 real seconds for an hour of activity. 9000 hours of crafting is about 47 REAL HOURS OF PLAYTIME. And, in fact, a lot more than that, because the player has to manually answer hunger/thirst/sleep prompts. This is simply unreasonable.

I understand it's tempting to implement all these long-taking actions to make the game more realistic and whatnot, but unless there are auto-eat, auto-drink, auto-sleep mechanisms and the game can process 1 game week in a minute, it's simply torturing players by forcing them to stare at the screen for hours without doing anything interesting.

[I-am-Erk]

#30415 auto eat and drink zones should be pretty trivial to set up apparently. Auto sleep shouldn't be too much harder. Practice actions will help to further automate it. There are ways to further speed up automatic time passage, like allowing line of sight calculations to be lazier... These things are all planned at this point, and not really germaine to the subject of proficiencies

[Amoebka]

Well, you kinda propose 2 things at once: proficiencies and exponential practice time requirements for gaining skill levels. I have no issue and, in fact, welcome the first one, but the second is deeply flawed and I can list a lot of arguments why it's not a great idea.

Lazier LoS calculations are excellent, but I doubt little optimizations like that can speed the game from 1 second per 5 minutes to 1 second per day.

[Zireael07]

What lazier LoS are you talking about @Amoebka ?

[I-am-Erk]

1 second per day is never happening, obviously, nor should it. One of the underscored points of this is to make more things happen within a single level of a skill, so that lateral learning is a bigger thing rather than just pushing to the next level. We're not getting around slower leveling of skills; it's pretty much a foregone conclusion, I'm just mentioning it here for the sake of suggesting a proficiency level up speed in that context.

[kevingranade]

This issue has been mentioned on Cataclysm: Dark Days Ahead. There might be relevant details there:

https://discourse.cataclysmdda.org/t/butchering-should-be-its-own-skill/24086/22

[meelock]

I don't know if this is off topic, or exactly how the process of built in mod creation works, but it might be a good idea to make a mod similar to stats through skills that affects stats through proficiencies, as proficiencies become more functional.

Also adding proficiencies for martial arts would probably be a very good idea, perhaps some professions can know a martial art, but not have the body aspect (the proficiency) from the start of the game, while others such as the black belt have max proficiency in whatever martial art they took from the start of the game.

[jwgrawe]

I feel proficiencies should have a more binary nature to them, representing substantial (and critical!) practice and experience, and thus reducing failure consequences/chances, improving success consequences/chances, etc.
The more a skill is predominantly theoretical, the higher the chance it will have need for proficiencies, to represent familiarity with certain practical applications of the skill. In the case of nigh solely practical skills (like martial skills), there should be as few proficiencies as possible, as all kinds of skill use here should be easily represented solely by the skill level itself.
I have this strange worry that overly relying on proficiencies to hotfix certain issues and unrealisms will eventually lead to a saturation of proficiencies, and that these might infringe on the tried-and-true enjoyable systems based on scalar proficiency (i.e. skill levels).

Moreover, I can't shake the feel that the most elegant solution would be to simply divide up the skills and create dependencies, defaults and bonuses between them. Then adding sparse binary proficiencies on top of that, to represent a degree (or several degrees) of critical practical experience in certain skills, not reachable without actual attempts and practical training.
This way (i.e. having more less generic skills), the framework for adding skills and skill checks might be made more generic and ready until such a time as we hopefully might get more options for skill checks. (E.g. social engineering, engineering/design/invention, scientific research, ritual magic, etc.)

Lastly, I'm not sure there's even a definite need of proficiencies at all, provided sufficiently specialized skills are added, like my suggestion above. Piloting could be its own skill (hard to learn and harder to train!), and glassblowing could be too, if it's not to be gated by recipe. Weaponsmithing and armorsmithing are realistically very different from regular blacksmithing, and practically disciplines in their own right. In my opinion they would work both as proficiencies based on "Smithing" or Blacksmithing, or as skills in their own right, with defaults ties up with any related skill.

[DoctorVanGogh]

As more and more proficiencies get added, this system (in it's current form) feels worse and worse to me.

Sure, the concept of "you gotta know how to foo - otherwise it'll take longer" sounds great. And it works great if there is a limited number of proficiencies, and a limited penalty for lack of knowledge and easily accessible information for the player.

Currently that is not the case. Take the following example:

Example

That recipe presumable takes one hundred days of pure crafting time to complete (season is left at 91 days). That is fricken insane.

Yes, you don't know cobbling, yes you don't know much about waterproofing, yes you have difficulty with those advanced materials, and yes, you don't really know how to treat leather.
But according to the recipe you are "merely" up-armoring some existing footwear. That should not take 2400 hours.

Even if you are absolutely clueless about the proficiencies... It should not take more than a few days (of 8h crafting) at most... and maybe eat some materials and maybe result in a damaged item (due to lack of proficiency).

Rant

This feels less like a game system (remember - this is supposed to be fun) and more like someone taking the mickey by making things effectively unattainable.

Suggestions

This clearly needs work. A lot of work.

• There is no current way to filter by used proficiency (Which would help in finding the "cheap" learning tasks).
  Suggestion: Add a f:xyz clause to the crafting filter to search for proficiency xyz.
• Cumulative penalties need an extremely hard look. Currently penalties can just stack up ad infinitum. That is bad. I thought those 750% penalties on some smithing tasks were bad. Oh boy was I wrong... 10800% is just ... No... 🤮
  Suggestion: Significantly lower the cumulative effect. Maybe order by descending penalty severity and apply damping factors by position?
• Lots of recipes need a hard look at the added proficiencies. In some places they make little sense (see example recipe). Why is there cobbling in there?
• The whole system seems half-cocked. If the player has a recipe book presumably in that recipe there would be steps on how to do something. Which would lessen the impact of lack of proficiency - a lot. Or are the recipes just "hey, you can combine a paper clip and some chewing gum to create a nuclear reactor". But if recipe books lessen proficiency penalties then only auto learned recipes would be penalized.... which makes no sense.... because then the player is worse at what they know than what they dont know.
• This needs an off-switch. At least until the whole system is somewhat balanced. Add an external option AUTO_PROFICIENT, put it in a basic mod "Auto-proficient" and have it simply return 100% proficient for every value if active (similar to no npc food).

[I-am-Erk]

You are choosing the most top tier items in the game, and looking at how they are to make if you have no idea how to do any of the necessary skills. It takes a very long time, quite intentionally. If you want to learn cobbling, leatherworking, plastic molding, and waterproofing, you should do that first and then try to use those skills to make a specialized piece of gear better than anything you could have found pre-cataclysm, including milspec stuff.

If you look at the time to do something like knit a sweater, or even make a pair of boots for a character who doesn't know how to make boots or work with leather, the timeframes are much more sane.

Semi unrelated: Survivor gear performs too well to be upcycled clothing. That is a conversation outside proficiencies really, but I am doing some of the adjustments alongside each other so it's fair game to bring it up here. Either the survivor gear needs a nerf or it needs to be much harder to make to justify what it is. I'm going a bit more towards the latter presently.

Edit: Not to say, by the way, that my timeframes are perfect at the moment. Just that you've based your analysis on a pretty bad example.

[DoctorVanGogh]

I am aware that I'm arguing with a double edge case here. I specifically looked for the item with the highest duration penalty. And I'm only seeing it because it's a migrated savegame where the character did all the "simple" stuff when there were no proficiencies in yet.

If you look at the time to do something like knit a sweater, or even make a pair of boots for a character who doesn't know how to make boots or work with leather, the timeframes are much more sane.

I am in absolute agreement with you here: If there are one or two proficiencies involved, the system is (mostly) sane.

But if there are three or four proficiencies at play, then the penalties just keep multiplying with each other. And that is no longer sane.

I think the penalty aggregation needs tweaking here. Anything above a composite multiplier of 20x feels absolutely insane, above 15x is still really bad, and above 10x is "merely" aggravating.
So maybe the penalties should not be multiplicative but additive. Maybe it can stay multiplicative but any penalty past the first gets a decreasing weight.

Ultimately the system should be tweaked so that the absolutely hardest item with the absolute shittiest skills should end up at (or just beyond) the "really really bad" but not yet ludicrous threshold (which to me felt like a 15x composite multiplier). But then, maybe such "under" proficiency should get a penalty to material loss chance instead.

I'll see if I cant crunch some numbers here to see if I can come up with some formula suggestions.

[I-am-Erk]

What you're facing here is what I'd call a soft cap, and that too is intended. After a point, you can't really make survivor boots. You don't know how. If you sit down to make them, you'll just fail and you'll spend more time goofing off reinventing the wheel than you would if you started with something more skill appropriate and worked your way up. The time multipliers aren't the big one, your failure rate on an item like that is going to make it impossible regardless.

We could add special code to make a hard cap saying "after x time and failure multiplier just hide the recipe", but that's just a UI thing. Personally I'd rather have the option to try, because there are going to be edge cases where the attempt is worth it*, and a hard cap will reduce that freedom.

*For example, you could gather the parts, assemble them to an in progress item, and then stop. Then you have them gathered up and won't accidentally use them for something else while you learn the needed proficiencies.

Edit to add:
Thinking on it, there's one thing I dislike about stacking multipliers, which is that learning leatherworking alone drops that time by several months. I might run some numbers and see how badly it would shift things if we did a sum of multipliers (ie actual time = base time x (sum of proficiency multipliers)) instead.

[DoctorVanGogh]

Did some number crunching as promised - I think adding the penalties (not multiplying them) is the way to go. Cumulative penalties top out at 13x (as opposed to 108x) while lower numbers stay significantly closer:

https://gist.github.com/DoctorVanGogh/bd5a1fa2f3869748dee40e563e42f219

---

PowerShell script to grab results: https://gist.github.com/DoctorVanGogh/b236963ec9e0e529fcb385c334607bc6

[I-am-Erk]

Unfortunately I think adding the penalties is quite a bit too soft. Something that takes an experienced professional a half a week of full-time work shouldn't be doable in only a month or two for someone without the foggiest clue where to even start.

We could, at some point, look into diminishing returns, so each subsequent proficiency has a lessened penalty to time, but I suspect it will remain this way for stable, because it is pretty much working as intended with just some fine tuning at the extreme end

[DoctorVanGogh]

See #44302 for my suggestion of an optional "off switch".

[I-am-Erk]

Yeah, toggling a feature like this not happening, as usual. Progress marches on. If people turn things off because they're in progress, they will never be tested properly. On the other hand, your passive aggressive approach to me discussing this with you, considering options, and not immediately agreeing has made it so that now I'm unlikely to listen to you in the future. Good job?

[DoctorVanGogh]

I am sorry Erk, that you see this as a passive aggressive attack on you - it was not meant as such. This was me putting my code where my mouth is: If I claim that this needs a switch, then I may better damn well be willing to at least try adding that one.

And since you seem to be the driving (or at least most visible) developer behind that feature here, I don't really expect you to go all "Oh gosh, yes, of course! That random person on the internet who jumped out of that bush 2 days ago is right, I will immediately change my plans". Thus me trying to add an option for some tweaked things while you stuff in your system as you designed.

I realize that the mere offer of an alternative system somewhat steps on your toes here. But I would much rather have tried offering an alternate solution than keep on stomping my foot and going "But I'm riiiiiiiiiiiiight! You should change the default system to what IIIIIIII want."

I was - at least until now - under the impression that options & configurability were the preferred way for this project. Well - seems Kevin thinks otherwise, so my whole argument is probably moot 🤷

[nexusmrsep]

Actually the well-advised decision of not allowing step-back options dates a long back in history of the project.

Requests for toggle-off bail-out options emerged, emerge and will emerge after almost every major feature or shift of paradigms in the game development (and by paradigms I mean entering yet another tier of it's complexity).

I can imagine that if it was an open option, the need for constant support of ever-branching out superimposing "nerf" options would hamper further development. And if "the mainline" features is what you deliberately design, they why even stray off the path by adding a back door. It would be like saying "hey, this feature completes a milestone in a development goal, but lets leave the back door just in case". One year after and you'll have a house of doors to manage and you'd be adding more doors, to allow other doors to open, in order for them to not get into each other's way, as they start to intertwine.

And you end up with inability to obsolete old code (which you are in fact no longer interested in as you developed a new milestone and you want to follow that path) as it supports one of the branches, and now any change to that area and you have two competing branches of codes to update in a single project, and you need to follow every path and interaction on both branches, and if they too branch out, then you end up in a Mandelbrot fractal hell. "What about a back door for mods?" is still not valid in this scope, as a back door is always a back door and falls under the same scrutiny traps.

Options & configurability yes, but along the mainline path of development. You cannot expect to put an equal sign between options & configurability and de facto carrying the baggage of the previous obsoleted features. For that previous game versions are supplied, so one can roll back to the past at the cost of forsaking the future. But you can't have the past and the future in one cake, as you cannot have a cake and eat the cake. Schrodinger's cat option wouldn't work here imho.

[anothersimulacrum]

Yeah, the option (hah) is between maintainability hell by adding an infinite variety of options, or adding options for stuff and then just stripping them out when something related to them changes so that they don't need to be maintained.
Or just, do neither.

[DoctorVanGogh]

Here's my reasoning on why I think this thing needs options. Some of the maybe temporarily, some maybe permanently:

---

1. Synopsis

The in development Proficiencies system is a new[1] game mechanic aimed at adding granularity in player progression, activities & playthrough differentiation.
This is my impression of what it does and where I think it falls short and needs work.

1.1 Proposed System

The system was proposed as splitting up tasks into specific knowledge domains where lack of knowledge increases time required to complete the task (or allow otherwise completely unattainable tasks to be executed).
The original proposal suggested a quite lenient penalty system (Maximum of all penalties, reduction in penalty for lack of domain knowledge if the player had other domain knowledge) [2].
The initial draft proposal suggested about 1-6 knowledge domains per existing skill with most skills being split into 2-3 domains.
With the existing number of skills this should end up with about 50-ish non combat proficiencies and possibly another 6-12 combat proficiencies (assuming a lot of combat skill proficiency overlaps - aiming is aiming).

1.2 Current implementation

The current (partial) implementation turned out to be somewhat different. So far tailoring is the first skill which has gotten its initial pass at specific knowledge domains. It has recieved ten proficiencies with several interdependencies and prerequisites:

Penalties are not calculated on a maximum basis but all stack on top of (and reinforce) each other. While most touched recipes have gotten one or two involved proficiencies, some have gotten three or four. In the aggregate this can lead up to a activity time penalty multiplier of 108x (!!)[3] - average maximum cumulative penalties are at about 9.4x with a median of about 4x.
The current implementation treats partial domain specific knowledge (anything below 100%) the same as a total lack of knowledge. So a character with 99.99999999% knowledge about a domain acts as clueless (and takes as long) as a character with 0% knowledge.
Knowledge gain is achieved at every 5% of activity. Activity duration is not recalculated for in-activity knowledge gain.

2. Percieved issues

2.1 Issues with other game systems & concepts

The new system muddles and conflicts with the existing concepts of recipe knowledge & learning and skill/recipe books. So far a player either knew a recipe (memorized) or had a recipe book which allowed them to perform the corresponding crafting activity. With this new proficiencies system, that knowledge suddenly becomes arbitrary. Skill gain may magically pop a new recipe into the players mind, but will not give any knowldge on the component tasks required to achieve the end result: "You know a nuclear reactor can be built out of some belt buckles, shoelaces and a piece of gum - you just don't know how".
Also recipe books may contain a recipe for a task, but supposedly do not give any help on the intermediate steps.

2.2. Issues with the system itself

As stated in 1.2 the new system can create very large composite penalties due to the stacking of multiple values all reinforcing each other. The current absolute edge case can lead to an activity time of over 100 pure crafting days. Only after 5 of those days (or 15 days of 8h shifts) would the character gain any proficiency knowledge - but with that much time spent carfting they should immediately jump to 100% in that proficiency, alas, the task would not recalculate the required duration.

Almost perfect proficiency is treated as no proficiency at all. While the system records like a float, it acts like a boolean. Proficiency is either there or not.

Also I'm seeing some scope creep here. What initially suggested about three proficiencies per skill turned into ten for the first skill with a serious pass. If this pattern keeps up, the system will end up with well above 50 proficiencies. Which will not be an easy thing for the game to display or players to keep track of.

3. Some thoughts & ideas

3.1 Short term

• To me the current pain points lie mostly in point 2.2. Slowing down progression can devolve into a grind. There is very little "fun" for the player in staring at progress bars for the sake of just making things take more time.
  And since the most egregious outliers of time penalties come from the stacking of penalties, I would suggest a rethink in the aggregation of penalties (to compress limits down into a desired target range) or at least an option here. Maybe even a selection of options from "stacking" to "added" to the initially proposed "max single value". The value of "off" would be more of a temporary solution until balancing gets more stable[4].
• Partial proficiency should result in exactly that: partial proficiency and not a total lack of proficiency.
• Learning at only 5% intervals may need a look to make that more usable for very long duration activities. Maybe turn the 5% into a "over X time units or 5% total duration".

3.2 Long term

• Maybe perform activity duration recalculation if the activity depends on some prerequisites which may have changed during activity execution.
• The lack of cohesion with other concepts may be a bit jarring, but is not something immediately or easily fixable. Nonetheless recipe books could offer some "basic" proficiency bonus. If a book describes a composite task it typically would contain short primers on basic component activities. (Have readable books apply a "virtual" 0-30% (50%?) proficiency bonus depending on the skill level they can teach?).
• Proficiencies need not necessarily always apply to the whole task. Forging a sword certainly may rely on bladesmithing, but a blade is not all that is created here. There is also simple metal heating & forging, creating a hilt & guard. That "partial" task component could be integrated into the curent time_multiplier field per proficiency, per recipe, but that is somewhat of a maintenance issue. It can become hard to figure out what the intended source values were. Maybe a split of values into "applies to X% of task" and "make that part take x times as long" could be used.

---

[1]
An argument can be made that this system is not new, but just a tweaked re-implementation of the skills system. Except there is no rust and scaling is not from [0-10] but from [0-100].

[2]

If a recipe/action requires two proficiencies and the player is not proficient in either, use the harshest penalty of the two. If the player is proficient in one, half the penalty of the other

[3] See "Multiplicative" column here

[4] See "docs/IN_REPO_MODS.md", "Development mods"

which [...] are [...] there to ease the transition between "incomplete feature" and "complete feature", when a feature in the core game is sufficiently incomplete [...].

[I-am-Erk]

So as I said, you've pretty much used up your good will after insulting me for listening but not acquiescing. However, I will briefly address your misconceptions here.

• The proficiencies I listed above were a preliminary list, not exhaustive. See "the overall list would be a dependency tree, this is just to give a quick idea."

• The original proposal had much lower penalties; however, these didn't work in practice. Were we to go back to that we'd need a different stacking system for proficiencies, where high level proficiencies (eg cobbling if you don't even have basic leatherworking skills) would have very high penalties, like 30x and above. The end result would be similar. This way is much easier to implement.

• Again, there is nothing wrong with not knowing enough to be able to craft something.

• It is very common to know that a thing can be done, but not how to do it. Use your noggin'. We all know a backpack can be sewn from cloth, that doesn't mean we know how to set it up in a way that will hold together with a zipper that will readily open and close smoothly.

• The longest time needed to learn a proficiency is such that most proficiencies will be learned after a small number of basic tasks in that area. If you want to learn leatherworking, don't start by trying to make a full suit of leather armour. Make some basic leather items. This is equivalent to real life. If you try to learn miniature painting by tackling a 2' tall cthulhu statue, you will take months and probably mess it up, and you won't really reach the stages needed to gain basic proficiency because you picked a poor start point.

• Several of your concerns are just about planned systems that will be implemented before proficiencies are complete, like proficiencies being in books, or like certain recipes only being autolearn if you have a particular proficiency.

[esotericist]

Here's my reasoning on why I think this thing needs options. Some of the maybe temporarily, some maybe permanently:

"i see concerns with the design that could be improved" is a valid argument. erk was even willing to discuss it with you for a time, before you ramped up the hostility.

"i see concerns so i need to be able to turn off the entire work in progress system" is not a valid argument. this will achieve nothing.

every time we've had a work in progress system that was in active development and let people turn it off, it ended up partitioning players and developers, and resulted in the system taking much longer to get complete.

what you asked for will make development more difficult, slow adoption of the mechanic, slow completion of the mechanic, and fragmenting people playing the game.

this is why kevin said "no, not interested". it's a "hard no" from the team because it's an inherently bad plan, and "more choices is always better" is an axiom that the team in general rejects.

i urge you to reconsider your antagonistic approach to interacting with the team, both displayed in this issue and in your pull request. if you continue to behave in this fashion, don't be surprised if you're asked not to participate further.

[kevingranade]

Wrapping up some issues with your argument that weren't directly addressed.

This isn't being implemented in line with the original proposal

This is irrelevant, this isn't some kind of formal design-by committee thing where a proposal is riddled with compromises before being accepted and is then writ in stone, the implementation evolves continuously as it's being implemented and then afterwards. I.e. the original proposal is not a source of truth, we are.

The new system muddles and conflicts with the existing concepts of recipe knowledge & learning and skill/recipe books. So far a player either knew a recipe (memorized) or had a recipe book which allowed them to perform the corresponding crafting activity. With this new proficiencies system, that knowledge suddenly becomes arbitrary.

There is no conflict, it's an explicit goal of adding proficiencies to separate knowing "what" to make and the details of "how" to make it. It's also not arbitrary, recipes represent knowing the sequence of steps to make something, proficiencies represent knowing how to execute those steps, skills represent ability to execute those steps.

As stated in 1.2 the new system can create very large composite penalties due to the stacking of multiple values all reinforcing each other.

This is the primary point of contention. You've been told several times that this is by design and fully intended. There's no way around it, the goal of this is that certain crafts are practically impossible unless you have the requisite expertise. At the same time we're building facilities into the system for you to gain some of that expertise as you go.

There is very little "fun" for the player in staring at progress bars for the sake of just making things take more time.

You are entirely missing the point here, if you see, "this will take you 1,000 hours to complete", the sensible thing to do is not to just fire it off and grind your way through it, the sensible thing is to do things with lower time investment that will whittle down those penalties until it's achievable. "It's not fun to do it this way" is only a reasonable statement if there are no better alternatives. If grinding away at a huge craft were both boring and highly optimal, you might have a point, but as it is it's just a bad option, so just don't do it.

Maybe perform activity duration recalculation if the activity depends on some prerequisites which may have changed during activity execution.

This isn't completely out of the question, but at the same time even encountering this is a symptom of targeting the largest, most complex crafts with little to no preparation in the first place. The reality is people are told IRL to NEVER do things this way, because it's a terrible way to learn due to the infrequency of feedback and compounding errors.
i.e. if you make something that takes a few hours and there are a few errors, your chances of learning something from it are high. If you make something that takes you a month and it's riddled with thousands of errors, you're unlikely to learn much from it.

[DoctorVanGogh]

@I-am-Erk I would challenge you to point out where the heck I allegedly insulted you. I am pretty sure I did not throw one single iota of an insult at you.
I think my harshest words were "The whole system seems half-cocked" and "someone taking the mickey" directed at the current implementation of a certain aspect of the system. (Shortly after finding a recipe suddenly taking 108 times as long as before).

---

I am also not going to continue to argue this. I had been accused of not having made a case why certain aspect were excessive. That is my case (together with some other side observations about the system).

If the delays are not a mere by-product of the added complexity but one of - if not the main - reason for the complexity.... I would not expect those to change that much.

Also... several people seems to be under the impression that I am particularly invested in the "off" option for the system - which might explain why my points are viewed as so antagonistic - I am not. While that was included in my PR it was merely what felt like a natural extension of my tweaking of the aggregation logic. (Because that conceptually started out as a multi-select option of "default", "more lenient"... and "off" felt like the natural third option to that).

[kevingranade]

This issue has been mentioned on Cataclysm: Dark Days Ahead. There might be relevant details there:

https://discourse.cataclysmdda.org/t/what-are-proficiencies-trying-to-model/24808/2

[Giagantic]

I've talked about this to others but the proficiency system definitely has potential, it helps mitigate the qualitative transition from chicken fodder to strong survivor that'd you'd expect would take a lot of time and experience. Obviously, it is still flawed, mostly because of the monotony of standing there leveling X proficiency especially since it is only on a few recipes.

From my perspective the system should be tweaked in the following ways:

1. Make the time to build only part of the process not the entire system, there are already enough waiting games in the game itself instead the actual construction of the weapon or clothing should be a multi-step process itself. Example, you have to make a billet before you make a blade before you attach a handle and sharpen the blade, this is ignoring multiple other steps such as quenching, the use of various lamination techniques such as San Mai. Basically, the proficiences and the time spent would be split up into multiple parts rather then one giant lump of time sank into a pair of boots.

2. Proficiency and the skills should play a role in the resulting product itself, thus the need to improve your armory overtime and as a result improve your skills. The fact that a blade we made at Fabrication 5 would be the same quality as a blade made by someone with Fabrication 10 coupled with Blacksmithing and Bladesmithing is silly and does contribute to how quickly we go from weak to strong. Such ideas already somewhat exist in the game as is, such as the maces or katana you find in pawn shops often being lower quality compared to the one you craft (because they are cheap knockoffs).

[characterstring]

I know this has been discussed already, but I still want to make a comment from a gameplay perspective. Suppose the survivor wants to make an item "I" with normal crafting time "T". Suppose this item requires three proficiencies, with multipliers M1, M2, M3. The current formula says that the crafting time is T*M1*M2*M3.

Clearly, trying to craft "I" directly is not a reasonable strategy. Instead the survivor will find items I1, I2, I3, such that I1 requires M1 alone, etc. Let's say that the crafting times for the items are T1, T2, T3, the recipes are reversible, and the the deconstruct time is at most the construct time. Then, by learning M1 from constructing and deconstucting T1 etc, all three proficiencies can be learned in time 2*(T1*M1+T2*M2+T3*M3), and then the total crafting time for the goal item I is T+2*(T1*M1+T2*M2+T3*M3). Assuming that T1, T2, T3 are at most T, the total time the survivor should take is at most
3*T*(M1+M2+M3).

Would it be possible to make that the formula? Currently any player can craft the item "I" with no extra use of resources in time at most 3T(M1+M2+M3), but the process is quite convoluted. Perhaps I am missing something.

[Silanxi]

I just wanted to say that I'm completely new to GitHub, so I'm terribly sorry if it's wrong of me to write my thoughts here. I hope no one feels it as a slight or affront to the process in any manner, nor that I'm making a horrible faux pas by writing this here..

Hmm, I have two chief thoughts on this entire idea/system.

Firstly,

I'm wondering if there's a rather sizeable choice the dev team needs to consider here soon:

1. Should the game aim for lots of proficiencies, enabling affecting certain aspects of skill use (mostly uses where it's sensible to say that familiarity plays a large role)
   or
2. Should the game aim for potentially more skills, themselves being granular enough that there's little/no need for proficiencies (e.g. skills like driving, computers, electronics, spellcraft, cutting weapons, Rifles, Unarmed Combat etc. would be split into more specific skills.)

Here's my personal take on this:

• The need for proficiencies stem to a large degree from avoiding the absurdities of characters becoming really good at things without ever doing them, i.e. without familiarity. This could be ameliorated by having an initial uniform "unfamiliarity"/"incompetence" with most crafting recipes and certain item types which would penalize some or all aspects of the skill use (skill success rate, time, reagents, etc.), and a subsequent decline in these penalties to represent familiarization with the skill/item/recipe. This would incentivize various sorts of in-game practice/training, which is a realistic part of any competence/skill as well as fun IMO.
  • (Taking this line of thought further, you could do away with proficiencies altogether if you also added specialized mastery of certain items or recipes: After using the specific item a lot or crafting the specific recipe many times, you would eventually get uniform bonuses to some or all aspects of use, representing mastery. This might, however, have to be made time-consuming enough to avoid it becoming a practical necessity when playing.)
• I'm fairly certain prioritizing somewhat more granular skills would avoid the risk of needing too many too specific proficiencies down the line (myriads of proficiencies would make each proficiency have to be less beneficial and seem less "special", and this might needlessly overcomplicate the game with two equally complex skill-related systems).
• Furthermore, a specification/granularization of skills brings the game a bit closer to realism regardless.

Secondly,

Given that the proposed proficiency system should continue in its current direction (more or less option 1 in my list above), the framework should perhaps enable proficiencies to work in a more generic trait-like manner when involving skill use. Under, I've tried to use various examples to illustrate the particular respective need for a proficiency to affect that certain aspect of skill use.

Having or lacking a proficiency should affect one or more of the following:

• Skill success/fail chance, i.e. the roll/calculation involving the skill level as an integer in any action or crafting "check".

  • Good examples here are acrobatic or martial skills, conversational/social skills, and the piloting/aeronautics proficiency affecting Driving skill. Other examples could be something like fencing, power armor training, non-powered armor training, proficiencies with operating mechs, etc. Proficiency lack here should solely be penalizing the skill check/roll itself.

• Time spent crafting/performing a recipe/action.

  • Examples here could be martial/acrobatic proficiencies slightly affecting move cost, but mostly proficiencies here should apply to meticulous recipes/actions where there's a lot of detailed work and care involved, but where you can also take your time without any sizeable risk of having to start over: tailoring/any textile or fiber work, glassblowing, most "crude" manual crafting, lockpicking, mechanical modification/repairs, electronics, cooking, creative/artistic design?, magical enchanting?, spellcrafting?, computer programming?, scientific research/innovation?

• Amount of reagent needed, whether ingredients or tools/catalysts for a recipe or action.

  • Examples here would be recipes/actions where there's a sizeable chance of ingredient loss/inefficiency. E.g. chemistry, construction, carpentry, mechanical repairs, alchemy?_, most magical crafting?
  • Some proficiencies might also be made to waive/reduce the need for certain materials (or even tools!) needed beyond the default, depending on the nature of the recipe/action.

• Chance of reagent loss/damage, whether it be upon failure or success of the action.

  • I think flat-out reagent loss both is and should be sparse to begin with, and would advise tweaking the initial amount required instead. With particularly valuable reagents (advanced tools, unique/rare reagents, artifacts, etc.), there should be a chance of damage rather than loss, of course.
  • That being said, proficiencies here should be targeted towards improving results beyond the default, IMHO: Breaking your precious "Transcendent netheric mana orb (12000/12000)" by bad luck instead of just emptying it when trying to enchant your electric SUV, or losing your advanced mutagenic mixture when trying to make more anti-blob nanovirus, are never fun gambles no matter the risk, but the prospect of eliminating those risks would make for an enjoyable and fun mechanic for many players, I think.

Again, sorry for the large amount of text, and possible error in posting it here. I just feel that this is major subject that will impact the game to a sizeable extent down the line.

[kevingranade]

Would it be possible to make that the formula? Currently any player can craft the item "I" with no extra use of resources in time at most 3T(M1+M2+M3), but the process is quite convoluted. Perhaps I am missing something.

One of the underlying problems if the system as it exists before proficiencies is that it doesn't resemble the process of learning how to do things in any meaningful way.
The process is the whole point, you need to build out a repertoire of abilities and recipes instead of "find one item per skill level, craft untill you level".

[dissociativity]

for electronics might I suggest microsoldering as a proficiency, the curcuit boards that do more complex things are likely using more modern chips.

[kevingranade]

This issue has been mentioned on Cataclysm: Dark Days Ahead. There might be relevant details there:

https://discourse.cataclysmdda.org/t/a-simple-idea-on-skill-progression-involving-both-theory-and-practice/25462/2

[kevingranade]

This issue has been mentioned on Cataclysm: Dark Days Ahead. There might be relevant details there:

https://discourse.cataclysmdda.org/t/will-there-be-proficiency-books/26222/2