[solved] "inconsistency" in recipes for packing and unpacking ammo boxes

[s_f]

EDIT: Solution in next post.

 

I noticed that the "count" required for packing/unpacking ammo boxes differs by a factor of 5.

Why is this so?  

    recipe Open Box of .556 Ammo
    {
        556Box,

        Result:556Bullets=12,
        Sound:PutItemInBag,
        Time:5.0,
    }

    recipe Place .556 Ammo in Box
    {
        556Bullets=60,

        Result:556Box,
        Sound:PutItemInBag,
        Time:5.0,
    }

 

Edited July 18, 2021 by s_f

[s_f]

Result of a recipe has to be multiplied with the "Count" of the result item's definition.

e.g. for the above case, 556Bullets have a Count of 5 in the item definition

 

    item 556Bullets
    {
        Count	=	5,
        Weight	=	0.025,
        AlwaysWelcomeGift	=	TRUE,
        Type	=	Normal,
        DisplayName	=	.556 Ammo,
        DisplayCategory = Ammo,
        Icon	=	RifleAmmo308loose,
        MetalValue = 1,
    }

    item 556Box
    {
        Weight	=	1,
        AlwaysWelcomeGift	=	TRUE,
        Type	=	Normal,
        DisplayName	=	Box of .556 Bullets,
        DisplayCategory = Ammo,
        Icon	=	RifleAmmo308,
        MetalValue = 40,
    }

 

This seems very unnatural from data perspective though.

I am guessing that this is done by dev because it is easier to generate loot in units of "Count" for "heap type" items of large numbers.

But it creates semantic inconsistency.

e.g. if I say double the count to make 556Bullets appears in units of larger number, say 10, which effectively doubles the number if it found without changing the distribution, it messes up the recipes:

 

Each Box unpacks to 12x10 = 120 bullets now.

But in reverse, it just takes 60 bullets to make a box.

 

Well, it may make some players very happy, but it is still an issue.

 

Suggestion to dev (if anybody is actually reading this in a seemingly semi-abandoned forum/community)

1. Do not use Count in recipes.  only use it for distribution.  (for for backward compatibility, make all count 1, and use another parameter to denote properties related to distribution)

2. Fix the recipes and related systems (multiply the result count by the previous count for the result item type)

^ reason for this is that it won't break any existing mods that currently uses the count to correct recipes.

and also makes the recipes independent of loot generation