Distance limit parameter for `spill_item_stacks`

[Wiwiweb]

We recently came across a player bug where `spill_item_stacks` would take 10+ seconds to try and find a free position to spill items:

108931

We thought about how we could avoid this by checking before spilling, using either `count_entities_filtered` or `find_non_colliding_position`, but there's 2 disadvantages: 1) It's expensive, 2) Doesn't always catch all cases (e.g. trying to spill items in the middle of a lake puts the items in unpredictable positions).

It would be convenient to have a "max_distance" or "max_radius" parameter on `spill_item_stacks`. If the spill position found by `spill_item_stacks` is larger than this value, then do not actually create items.

Thanks!

[curiosity]

Guess what else is expensive: spill_item_stacks. Spawn item entities manually if you want something remotely performant. As a bonus, you can put an entire stack into an item entity instead of a single item.

If for whatever reason you are bent on using spill_item_stacks, you should be asking for it to ignore collision as the best way to improve performance.

[boskid]

For now i will have to reject this idea because the spill distance limit would not help in this specific case, the spill_item_stacks would simply revert to spawning items at the spill center which means there could be 1000s+ entities spawned at the center in your specific use case and they would slow down all entity searches happening at that position since collision checks may need to visit literally every single entity at an advanced tile until colliding one is found. Also i do not like the spill_item_stacks function signature as right now it takes up to 5 unnamed parameters so having additional one would mean you would be forced to provide 3 other parameters that are in most cases optional.

[Stringweasel]

+1

My use case is in Biter Power I have turrets that shoots cages to capture biters. This is done with scripting for a few reasons and thus uses spill_item_stack. And if the player doesnt clean up enough the same problem as outlined above might arise.

If 2.0 is used to change the function to accept a table instead so more optional arguments can easily be added, then max_distance / max_radius would be perfect for my use-case as well. Also if it's exceeded then I would be fine with the items being ignored instead of piling in the center. It's possible to verify which items was created by looking at the returned array as anyway.

[Soul-Burn]

With 2.0 getting stacking inserters, could this 10 second freeze issue be solved by spilling items out in stacks? Yes you could have a lot of item types (up to 65k times qualities), but it's usually relatively few item types.