Cataclysm-dda: Size / Weight / Volume of monsters granularity

[nexusmrsep]

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

This problem emerged along with introduction of non-standard creatures like dog breeds, and re-evaluation of meat yield per creature size. Those two changes resulted it some non-optimal meat yield counts for creatures that should not be that big/small, and in consequence showed that existing granularity of interdependent Size / Weight / Volume has reach it's limits.

Describe the solution you'd like:

• Add "in-between" sizes and support for them,
  
  
  
  • Re-balance whatever an wherever is needed,
  
  
  • Reapply sizes to JSON-ized creatures.
  
  

| SIZE | REFERENCE | WEIGHT | CORPSE VOLUME | MAX MEAT CHUNKS |
|------------|-------------|------------|-------------|--------------|
| MS_TINY | Squirrel, snake | 1000_gram | 750_ml | 2 |
| MS_VERY_SMALL | Dog: dachshund |10000_gram | 7500_ml | 16 |
| MS_SMALL | Dog: labrador | 40750_gram | 30000_ml | 64 |
| MS_SMALL_MEDIUM | Dog: rottweiler | 60000_gram | 46250_ml | 96 |
| MS_MEDIUM | Human | 81500_gram | 62500_ml | 128 |
| MS_MEDIUM_LARGE | Bloated zombie | 100000_gram | 77500_ml | 160 |
| MS_LARGE | Cow | 120000_gram | 92500_ml | 192 |
| MS_EXTRA_LARGE | Zombie hulk, moose | 160000_gram | 483750_ml | 256 |
| MS_HUGE | Tank Drone | 200000_gram | 875000_ml | 320 |

Disclaimer: above values were not changed for existing sizes written in bold. Values for new "in-between" sizes are rough in-between values of existing sizes.

Describe alternatives you've considered
I leave the alternatives to be discussed here.

Additional context
Reference: #24909, #24921, #25244 & #25248, #24878

[MT-Arnoldussen]

I like it, but the names might need some work.

[FulcrumA]

I like this idea. However, while mitigating the problem it may not solve it completely. Various creatures have similar overall size but various mass. This is certainly an improvement over what we have but I suspect in case of some animals, some sort of custom values for volume/weight (with a few percent margin of randomization) would do better.

[MT-Arnoldussen]

Custom values would need each animal to be somewhat researched though. I think a system with a more limited amount of sizes is a more feasible idea.

I do like animals having a few percent margin of randomization in size/volume. This would make it less glaringly obvious that animals are often the exact same size and weight.

[mlangsdorf]

I'd really prefer to move to listing precise weight and volume in the creature entry (or mass and density, or density and volume, whatever). Then have functions get_weight(), get_volume(), and get_size_category().

Looking through the code:
activity_handlers::setup_butchery would call get_volume() to determine time to cut.
activity_handlers.cpp butchery_drops_hardcoded would call get_volume() to determine yield.
game::forced_door_closing would call get_size_category()
game::emp_blast would call get_set_category()
item::corpse_volume would call get_volume(), and the quartering check would be reduced to if( volume > SOME_VAL ) volume /= 4;
item::weight would call get_mass()
item::contain_monster would call get_mass()
iuse::camera would call get_size_category()
monattack.cpp blobify would call get_size_category()
mdeath::explode() would call get_size_category()
ranged.cpp ranged_target_size() could either call get_volume() or get_size_category()
trapfunc::crossbow() and trapfunc::shotgun() would call ranged_target_size()
trapfunc::snare_func() could just do fixed damage regardless of creature size.
vehicle::part_collision would call get_mass()

We can keep the existing size categories for the parts of the code that care about them, and the parts that care about weight and volume can get an exact number.

Randomizing the values to provide more variation sounds interesting, but then that's another thing to add to the save file so I'm against it.

I would probably record creature mass, and set density by creature type: living things are all density 0.95, robots are density 7, etc. and then get_volume() calculates volume on the fly but that's an implementation detail inside of creature.cpp and the butchering code just calls get_volume().

[MT-Arnoldussen]

Well if you do it via the creature entries, then the size categories could just become a function that turns weight into a category.

[mrkybe]

My vote is for @mlangsdorf 's solution.

[mlangsdorf]

Right, internally, get_size_category takes the volume or weight and spits out a size category and it's a black box for all other parts of the program.

Actually, a couple of the other ones could call get_volume and set some breakpoints based on volume.

[CoroNaut]

Lets hope the meat amount per corpse is balanced though, As I see it, between medium large and ms_small, they could all be reclassified and have less meat chunks. There is a huge gap between very small and small that makes it balancing this unclear.

[mlangsdorf]

I would estimate total salvage based on weight, with a decreasing percentage as the animal gets larger:

Mass | % Recovered | Weight
---- | ----------- | ------
1 kg | 55% | 550 g
10 kg | 50% | 5 kg
100 kg | 45% | 45 kg
1000 kg | 40% | 400 kg

Recovery percentage is 55% - 5* log( mass ). So it scales smoothly between masses, there's no breakpoints. For example, choosing some random masses:

Mass | % Recovered | Weight
---- | ----------- | ------
7 kg | 50.8% | 3.55 kg
27 kg | 47.8% | 12.9 kg
450 kg | 41.7% | 187 kg
1200 kg | 39.6% | 475 kg

[kevingranade]

I agree it seems like a waste of effort to only partially resolve the issue
by introducing new size classes, I'm very much in favor of setting specific
mass and volumes.

We can potentially set mass ranges instead of a single value while we're at
it.

[pikolinianita]

I'd like few "flags" to mark creatures with more meat per mass (like domestic pigs or cattle, wild animals in autumn) or less (for cyborg-like creatures, armoured ones (like turtles) or fat ones (where fat replace some meat), or starving ones (winter/early spring time) ).
Could be +20% for former and two (-25% and -50%) for latter.