[0.15.4][Twinsen] Read train contents sends 0 briefly?

[BillH]

I tried to use the "read train contents" option to limit the number of rails (among other things) that are put on my supply train. I ran a wire from the train stop directly to a stack inserter and set the enable condition to "rail < 500". When I tested an empty train it worked perfectly. However, when a train containing 500 rails pulls into the station, the inserter is enabled for one cycle, overfilling the train. As you can imagine, with multiple inserters each entering different items my train gets filled with extra stuff really quickly. It seems like it takes a tick or so for the train contents to be read after the train pulls into the station, just long enough that the inserter sees a '0' and therefore activates. Is this intended behavior?

[maniak1349]

Train station will report train contents with a slight delay (a single tick?) after the train has stopped at the station. This will allow inseters that rely on the train contents information to grab a handful of items even if they are not supposed to.

Steps to reproduce:
1. Make a station and allow it to report train contents
2. Make an outward (extracting) inserter at station and power it
3. Connect inserter to the station, set it to be enabled if circuit network reports none of item X
4. Make a station inbound train with cargo wagon containing any amount of forbidden items X
5. Let the train get to the station
6. Observe inserter being able to extract a handful of items

For example, here inserter was able to grab 3 ECs despite the fact that it is forbidden to take stuff out if the train contains ECs:

inserter-mugger.jpg (582.25 KiB) Viewed 29860 times

[Aeternus]

Don't think that's a bug. Inserters work immediately, but the Circuit Network gets evaluated 60 times per second. The time between train arrival and the next circuit pulse is enough for the Inserter to start a single move - and inserters finish whatever they're currently grabbing/moving before rechecking their activation state.

You could work around this with an extra Decider Combinator - Toss "Everything = 0" as input, reading it from the station, and "Circuits = 1" as output, use the green cable and patch that onto the inserter. That'll hold the inserter until the train contents is evaluated.

[Edit] If it's considered a bug, then syncing the "wagon opens" event with the next circuit pulse should fix the issue.

[Kilandor]

Here is a gif of the issue. I ran into it today and started to report it.
Its the same issue just slightly reversed

1. Send train contents of network to an inserter.
2. Check if item has less than X amount.

The cargo wagon opens and the inserter sees has a spot to insert into before the contents of the train reach the inserter. In my case I want the wagon to be stocked with X number of items without overfilling it or filtering the slots.
The end result problem with the current delay is that every trip the wagon returns its possible for it to slowly overfill to the point the inventory is completely full.



Full sized version
https://gfycat.com/ComplexAstonishingBluefintuna

(Thanks to Extrien for coming in and testing/confirming this for me and the work around, and KorGgenT)

[Twinsen]

This is not a bug due to the way how circuit networks work(every signal takes 1 tick to propagate).

But this is a very common use case and people expect it to work. I'm still thinking of the best solution.
1. Delaying the inserter loading. This would require some significant code changes and some performance hits.
2. Adding a new output to the station that outputs a signal when the train is stopped. This way you can stop the inserter until a train arrives.

[Tekky]

If it's considered a bug, then syncing the "wagon opens" event with the next circuit pulse should fix the issue.

Yes, I agree with this.

1. Delaying the inserter loading. This would require some significant code changes and some performance hits.

Although I do agree that the inserter should be delayed by one tick, so that very simple circuit network setups such as those described by the original poster will work, I am still not happy with this solution. The game has no way of knowing how many ticks the player's circuit network will need to adapt to the new station output. Complex circuit networks could require many ticks.

2. Adding a new output to the station that outputs a signal when the train is stopped. This way you can stop the inserter until a train arrives.

I like this solution very much. It should be possible for the circuit network to distinguish an empty train station from a station with an empty train in it. This information would be useful not just for the issue described in this bug report, but also for other situations.

Just as a side note: The signal that the train/station sends to the circuit network could be more than just a predefined constant. In the following threads, it has been proposed that the Train-ID is sent to the circuit network:
viewtopic.php?f=6&t=26359 Trains numbers for circuit network in v0.13
viewtopic.php?f=6&t=39002 Train-IDs for the circuit network
viewtopic.php?f=6&t=46969 Constant Combinator for Locomotive

[Deadly-Bagel]

There are botches players have used to try to determine if there is a train at the station and if the train is empty they still need to rely on those techniques. Having the ability to sense a train is at the station would be very useful, for this and other reasons as well.

Now we only need a way to tell trains apart by maybe having them send a constant signal *wink wink* and we're set

[MasterBuilder]

2. Adding a new output to the station that outputs a signal when the train is stopped. This way you can stop the inserter until a train arrives.

That would make my day. My best workaround for this was to check is the signal leading into the station was red, but this is imperfect.

(Maybe a signal indicating a train is heading to the station as well? This & the above would complete my train supply/demand circuit network.)

[Kilandor]

This is not a bug due to the way how circuit networks work(every signal takes 1 tick to propagate).

But this is a very common use case and people expect it to work. I'm still thinking of the best solution.
1. Delaying the inserter loading. This would require some significant code changes and some performance hits.
2. Adding a new output to the station that outputs a signal when the train is stopped. This way you can stop the inserter until a train arrives.

I think a Signal from the stop when a train is at the station, and a signal for when no train is at the station would work just fine to solve the issue.

[BenSeidel]

I currently have a fish in each of my trains. It only works because I don't use the "inventory full" or "inventory empty" conditions.

[samr85]

Could the signal not be sent 1 tick before the train finishes opening?

[Deadly-Bagel]

Inserter starts working the moment the train stops, the train opening is just an animation. Twinsen said he could delay the Inserter but would impact performance, probably only a little but these things add up.

[BenSeidel]

Could the signal not be sent 1 tick before the train finishes opening?

This would also only work for single combinator setups. If you have two in a row then you will need a 2 tick delay, 3 combinations in a chain makes it a 3 tick delay. What is needed is a reliable way of telling if a train is at the stop.

[Tekky]

Could the signal not be sent 1 tick before the train finishes opening?

This would also only work for single combinator setups. If you have two in a row then you will need a 2 tick delay, 3 combinations in a chain makes it a 3 tick delay. What is needed is a reliable way of telling if a train is at the stop.

Yes, I agree that this would be the most important thing.

However,it may be nice if at least a 1 tick delay could be implemented, if it does not sacrifice too much performance, so that at least very simple circuit network setups would work without having to evaluate that signal. But this is not so important.

[mpd_steam]

Twinsen, please don't toy with us I've seen people asking for a "train present" signal for ages.

Of course we'd have to decide what signal. Maybe we could assign a signal to a train, and have the station output it once it arrives...

[maniak1349]

Inserters work immediately, but the Circuit Network gets evaluated 60 times per second. The time between train arrival and the next circuit pulse is enough for the Inserter to start a single move - and inserters finish whatever they're currently grabbing/moving before rechecking their activation state.

Can someone explain this to me in more detail please? Because I thought that the whole game state, including states of all the entities, circuit networks, etc. are evaluated (if there is a need for them to be reevaluated and there is enough processing power for that) exactly 60 times per second (i.e. UPS) and circuit networks are evaluated first. Or is it exactly because it works like that it's happening? Something like:

...
tick 1 - circuit networks are evaluated (train is yet to arrive)
tick 1 - moving entities are evaluated (train arrives)
tick 1 - stationary entities are evaluated (circuit network is unaware of the train and inserters grabs the stuff)
tick 2 - circuit networks are evaluated (now inserter is disabled but it is already in the process of moving some items)
...

[Aeternus]

The circuit network works on a 60Hz internal clock. That means, 60 times per second (16.67 ms per tick), the circuit network evaluates it's inputs, and changes the outputs accordingly. For most situations this is trivial, but people building bigger switching logics and/or people who, like you, use a nonsynchronized event (train arrival), it becomes important. The sequence of events is:

0 ms/ Tick 0: Starting state: No train present. Station outputs no cargo signals. Inserter is active.
10ms / Tick 0: Event: Train arrival and wagon opens.
10ms/ Tick 0: Active inserter detects cargo and starts a move. Once an inserter starts a move, it will not stop unless you kill the power to it.
16.66ms / Tick 1: Circuit network is evaluated. The inserter detects cargo and deactivates further moves. It finishes the first movement it started.

Again, this can be fixed by a single Decider combinator that tests for "Everything = 0" on the station, which signals no train or an empty one, and deactivate the Inserter as long as this condition is present. The condition Everything = 0 changes at the same time the "Basic Circuits > 0" changes, so that synchronizes the arrival event with the circuit network.

Train arrivals, wagons opening and inserters starting movement are not circuit network event, and are therefor done in realtime (or in whatever speed your computer itself can manage).

[Edit] As for a signal for train arrival - why not simply output the locomotives and wagons along with the cargo? Then testing for "Locomotives > 0" signals a train present. Simple.

[dRbiG]

2. Adding a new output to the station that outputs a signal when the train is stopped. This way you can stop the inserter until a train arrives.

That does indeed make sense. I've spent last 2h+ trying to "make my train loading work sane"... Damn this game

Thoughts:
1. Distinguishing between `nil` (as in absence of) and `zero` signal would solve it too
2. Delay combinator also crossed my mind
3. A work-around I didn't (yet?) try would be some hacky loop of load-unload-store, very much ugly

(And as this is my first post: astounded by the rate and timing of bugfixes. I can relate and I'd guess the "steam success" made things surface up so much more quickly.)

[Twinsen]

I will add a new mode of operation to the station that outputs a number to a specified signal when a train stops there. That number will be a unique id for the train.

Not only will this be a way to fix this problem, but it seems like a nice feature to have
Thanks for the suggestions.

[Tekky]

Wow, thank you very very much! I thought I would just mention the suggestions about adding a unique ID for the trains, just to make you aware of them. I didn't actually think you would implement them in the near future. I was thinking more of a feature to be added into Factorio somewhere around version 1.2 or 1.3, in maybe two years.

You guys truly are the best!

I have already posted twice to the thank-you thread on this forum, once shortly after I started playing and once to say thanks for the great 0.15 patch. However, I now feel that these were not enough thank you's, so I guess I will have to make another post in that thread. On the other hand, I don't want to get banned for spamming the thank you thread with thank you's.

EDIT: Please make sure that this train ID is nonzero, because sending a train ID signal of zero will not be distinguishable from no signal.