Slightly smarter inserters for trains?

[ActionJackson]

This has to do with inserter behavior when loading a train with filtered slots

Let's say you have a train with only 5 slots available and that they are all filtered to a different item (the rest of the slots are ignored with the RED X).

Problem: When pulling from a chest, the inserter will pull the maximum stack size and attempt to insert it into the train. If there are any remaining items in the inserters "grip", the item will remain there, preventing further available items that exist in your source chest from being pulled into their corresponding train spots.

Gripe: This effectively limits the number of DIFFERENT items you can put into a single train car to 12 if you want to minimize restock time. As only 12 inserters can "reach" a train once stopped. The only workarounds I'm aware of is 2 separate stops, or a combinator circuit that has "tick" count issues (which is a separate issue entirely)

Solution: The inserter should be smart enough to check that the maximum stack stack size for the target is too large for the remaining space, and only grab what it's capable of dropping off. The same is largely true for assembly machines, this won't ever happen with those (albeit probably because you can have excess materials in your ingredient hopper).

The only workaround is to limit stack size to 1, which can really suck for advanced train setups.

I don't seeing this as anything but a quality of life improvement, and open up more possibilities for creativity, and is not game breaking whatsoever.

[Theikkru]

Technically the item type limit is 24 (if you use long-hand inserters). This change would be nice for a lot of things though. Could also be solved by this.

[Sad_Brother]

So you are really want "do not take more than can place" option to inserters.
Should inserter block space for items, would be moved? Or else your 12 inserters would pretend for the same space.
Which inserter should take full stack? Placing on belts only?

[Serenity]

While this would be nice it would probably cost too much performance as those checks would have be made in all cases. Not just the very few ones you'd see a benefit in

[Sad_Brother]

The train case is most important here.
Even if this check would be for trains only its useful.

[Serenity]

Even if this check would be for trains only its useful.

They'd still have to check if they are inserting into a train

[Yoyobuae]

More checks = More CPU usage. Inserters need to be dumb in order to keep performance.

There are circuit setups which can load a train with exact count of items. They are just not easy to design.

[5thHorseman]

IMO 12 items per wagon in a simple setup, or 24 items with the dual long inserter setup, is perfectly fine.

If you _really_ need more than 24 different items per train wagon, then you should be more than capable of making your own circuits.

[ssilk]

This is something, which is for example part of complex LTN-setups. See LTN-mod subboard.

And for me it’s part of the game, because it looks at first like a simple thing to do, but it is in fact quite complex to do it right and impossible to do it right in every situation. But it is a quite simple thing, if the player changes the setup and reduces such complexity (see above, 24 items is a very solid base). So it should not be part of vanilla, because that should work in every situation.

[DingoPD]

While this would be nice it would probably cost too much performance as those checks would have be made in all cases. Not just the very few ones you'd see a benefit in

Not really, there is already check in place to make sure the inserter can put the items in, so when that fails, you can run the calculation and insert just partial stack then, at most you will have to do it only once, and only when the destination is nearly full.

[disentius]

You are missing one of the key concepts of factorio: you have this tools, make it work.
Aside from performance issues, the above is the reason this will not be implemented.

[5thHorseman]

While this would be nice it would probably cost too much performance as those checks would have be made in all cases. Not just the very few ones you'd see a benefit in

Not really, there is already check in place to make sure the inserter can put the items in, so when that fails, you can run the calculation and insert just partial stack then, at most you will have to do it only once, and only when the destination is nearly full.

When that check is made, the inserter already has the items in its hand. Should it put them back in the box? What if that box is full?

Or should you check earlier? And should you check all inserters that are putting things in the box to make sure they aren't already putting that item in it? Or should inserters reserve the space?

There's no way to do it where it doesn't either cost cycles or cause issues. I don't personally think this is worth either of those costs.

[DingoPD]

When that check is made, the inserter already has the items in its hand. Should it put them back in the box? What if that box is full?

Or should you check earlier? And should you check all inserters that are putting things in the box to make sure they aren't already putting that item in it? Or should inserters reserve the space?

There's no way to do it where it doesn't either cost cycles or cause issues. I don't personally think this is worth either of those costs.

I understand where you coming from, but everything has a cost, i bet the animation when the inserter moves full hand and then just sits there costs more CPU cycles than adjusting the pick up amount and actually getting something good out of it in the end. If saving all possible CPU cycles was name of the game, then the devs would save lot more cycles by not running the animation at all when the container is full.

I make some big assumptions,i don't know how exactly the code handles the inserter updates:
3Ghz CPU for the timing
inserter update handling is done sequentially on single thread

So please take everything below with a grain of salt.

Once compiled, in x64 the check would probably take 3 mov instructions, 1 cmp and 1 jge, so that's 5 CPU cycles if you have to adjust the pick up amount, and 4 CPU cycles if you don't (one mov less). You'd only run that check when the target is a containers, not a belts.

Even if you have to adjust the pick up amount on 10k inserters in a single 500ms tick, it'd take some 1.67ms (rounded up) to adjust the pick up amount 10k times. Or you could say it'd take about 0.000167ms per inserter on 3Ghz CPU.

There is a really good chance that the code already knows how much space there is left in the target and the pick up stack size beforehand, and if that is the case, you could get away with 3 opcodes to change the pick up amount, and 2 to skip.

I could say, that it is possible, to just read the container (in-game), and adjust the inserter stack size on the fly with in-game circuits, but then you'd spent orders of magnitude more CPU time dealing with it than if it is done in code.

I think this would be great for factory optimization, if you consider assembly machines a container too, they would always get exactly the amount required, instead of being greedy. That could smooth out lot of things overall. The endless optimist in me thinks you might even save few cycles here and there.

[eradicator]

If saving all possible CPU cycles was name of the game, then the devs would save lot more cycles by not running the animation at all when the container is full.

That potentially makes UX a lot worse though. If an inserter with a full hand hovers over a container without inserting it's very clear that the container is full - exactly the same behavior as for belts. If the inserter doesn't move at all on full containers then you have to manually inspect each container.

Also for assembling machines: If you had a machine that only uses 6 items per inserter cycle, then autoadjust would mean the inserter cycles at full speed. With the current 12 stack limit it can swing at half speed and sleep inbetween.

[DingoPD]

That potentially makes UX a lot worse though. If an inserter with a full hand hovers over a container without inserting it's very clear that the container is full - exactly the same behavior as for belts. If the inserter doesn't move at all on full containers then you have to manually inspect each container.

When i look for a problem, i don't really look at the inserters, i follow the empty belts back towards the source until i find the problem. It was just quick and dirty example, i didn't really mean for the devs to remove the last animation :). I was just trying to say, that new features don't necessarily carry heavy performance hit.

I still think that inserters picking up the exact amount left on last swing is a good idea, and not only for trains.

For example the kovarex enrichment process where the centrifuges try to stock up on 2x the required amount of u-235, when you just getting started with nuclear and trying to prime multiple centrifuges as fast as possible, inserters taking extra add lot of delay before you see any meaningful amount of u-235 coming out of a line of centrifuges. Inserters stocking only what is exactly needed, (80x u-235 in this case) would make output lot more predicable.

[ssilk]

For example the kovarex enrichment process where the centrifuges try to stock up on 2x the required amount of u-235, when you just getting started with nuclear and trying to prime multiple centrifuges as fast as possible, inserters taking extra add lot of delay before you see any meaningful amount of u-235 coming out of a line of centrifuges. Inserters stocking only what is exactly needed, (80x u-235 in this case) would make output lot more predicable.

This problem is part of the game. It can be managed or you live with it. This is the same with train loading/unloading. The problem with them is, that it looks like a bug and cannot be fixed by the player. But it is a puzzle.

[DingoPD]

This problem is part of the game. It can be managed or you live with it. This is the same with train loading/unloading. The problem with them is, that it looks like a bug and cannot be fixed by the player. But it is a puzzle.

Fair enough :)

For kovarex process i usually do something like this, and just let it do it's own thing:

Kovarex.png (4.02 MiB) Viewed 2959 times

The top inserter's are all set to 4 item stack, that manages the centrifuge greed for u-235 well enough that i rarely try to rebuild it, if i were to give each centrifuge it's own dedicated belt loop, use slow belt, and replace the top 3 inserters with 2 filter inserters, i could probably make it count perfect.

The inserter/train problem is a harder nut to crack, guess easiest way would be to make sure the train is empty and just use fraction of the amount for the inserter stack size, or something like that anyway ..