Audit: Bash results

[I-am-Erk]

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

Bashing furniture and terrain in game can produce some pretty wacky results, particularly when compared with disassembly of the same stuff. A lot of this is now basically just old code from when we didn't have disassembly options... it's kind of nonsensical to try to bash a fridge for its parts.

Solution you would like.

I have a 'simple' and a 'complex' solution. I consider them roughly equal, they both have advantages and disadvantages.

The Easy Way

Each of these steps can be done independently of each other, and do not require the others to be done! That's part of what makes this way the Easy way.

1. Go carefully through bash entries and where possible have them use standardized itemgroups rather than specifying inline what to spawn.
2. Durable items that can be quick disassembled into a single object should, in general, bash into a damaged version of that object rather than a pile of parts. So if you bash a fridge, you should get the fridge item with a bar or so of damage. This should not apply to easily breakable things like chairs and tables, those should still smash nicely.
3. Add a CI test that checks if a furn/terrain has both a deconstruction recipe and a bash entry, and if it does, check if the deconstruction recipe and the bash results produce a similar mass of products (within a wide margin of error, like neither is more than double the mass of the other eg). If anything is widely out of line, consider filling out the bash result with wood chips or whatever would be appropriate, for example.

Possible extra steps:
4. Adjust bash item entries to have two more fields:
damage_results: true/false, do the listed items get damaged by bashing? The chance of damage should be based on how much damage was done to the bashed object but if true there should always be a decent chance to do anywhere from one to complete damage to the product items.
delicate_items: These items are much more likely to be broken in bashing; if damage_results is false, then these things can still be damaged. If it's true, these take significantly more damage than the rest and should usually be destroyed in the bashing process, but sometimes might survive.

The additions in 4 would allow us to standardize bash result itemgroups to be the same as deconstruction results, but with damage applied causing eg. a lot of 2x4s to spawn as wood splinters instead. That standardization would help a ton to make sure bashing and deconstruction don't need so much parity auditing.

The Hard Way

Fundamentally, bashing is just another type of deconstruction. Rather than having it an inline definition inside the terrain/furniture entry, we could instead make it use construction recipes. The main advantage here is that it would make it clear that bash has the same general structure as deconstruction, and we could frequently use the same recipes for both deconstruction and bash. In the future we might be able to call different bash-deconstruct recipes depending on the type of bashing implement used, so smashing a boat with a sledgehammer yields a lot of splitners while smashing it with a crowbar woudl get you a few more planks and things, eg, or slashing underbrush with a machete would be both easier and produce different results from trying to whack it with a screwdriver. Note that bash recipes would ignore a lot of fields, like time and skill_required.

This would still require us to get into the damage_results stuff specified above, because the major difference between deconstruction vs. bashing for the most part is that bashing should wreck a lot of the stuff you'd salvaged. Doing it this way allows that stuff to get wrecked procedurally and produce the appropriate chunks of material byproducts, rather than arbitrarily doing it by guesswork. That's the major goal here.

This was my initial goal, but after going through it in some detail, for the moment i actually prefer the Easy Way so I won't type more about this up just yet. I might expand it more if people can think of some other advantages to doing it this way.

Describe alternatives you have considered.

I just gave you two alternatives, what more do you want from me.

Of note, the simplest way to go here (and what I think can be started on right now) is just to start auditing bash results and moving similar bash results into itemgroups instead of specifying a bunch of estimated returns.

Additional context

This seems like a pretty zen project (the first few steps) so I might look at plugging away at it a little bit.

[Procyonae]

This might be a weird take but the easy way kind of sounds like a waste of your time, it does little to change gameplay nor improve the system for future changes and would make new additions more tedious
The hard way sounds like a great improvement to the system but I don't envy anyone taking it on

[GuardianDll]

Yeah, good question is how much of work from "easy way" could be salvaged to the "hard way"?

[I-am-Erk]

What part of the easy way don't you think is useful?

• Bash results currently are often wildly random, moving them to standardized item groups would change what you get in bash results, which has a direct impact on gameplay, and it's easier to determine what to use for bash results if we have a smaller range of already well-supported itemgroups for it.
• CI testing improves the system for future changes by ensuring we don't run into this problem again.
• Allowing more detail on how bashing removes/harms the products is directly impactful.

I'm not quite sure what you mean.

The hard way would do all this same stuff, but putting things into a recipe is a nice way to compartmentalize them and make it all a bit clearer. It otherwise is exactly the same change.

[Procyonae]

• Bash results currently are often wildly random, moving them to standardized item groups would change what you get in bash results, which has a direct impact on gameplay, and it's easier to determine what to use for bash results if we have a smaller range of already well-supported itemgroups for it.

I don't see how this would be useful if/when the hard way gets implemented, merging the bash and deconstruction recipes
I appreciated it has non-zero gameplay impact I just don't think it's enough to justify it on it's own

• CI testing improves the system for future changes by ensuring we don't run into this problem again.

I don't have anything against more CI testing but again if they're going to being merged together anyway checking the differences between them doesn't achieve anything

• Allowing more detail on how bashing removes/harms the products is directly impactful.

I agree with that but wouldn't this make the hard method more work to implement instead of the other way around bc you'd have larger more complicated json bash entries to merge? (I appreciate the code that supports it would obviously be reusable?

I could well have just misread or be misinterpreting your OP again, sorry if that's the case, equally I'm not saying don't do this if you want to I'm just saying you do pretty cool stuff and this doesn't seem like a great use of your time

[I-am-Erk]

It's an either-or I'm describing here, not a one then the other. Either someone takes up the torch of revamping the whole system, which would be great for consistency but a lot of work, or we just solve it with what we currently have and some smaller tweaks

[GuardianDll]

well, it's kinda pointless to make some changes, that will be deleted as soon as someone more brave decide to make a better system

[I-am-Erk]

You're not following. We don't need to do the whole standardization thing. It's an option, but it isn't necessary. We should not hold off on a fairly important balance fix in the hopes that someone might in the next ten years decide to take on a big restructuring project... If someone wants to do that fix, it's a great idea, but it's nowhere near important enough to block a more important balance adjustment.

[Zireael07]

@GuardianDll You are only right IF that better system DOES happen and DOES so in a reasonable timeframe. CDDA already has several of those "let's make a better X" that never happened and are forever 2 years away or more

[vetall812]

I wonder if we can use multiple itemgroups and if we can multitply them.
An example: Lets suppose that construction path for a wooden wall is:

• t_floor_wood > t_wall_wood_half (-10 planks, -20 nails)
• t_wall_wood_half > t_wall (-2 wooden panels, -20 nails)
• t_wall > t_wall_red (-3 paint)

so lets also assume that we have following itemgroups:

• wall_removal_results : 0-1 wooden panels, 5-10 nails
• wooden_half_wall_removal_results : 2-5 planks, 5-10 nails
• wooden_wall_prebuilt_bash_results : 0-1 pipe, 0-5 cable
• wooden_wall_bash_results : 1-5 splinters

then results can be:
Bash:

• t_wall_red | t_wall > t_wall_chipped + wooden_wall_bash_results x 1-2
• t_wall_chipped > t_wall_broken + wall_removal_results x 0-2, wooden_wall_bash_results x 2-5
• t_wall_broken > t_floor + wooden_half_wall_removal_results x 0-2, wooden_wall_bash_results x 2-5

Deconstruct:

• t_wall_red > t_wall + nothing
• t_wall > t_wall_wood_half + wall_removal_results x 2
• t_wall_broken > t_floor + wooden_half_wall_removal_results x 2

I also would like to propose construction/deconstruction/breaking/repairing unification:

istead of this:

something like this:

removing / bashing the floor is a different problem, because of different results on different z-levels.

[GuardianDll]

multiple itemgroups and if we can multitply them

We can, and it's kinda the point of this issue

about walls advancements and degradation it's another giant can of worms, main issue of which is the terrain never knows what is above said terrain. meaning we need manually define floor for each terrain in the game, which result in stuff like us having 30+ type of wooden doors with only difference be ter_set they use