You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently all creatures are defined in their Size/Weight by picking from the following table:
Size
Volume
Weight
MS_TINY
750ml
1KG
MS_SMALL
30L
40.75KG
MS_MEDIUM
62.5L
81.5KG
MS_LARGE
92.5L
120KG
MS_HUGE
875L
200KG
And then the following modifiers depending on the primary material
Modifier
Divide By
Multiply By
Made from 'Veggy'
3
-
Is an Fish, Bird, Insect, or made from Bone
8
-
Made From Iron, Steel or Stone
-
7
This indirectly affects butchery and wilds living because a Deer is a MS_LARGE creature, and 92.5L/120KG is beyond most forms of cargo transport available early on (Travois, Wheelbarrow) in those playthroughs.
After field dressing the weight should reduce by 1.26~, so now a carryable 90KG for a deer. Though deer should probably be Medium. Butchery is a side-issue and will eventually provoke an overhaul of how monster sizes are defined.
The proposal then is to (for now) keep the Size Categories, but introduce random variations within those values of a 10-15% swing either up or down, with a view to in the future discarding the MS_ categories and using raw weight first by abstraction and variation, then later by JSON loading the values.
The text was updated successfully, but these errors were encountered:
Currently all creatures are defined in their Size/Weight by picking from the following table:
And then the following modifiers depending on the primary material
This indirectly affects butchery and wilds living because a Deer is a MS_LARGE creature, and 92.5L/120KG is beyond most forms of cargo transport available early on (Travois, Wheelbarrow) in those playthroughs.
After field dressing the weight should reduce by 1.26~, so now a carryable 90KG for a deer. Though deer should probably be Medium. Butchery is a side-issue and will eventually provoke an overhaul of how monster sizes are defined.
The proposal then is to (for now) keep the Size Categories, but introduce random variations within those values of a 10-15% swing either up or down, with a view to in the future discarding the MS_ categories and using raw weight first by abstraction and variation, then later by JSON loading the values.
The text was updated successfully, but these errors were encountered: