feat(balance): extend and improve ranged_bash_info to allow taking cover behind furniture

[chaosvolt]

Purpose of change

This improves how ballistic resistance data for terrain/furniture bashing is used. Not only does it extend it to be accessible by furniture, it sets it up to be used for some basic cover mechanics to finally increase one's options a bit beyond the level of "block line of sight so enemy can't shoot me but I can't shoot them" along with a few assorted improvements to the underlying code.

Describe the solution

C++ changes:

1. In map.cpp and map.h, fleshed out map::shoot considerably. The big one of course is now furniture can support ranged_bash_info in addition to terrain. In addition, the function now grabs the position of the shooter, and if block_unaimed_chance is used by the terrain/furniture in question, the shooter can shoot over adjacent obstacles unimpeded. This allows you to, for example, take cover by standing behind a sandbag barricade and have it potentially negate enemy shots without blocking yours. Set up the way it is so you can't exploit this to shoot clean through stuff like full-on sandbag walls or ballistic glass just by standing next to it. Shots that have damaged reduced but not negated also now print a message so it's more clear that successful intercepts are actually happening, but now the intercept messages only print if there's actual RNG involved in whether it blocks the shot (i.e. if block_unaimed_chance is set, that way it doesn't spam intercept messages for stuff that will always block shots like ballistic glass). Lastly, the effect of potentially destroying the terrain being hit was moved to print AFTER the add_msg section, preventing cases where the message says your bullet punched through "nothing" because it detroyed a sandbag barricade that intercepted the shot.
2. Updated uses of map::shoot in ballistics.cpp and ranged_aoe.cpp to pass the new origin value to the function. In the latter case, origin and target points are identical to allow for AoE cones to bypass cover randomized cover entirely.

JSON changes:

1. Defined ranged bash data for most furniture to possess a coverage value. reduction tends to be close to str_min for thin stuff not typically expected to soak up bullets, while stuff clearly expected to protect you like sandbags use values closer to or sometimes above their str_max. destroy_threshold generally tends to either match str_max or be a bit higher or lower depending on which made more sense. Any that are also TRANSPARENT gain a block_unaimed_chance roughly modeled after their coverage value.
2. Fixed some oddball furniture lacking TRANSPARENT like washing machines, driers, smaller grid batteries etc, and thus giving their ballistic data block_unaimed_chance.
3. Adjusted coverage and bash strength values of a few furns for consistency.
4. Misc: Set steel targets to drop a steel plate instead of metal sheets plus pipes when bashed, be easily deconstructed, and in general beef it up so basic pistol rounds will bounce off it. Idea being a static target instead of a popup target, since you can't have non-penetrating hits destroy the target.
5. Added references to the feature in description of sandbag/earthbag/road barricades, to main menu tips, and NPC hints.
6. Updated Magiclysm furniture accordingly, only furniture with coverage values I could find.

Describe alternatives you've considered

1. Setting execute_shaped_attack's use of map::shoot to use origin instead of p for its first argument, but I'd be leery of that since we probably want some AoE attacks to ignore cover entirely. But we might also want some to not ignore cover...augh.
2. Hacking together some way to make effective block_unaimed_chance high if the target is crouching.

Testing

1. Checked affected JSON files for syntax and lint errors.
2. Compiled and load-tested.
3. Spawned in a debug monster behind some sandbag barricades.
4. Fired a couple different guns at it, confirmed it randomly tanks some of the shots and hits the sandbags. M249 is negated outright hen it triggers, M240 and M2 can punch through but don't destroy the sandbags.
5. Shot at a steel target. Takes rifle bullets to knock through it, and it won't tip over unless punched through but is a start.

Additional context

I plan to follow up on this with two additional updates:

1. Going over terrain that already have this defined to sanity-check coverage and ballistic resistance values to be consistent with what all the furniture is set to.
2. Going over various other terrain and furniture entries that lack coverage and/or ballistic resistance defined, using this feature to fix a lot of cases of solid walls (like brick and concrete) being easily destroyed by arrows and bullets.

Checklist

[chaosvolt]

I forgot I'd started messing with an earlier failed attempt to implement this idea on my laptop under a branch of the same name, augh

[scarf005]

i think this line should be programmatically generated for all terrain that has bash.ranged, unless it'd be too much code duplication.

[chaosvolt]

That'd be a bit of effort yeah. We'd also have to restrict it to only ones that use block_unaimed_chance.

[scarf005]

Any that are also TRANSPARENT gain a block_unaimed_chance roughly modeled after their coverage value.

maybe block_unaimed_chance should be computed from TRANSPARENT and coverage?

overall, i think it may be better in the long term to avoid manually computed values as much as possible and prefer computed properties.

[chaosvolt]

maybe block_unaimed_chance should be computed from TRANSPARENT and coverage?

That's gonna be a pain in the ass, yeah. Biggest issue with it though is just the fact that block_unaimed_chance is used in the function like this: !check( rfi.block_unaimed_chance ) That means it gets rolled for the instant it's referenced, so we'd need to instead replace it with a value automatically calculated from coverage and rework the math to do it that way, and then also likely audit coverage values so they fit neatly into the 25/50/75 percentages I've favored so far...

[scarf005]

maybe we could still keep block_unaimed_chance, but also auto populate into 25%, 50% or 75% using TRANSPARENT and coverage?

[chaosvolt]

I just realized another issue with making this use coverage: a closed window logically should stop shots 100% of the time, but it needs coverage defined in order for the "crouch behind it to hide" behavior to work. Working around that would require it to treat coverage as 0% by default if unspecified instead of 100%, and then to work around THAT we'd have to specify a whole fuckload of terrains with explicit 100% coverage...

EDIT: The window problem is also the definitive example of why auto-generating it from "transparent and has coverage" at all is probably more pain than it's worth.

[scarf005]

a closed window logically should stop shots 100% of the time, but it needs coverage defined in order for the "crouch behind it to hide" behavior to work.

sorry, i don't follow, shouldn't closed window have 100% coverage?

also, pls check discord

EDIT: after offline discussion, yes i now understand window shouldn't have 100% coverage because it'd be half wall and half glass, and coverage affects crouching

[chaosvolt]

Gonna hope this goes well then, had done some more testing and faffing about so...