[1.1.5] Inserter sets stack size from the wrong tick when unloading train

[shaney]

Steps to reproduce:
- Train with contents arrives at station. Inserter is enabled/disabled on white dot > 0 and sets stack size on signal S. 2 constant combinators are set up to send 1 white dot and 3 signal S, but are switched off. Game time is paused.

1.png (987.41 KiB) Viewed 3009 times

- Enable both combinators.
- Move time forward one tick.
- Disable both combinators.
- Move time forward another tick. At this point, the inserter is enabled (green light is on), and the stack size has been overridden correctly:

2.png (1 MiB) Viewed 3009 times

- Move time forward another tick. The inserter grabs the contents of the train. It should grab 3 items, but only grabs 1.

3.png (919.78 KiB) Viewed 3009 times

This only happens on the first swing when the train has arrived. On subsequent swings, repeating the steps above will cause the inserter to grab 3 items, as expected. When an inserter is loading a train, repeating the steps above will cause the inserter to grab 3 items even on the first swing after the train arrives.

In the scenario above (first inserter swing while unloading the train), the inserter appears to be setting the stack size from the wrong tick. The steps below reproduce this:

- Same setup as above.
- Enable only the white dot combinator.
- Move time forward one tick.
- Disable the white dot combinator and enable the S=3 combinator.
- Move time forward one tick.
- Disable the S=3 combinator. At this point, the inserter is enabled, but the stack size still shows one, as expected.

4.png (1.11 MiB) Viewed 3009 times

- Move time forward one tick. The inserter has grabbed the contents of the train, but has grabbed 3 items instead of 1. Note that we can also see the inserter is now disabled (light is red) and stack size now shows 3, as it should be.

5.png (1.08 MiB) Viewed 3009 times

Repeating this second set of steps for subsequent inserter swings will result in one item being grabbed, as expected. Again, train loading does not have the same issue.

[Rseding91]

Thanks for the report however I believe this is all working as intended. The stack-size logic only updates once per swing operation and that isn't likely to be changing any time soon.

[mathe172]

Thanks for the report however I believe this is all working as intended. The stack-size logic only updates once per swing operation and that isn't likely to be changing any time soon.

The expected behavior (in my opinion) is that the stack size is read out the instant the items are grabbed. This would also result in "one update per swing operation", but would be much more predictable. (The current behavior seems to behave as if the stack size is read before putting the inserter to sleep rather than after waking it up - as far as I can tell, there is no reason to do it this way, but please do let me know if I'm missing something)

For reference: We have encountered this issue today in a setup where the inserter is set to enable on "S > 0" and set the stack size to "S". Now, "S" is set to the required stack size for one tick to trigger the inserter. This is required due to the tight constraints on timing, item management and cabling. With the current logic, this setup cannot be made to work properly, which would unfortunately make our whole base concept unviable.

[PhiPro]

The stack-size logic only updates once per swing operation

Could you please elaborate how this relates to the very first swing reading the stack size off a different tick than all subsequent swings? I don't really see the connection between these two statements.

This inconsistency between the first swing after seeing a wagon/chest/car and all subsequent swings (namely, reading the stack size from the circuit network with a 1 tick delay comapred to all the susequent swings) doesn't seem expected to me at all. Reading the stack size from the same tick that enables the inserter, as all the subsequent swings do, feels like the expected and most useful specification to me. However, it is really the inconsistency which makes this a bug for me; having a consistent behavior, even if this means always reading the stack size with a 1 tick delay, would at least give some well defined behavior that doesn't depend on an invisble internal state. (Having the expected behavior of always reading the stacksize off the enabling tick would of course be much preferred)

Marking this report as WAI really feels like there is a misunderstanding in what this issue is about. At the very least, I think this should be classified as Won't Fix to at least acknowledge that the behavior shouldn't be expected.

Best,
PhiPro

[shaney]

Thanks PhiPro. I also believe there may have been a misunderstanding with this issue, but wasn't sure how to bring it up. Since this has already been moved to Not A Bug will a developer see replies here?

[Squelch]

This issue has, in some way, answered a problem that I have run into where I wanted to place a precise amount of items from a cargo wagon. I always ended up with more items than I had instructed the inserters to to place. Having been distracted by something else, I eventually abandoned the idea and tried something else. I bookmarked this report when it was first posted in the hope of some clarification, or fix.

From the OP's excellent breakdown of the problem (albeit I needed to read through a few times to fully grasp what was being said) I can now see that the stack size input is read on the trailing edge of the swing and not the leading edge as I had expected. This behaviour is not documented anywhere, and does seem to be the reverse of what seems logical ie. the stack size input is parsed before any items are picked up.

I also agree that the reported issue might have been misread or misunderstood (it took me a moment, but that's probably my problem). I also believe the response is also true. The stack size is indeed updated once per swing. The problem that caught myself, and it seems others, is exactly when it is updated.

It would be nice if this issue is checked again by one of the development team. If the current behaviour of trailing edge is indeed what was intended, then some confirmation of this would be desirable, and perhaps the order of execution documented so that others may be able to understand after they run into problems.

The alternative is to make a suggestion that the order of execution be changed to (in my mind) a more logical sequence.

[Squelch]

I have just been looking into this deeper, and find I have to retract my previous assertions.

The hand stack size signal does not latch when the enable signal is applied, so therefore must be present for the start of the swing. If it is removed before the inserter swing begins, as is the case in the OP time stepping, or if there is any delay (>=1 tick) between the enable signal and the stack size signal being asserted, the inserter will default to a single item (default for stack size = 0)

The stack size amount is in fact parsed on the leading edge, but it must be held long enough for the inserter to react while it is enabled.

An example where this will become a subtle gotcha, is if the enable and stack size signals are both asserted for only one tick simultaneously.

The best practice would be to assert the stack size signal before the enable signal, and only remove it after the inserter has started its swing.

[shaney]

The hand stack size signal does not latch when the enable signal is applied, so therefore must be present for the start of the swing. If it is removed before the inserter swing begins, as is the case in the OP time stepping, or if there is any delay (>=1 tick) between the enable signal and the stack size signal being asserted, the inserter will default to a single item (default for stack size = 0)

I don't think this is quite right. Most of the time you can enable the inserter and set the stack size simultaneously (both signals sent for just one tick). This doesn't work in what seems to be very specific situations. The only such situation I've found is the first swing unloading (but not loading) a train. for this swing, the stack signal must be sent the tick after the activation signal is sent to get the stack size set properly.

The best practice would be to assert the stack size signal before the enable signal, and only remove it after the inserter has started its swing.

Yes, the inconsistency I've described above is only a difference of one tick. If you send the stack signal both at the same time as the activation signal, and also for the the following tick, the stack size should be set correctly in all scenarios. However, it would still be nice to fix the inconsistency.

[shaney]

I also agree that the reported issue might have been misread or misunderstood (it took me a moment, but that's probably my problem).

It seems like this was definitely an issue of clarity in the original post, not your problem .