Monster weight / volume granularity #25631

nexusmrsep · 2018-09-15T18:39:27Z

Summary

SUMMARY: Infrastructure "Converts monster size to weight and volume."

Purpose of change

Resolves #25298 Resolves #24921 Resolves #24909
Many game features use monster size classes to determine some effects. While this is a decent method for some cases, in other, like butchery, makes proper balancing impossible because lack of granularity.

Describe the solution

This PR does following things:

introduces weight and volume variables to monsters in mtype
introduces automatic conversion of volume to size class via volume_to_size method
Conversion table below shows how middle values between existing hardcoded weights and volumes (also presented below) were used to determine delimiter (borders) between size classes.

SIZE	REFERENCE	CORPSE VOLUME
MS_TINY	Squirrel, snake	750_ml
BORDERLINE	------------	7500_ml
MS_SMALL	Dog	30000_ml
BORDERLINE	-------------	46250_ml
MS_MEDIUM	Human	62500_ml
BORDERLINE	---------------	77500_ml
MS_LARGE	Cow	92500_ml
BORDERLINE	--------------	483750_ml
MS_HUGE	Tank Drone	875000_ml

removes decoding size entries from json monster files and add decoding volume and weight from them
in JSON files for monsters replaces "size" with "volume" and"weight", that were set at previously hardcoded weights and volumes (presented above)
This of course asks for a general refactor of those values according to some more sane values in many cases (example: most dogs weight over 40 kg)
method get_meat_chunks() that is a primary function to determine main butcher yields was redesigned to use monster's weight instead of size class. It has also been given dependency on 'meat' type to dynamically resolve number of maximum yielded items as some creatures yield not "meat" per se, but thinks like "tainted meat", "veggies", etc. that might have different weight. In general this new calculation follows @mlangsdorf idea for a function from Size / Weight / Volume of monsters granularity #25298 , but I've lowered its base value and flattened its regression, to keep it around 33% of body mass. It's final (?) form is:
weight * ( 0.4 - 2 * ln( weight ) ) divided by mass of a proper 'meat chunk'
Typical results in %:

WEIGHT in kg	YIELD in % body mass	MEAT count
1	40%	2
5	36.7%	9
10	35.3%	18
20	34%	34
50	32.1%	80
100	30.8%	154
200	29.4%	294
300	28.5%	429

This is of course dynamic, so different weights of creatures will result in granular effects.

Describe alternatives you've considered

Alternative was granulating size classes, even after introducing this PR, but a need for that would have to emerge, and there are too many places where they are uses, that would need rebalancing.

Additional context

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

WARNING

untested - TEST BEFORE MERGING
will affect unsupported mods to fix their monster json files to use weight and volume instead of size

also changes meat chunks calculation

SunshineDistillery · 2018-09-15T21:46:01Z

Does it check the monster's material? Non-meat monsters should have different density/weight.

nexusmrsep · 2018-09-15T22:26:35Z

@SunshineDistillery this is an infrastructure conversion for the starters, any re-balancing and improvement will need to be done later.

brianlewisbeck · 2018-09-18T20:09:57Z

mtype::get_meat_chunks() forced corpses into 5 possible sizes. All corpses of the smallest size (tiny) were 1 kg; all corpses of the next smallest size (small) were 40 kg. There is a huge gap between 1 and 40kg.

nexusmrsep · 2018-09-18T20:15:05Z

@brianlewisbeck I have no idea what are you trying to tell here. This PR is all about changing that so... whats your point?

brianlewisbeck · 2018-09-18T20:27:04Z

Sorry - guess I was thinking out loud. Does the issue relate to any of the other sizes? If not, would it be possible to keep the existing framework but add subcategories to small? Seems like that would be a lot easier.

nexusmrsep · 2018-09-18T20:37:30Z

Does the issue relate to any of the other sizes? If not, would it be possible to keep the existing framework but add subcategories to small? Seems like that would be a lot easier.

To put it simple: when coding a new monster in JSON you will be able to define its weight and volume instead of forcing it into any constraints. For example you could say your new dog breed now weights 7 kg and is 15 liters of volume. Specific in game calculations would then use that value - for example to calculate meat chunks count, or if it just needs a category of size it would use a size class like before, but that class would be calculated from the given volume - for ex. 15 liter dog falls into MS_SMALL category.

Adding subcategories is not an option now - would require to rebalance "half" of the game.

mlangsdorf · 2018-10-01T15:10:58Z

is there a plan to replace the existing calls to get_size() where appropriate? Replacing the call in vehicle_move.cpp:part_collision() to critter->get_size() and the resulting switch/case set to get critter mass with get_weight(), for instance?

Or do you just plan to do this infrastructure and let the rest of us sort it out, which is fine, just want to know the plan.

nexusmrsep · 2018-10-02T05:09:17Z

If there is an obvious function that uses get _size while it should use true weight or volume then yes. However the only one that I considered obvious was butchery yields up until now. If it would be intuitive for me to incorporate the one you mentioned then I'll try, but if not I'll pass. I will not change or balance creatures’ values either, just the infrastructure for it.

Second thing is that my free coding time got extremely scarce lately and I've got two other WIP not yet published PRs on the bench that slow me down in finishing this one. I just hope I'm closing in on finishing them.

mlangsdorf · 2018-10-07T19:32:16Z

I listed every use of MS_SIZE I could find in the code in my first response in #25298. But if you're too busy, I totally understand and can clean up the vehicles code on my own after you've got this merged. Like I wrote, I don't hugely care what the answer is, I just want to know the plan. If you're only going to make the infrastructure and butchery changes, that's fine and I won't ask you to change the vehicles code if I review this PR.

nexusmrsep · 2018-10-08T17:25:30Z

@mlangsdorf First of all thanks again for your help on fixing few issues with this PR.

I'm not too confident to touch mechanics other then butchery to translate them to weigh/volume (this would require more conceptual work to perceive the desired effect), neither have time to do it. Same for setting correct values for monsters - that might need some extra research, and involving our community would be the best approach.

So I've evaluated my take on this, and I think its best to provide this infrastructure as is to allow the community to take over from here and apply weight and volume however it's best - both in switching mechanics from size categories to actual weight/volume and also in setting individual weight and volumes for monsters in JSON files.

nexusmrsep · 2018-10-08T17:28:44Z

I'm removing [WIP] from this PR but please TEST BEFORE MERGING.

data/json/monsters.json

ZhilkinSerg · 2018-10-23T21:04:31Z

data/json/monsters.json

@@ -7,7 +7,8 @@
    "default_faction": "",
    "species": [ "ZOMBIE" ],
    "diff": 100,
-    "size": "MEDIUM",
+    "volume": "62500 ml",
+    "weight": "81500",


Why not "weight": 81500 instead of "weight": "81500"?

And in this I will regex quote marks into oblivion ASAP.

src/game_constants.h

BevapDin · 2018-10-24T14:05:17Z

src/monstergenerator.cpp

@@ -547,8 +548,10 @@ void mtype::load( JsonObject &jo, const std::string &src )
    }

    assign( jo, "color", color );
-    const typed_flag_reader<decltype( Creature::size_map )> size_reader{ Creature::size_map, "invalid creature size" };
-    optional( jo, was_loaded, "size", size, size_reader, MS_MEDIUM );
+    //const typed_flag_reader<decltype( Creature::size_map )> size_reader{ Creature::size_map, "invalid creature size" };


Please do not check in commented out code.

good call, didn't even noticed that I left it behind

BevapDin · 2018-10-24T14:06:51Z

src/mtype.cpp

@@ -52,6 +57,23 @@ std::string mtype::nname( unsigned int quantity ) const
    return ngettext( name.c_str(), name_plural.c_str(), quantity );
 }

+m_size mtype::volume_to_size( const units::volume vol ) const


Why is this a non-static functions? It does not access any of the members of mtype, it does not needthe implicit this pointer. Make it a static function.

ok, this requires moving it to monstergenerator.cpp, I thought it might be more universal in the future by placing it in mtype, but lets leave the future to govern itself.

BevapDin · 2018-10-24T14:09:57Z

src/mtype.cpp

+{
+    if( vol > 0_ml && vol <= 7500_ml ) {
+        return MS_TINY;
+    } else if( vol > 7500_ml && vol <= 46250_ml ) {


You don't need the first check, write it like this instead:

if( vol <= 7500_ml ) { return ...; } else if( vol <= 46250_ml ) { return ...; } else if( vol <= ...

The second if clause will only be reached if vol > 7500_ml, which does not need to be cecked again.

I just hope there will be no situation where vol == 0 then...

BevapDin · 2018-10-24T14:12:12Z

src/mtype.cpp

-    return 0;
+    float ch = units::to_gram( weight ) * ( 0.40f - 2 * log( units::to_gram( weight ) ) );
+    const itype *chunk = item::find_type( get_meat_itype() );
+    return static_cast<int>( ch / units::to_gram( chunk->weight ) );


units:: is not needed when calling to_gram with a units::mass argument, the C++ compiler will find it anyway thanks to ADL.

src/creature.h

src/monstergenerator.cpp

Co-Authored-By: nexusmrsep <[email protected]>

nexusmrsep · 2018-10-28T11:26:27Z

Removed quote marks (") on weight and applied @BevapDin suggestions (thanks for the review). It's all yours @ZhilkinSerg.

ZhilkinSerg · 2018-10-28T11:32:25Z

Great. Will test it again tonight.

GoLoT · 2018-10-30T13:50:30Z

I'm not sure if this is the place or the way to report it but this commit has broken butchering completely. I can't debug because the latest experimental refuses to compile under VS but I have taken a look at the commit and I think it has to do with how the mass percent calculation is done:

float ch = to_gram( weight ) * ( 0.40f - 2 * log( to_gram( weight ) ) );
This line seems to be using weight in grams instead of kilograms which causes the calculations to be way off. The percentage calculation also seems wrong as 2*log(w) should be substracted from 40 and not 0.4, causing ch to always be a negative number and making every butcher attempt fail.

A quick fix that I can't test at the moment could be:
float ch = to_kilogram( weight ) * ( 0.40f - 0.02 * log( to_kilogram( weight ) ) );

And then divide by the chunk weight in kilograms:
return static_cast<int>( ch / to_kilogram( chunk->weight ) );

EDIT: Now that I think of it, once the percentage is calculated it can be applied to the weight in grams and the return statement doesn't need to be changed. So this should do:
float ch = to_gram( weight ) * ( 0.40f - 0.02 * log( to_kilogram( weight ) ) );

ZhilkinSerg · 2018-10-30T14:20:08Z

src/mtype.cpp

-            return 320;
-    }
-    return 0;
+    float ch = to_gram( weight ) * ( 0.40f - 2 * log( to_gram( weight ) ) );


Should be:

float ch = to_gram( weight ) * ( 0.40f - 0.02f * log10( to_gram( weight ) ) );

Todo ASAP today.

jbytheway · 2018-10-30T14:41:32Z

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Monster weight / volume granularity #25631

Monster weight / volume granularity #25631

nexusmrsep commented Sep 15, 2018 •

edited

Loading

SunshineDistillery commented Sep 15, 2018

nexusmrsep commented Sep 15, 2018

brianlewisbeck commented Sep 18, 2018

nexusmrsep commented Sep 18, 2018

brianlewisbeck commented Sep 18, 2018

nexusmrsep commented Sep 18, 2018

mlangsdorf commented Oct 1, 2018

nexusmrsep commented Oct 2, 2018

mlangsdorf commented Oct 7, 2018

nexusmrsep commented Oct 8, 2018

nexusmrsep commented Oct 8, 2018

ZhilkinSerg Oct 23, 2018

nexusmrsep Oct 24, 2018

BevapDin Oct 24, 2018

nexusmrsep Oct 28, 2018

BevapDin Oct 24, 2018

nexusmrsep Oct 28, 2018

BevapDin Oct 24, 2018

nexusmrsep Oct 28, 2018

BevapDin Oct 24, 2018

nexusmrsep commented Oct 28, 2018 •

edited

Loading

ZhilkinSerg commented Oct 28, 2018

GoLoT commented Oct 30, 2018 •

edited

Loading

ZhilkinSerg Oct 30, 2018

nexusmrsep Oct 30, 2018

jbytheway commented Oct 30, 2018

Monster weight / volume granularity #25631

Monster weight / volume granularity #25631

Conversation

nexusmrsep commented Sep 15, 2018 • edited Loading

Summary

Purpose of change

Describe the solution

Describe alternatives you've considered

Additional context

WARNING

SunshineDistillery commented Sep 15, 2018

nexusmrsep commented Sep 15, 2018

brianlewisbeck commented Sep 18, 2018

nexusmrsep commented Sep 18, 2018

brianlewisbeck commented Sep 18, 2018

nexusmrsep commented Sep 18, 2018

mlangsdorf commented Oct 1, 2018

nexusmrsep commented Oct 2, 2018

mlangsdorf commented Oct 7, 2018

nexusmrsep commented Oct 8, 2018

nexusmrsep commented Oct 8, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nexusmrsep commented Oct 28, 2018 • edited Loading

ZhilkinSerg commented Oct 28, 2018

GoLoT commented Oct 30, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jbytheway commented Oct 30, 2018

nexusmrsep commented Sep 15, 2018 •

edited

Loading

nexusmrsep commented Oct 28, 2018 •

edited

Loading

GoLoT commented Oct 30, 2018 •

edited

Loading