[2.0.30] AgriculturalTowerPrototype with output_inventory_size of 0 has 2 output slots

[noodlebox]

1. What did you do?

I'm creating a mod that defines a Cargo Crane entity using the 'agricultural-tower' type. My intention is to prevent the default automatic behavior of harvesting nearby trees and set the crane position via a control script instead, so the crane's prototype sets an 'output_inventory_size' of 0.

2. What happened?

The resulting entity has an output inventory with 2 slots. Specifically, calling `get_inventory_size(defines.inventory.assembling_machine_output)` on the crane's prototype returns 2. Also, `prototype.get_history` show no changes to the prototype after being created.

3. What did you expect to happen instead? It might be obvious to you, but do it anyway!

I expected the output inventory size to be zero, similar to the behavior of 'input_inventory_size' when set to zero (no input slots). Other positive values work as expected (an entity with the specified number of output slots). The docs also mention that its default value is 0, but attempting to fall back on the default gives the same incorrect result (2 output slots):
https://lua-api.factorio.com/latest/pro ... ntory_size

[Rseding91]

Thanks for the report. This is working as intended: a value of 0 (the default) means auto-calculate the required max number of slots to harvest any possible trees. There is no supported way to disable a core functionality of the agricultural tower prototype.

[noodlebox]

This is working as intended: a value of 0 (the default) means auto-calculate the required max number of slots to harvest any possible trees.

That does sound like a perfectly reasonable default behavior. It just seems surprising to use an explicit zero value to represent that case when a nil value (or absent key) already offers a distinct way to signal the intent to use a default. A setting of zero slots here is not only sensible, but uniquely useful for several use cases. Does this limitation exist because this logic must be implemented after the conversion to uint? Here's an example implementation that should behave identically for existing prototypes that omit 'output_inventory_size' (falling back to the auto-calculated default), while allowing for a zero value to behave just as it does almost anywhere else that inventory sizes can be defined.

Code: Select all

-- data-final-fixes.lua

local function get_item(name)
    for typeName in pairs(defines.prototypes.item) do
        local items = data.raw[typeName]
        if items and items[name] then
            return items[name]
        end
    end
    return
end

local function minimum_slots_for_harvest(tree)
    if not tree.minable then
        return 0
    end

    if tree.minable.results then
        local result_slots = 0
        for _, result in pairs(tree.minable.results) do
            if result.type == "item" then
                local amount = result.amount
                if amount == nil then amount = result.amount_max end
                result_slots = result_slots + math.ceil(amount / get_item(result.name).stack_size)
            end
        end
        return result_slots
    end

    if tree.minable.result then
        return math.ceil(tree.minable.count / get_item(tree.minable.result).stack_size)
    end

    return 0 -- No results
end

-- Calculate maximum number of slots to harvest any possible trees
local default_output_size = 1

for _, tree in pairs(data.raw["tree"]) do
    default_output_size = math.max(default_output_size, minimum_slots_for_harvest(tree))
end

for _, plant in pairs(data.raw["plant"]) do
    default_output_size = math.max(default_output_size, minimum_slots_for_harvest(plant))
end

for _, entity in pairs(data.raw["agricultural-tower"]) do
    if entity.output_inventory_size == nil then
        entity.output_inventory_size = default_output_size
    end
end

There is no supported way to disable a core functionality of the agricultural tower prototype.

I understand this stance, it just happens that the current implementation leaves the Agricultural Tower disappointingly close to being a useful (and jank-free) base for a wider variety of machines that could take full advantage of a subset of its other features. If it would be more appropriate, I could bring this up as a modding API request instead. Thanks for the response.