Hi WhiteThunder!

I'm having a problem with 'Output multipliers' specifically metal.refined. Going off your example config I believe the shortname is correct, no matter its value I only get 100 hqm for 100 pipes. I tried changing the Default Multiplier and am getting more scrap but not HQM, and using metal.fragments works. Here is my example not working for HQM.

"Output multipliers": { "Default multiplier": 1.0, "Multiplier by output item short name": { "metal.fragments": 3.0, "metal.refined": 10.0 } },

Do you have an override enabled for pipes? I recall there's a limitation where the override isn't affected by output multipliers, and I never really reconciled those two features.

No, everything is default except that and the 'Default recycle time (seconds)'. I did try with rifle bodies and it is working, springs it does not.

Try something for me.

if (amountToCreatePerConsumedItem > 1 && outputMultiplier > 1)

Replace with:

if (amountToCreatePerConsumedItem >= 1 && outputMultiplier > 1)

That should work for pipes, but for other cases, will need another change I think.

Edit: Actually, try this (replace existing method of same name):

private static int CalculateOutputAmount(int amountToConsume, float amountToCreatePerConsumedItem, float outputMultiplier = 1, bool alwaysRoundUp = false)
{
    if (amountToCreatePerConsumedItem > 1 && outputMultiplier > 1)
    {
        // Round up to make sure vanilla fractional amounts are multiplied accurately.
        amountToCreatePerConsumedItem = Mathf.CeilToInt(amountToCreatePerConsumedItem) * outputMultiplier;
    }
    else
    {
        amountToCreatePerConsumedItem *= outputMultiplier;
    }
    
    if (!alwaysRoundUp && amountToCreatePerConsumedItem < 1f)
    {
        if (amountToConsume <= 100)
        {
            return CalculateOutputAmountVanillaRandom(amountToConsume, amountToCreatePerConsumedItem);
        }
        else
        {
            return CalculateOutputAmountFast(amountToConsume, amountToCreatePerConsumedItem);
        }
    }

    return amountToConsume * Mathf.CeilToInt(amountToCreatePerConsumedItem);
}

This issue stems from trying to match vanilla nuances, such as items that recycle to less than one use randomization, whereas items that recycle to greater than one round up. I will have to think a bit more about this before pushing an update.

Edit: I changed the above code again because I forgot about multipliers below 1.

The new method seems to work. Thanks for your time have a great day! :)

I think I got it properly sorted now. Please download from GitHub and test it out. What I needed to do was apply the vanilla logic (round up if output is greater than 1) before applying the output multiplier, in all cases. That way, if you are comparing the vanilla amount to the multiplied amount, it'll match expectations. That's pretty close to what I have above, but that code didn't work right for output multipliers below 1.

A good test case was the .556 ammo which has 83.33% chance to produce gunpowder in vanilla. I tested with 0.5, 1.0 and 2.0 global multipliers, with stacks of 100 and 1000. Also tested with gears (which rounds metal fragments from 12.5 to 13 in vanilla), m249 (50% chance for rifle body) and pipes.

Hi! This version does seem a lot more realistic. I actually was messing around with ammo too, trying to figure out if you could change this value by .1 and it didn't seem like it, but now it does. so 'chance' in the game is just a multiplier less then 1? I'm surprised we can't do items by wildcard and category, but that's not a big deal. Thanks for this quick fix and again for your time, love what you're doing for the community.

Vanilla recycling basically works like this.

• For each crafting ingredient, divide by 2. If the result is greater than 1, round up to determine the output amount. If the result is less than one, that is the chance the ingredient will be given. For example, if the crafting cost is 3, the recycle output is 2 (rounded up from 1.5). If the crafting cost is 1, the recycle output is a 50% chance for 1.
• Once the output amount or chance is calculated, if it's greater than on 1, it's also a whole number, so that amount is multiplied by how many items are being recycled to determine the total output. If the output amount is below 1, the game rolls a random number to determine whether to give the ingredient. A random number is rolled for every item in the stack (though the plugin optimizes this for stacks greater than 100, for performance reasons, though losing some randomness as a result).
• If the crafting recipe outputs multiple items, like ammo, then the output amount is first divided by that by number so you can't get back more than you spent. That's why the ammo returns are often decimals.
• If a crafting recipe includes scrap, that is ignored. That is why workbenches don't recycle into scrap. However, many items do produce scrap because they have a specific scrapFromRecycle number set on the recipe.
• If the item has a max stack size of 1 and has condition enabled, the recycle output is also reduced according to the current item condition early in the calcilations.
• Each recycler has a property called recycleEfficiency which determines how much of the ingredients you get back, but it's always 0.5, and I don't know of any plugins that alter it. I was originally trying to accommodate plugins that might change it, but the output override feature didn't play nice with it as it would become confusing, so the plugin hard codes 0.5 into the calculations.

• Allow output multipliers to apply after output override. This would probably be a simple toggle, but the main challenge is accommodating it in the UI because I don't have a good way to represent items that can output 2.5 for example, though the plugin now accommodates that in the actual recycling logic if your multipliers produce such a number (would be 2 + 50%).
• Allow min and max output, and chance to produce output of greater than 1. Rust doesn't really have these concepts, but the Custom Recycle plugin has something like this, and somebody casually asked about it yesterday. It adds complexity that IMO isn't worth it. It would also present some challenges on the UI.
• Configuring output multipliers by category could be done. I hadn't thought about that before. Output multipliers were more of an after thought, a legacy feature that I carried over from the previous version of the plugin.
• Add an API so that crafting plugins can register their custom recipes, allowing this plugin to auto determine the appropriate output, and show that output in the UI.
• Add an API and hooks to allow editing configurable outputs of other plugins. For example, Bag of Holding has configurable recycle output for all bags. While that could just be configured in this plugin by skin ID or display name, that plugin allows changing those properties, so it would be better if this plugin could just edit that plugin's config to ensure the recycling output is colocated and has a single source of truth.