Hi, I've run into a really awkward problem with train stop circuit logic.
It seems that the "Read Stopped Train" signal is sent at least one tick earlier than "Read Train Contents."
I identified this glitch while trying to answer the question, "how do you read that there is an empty train waiting, when you don't know what it was originally loaded with?"
The simplest answer I found is: ( [Everything] == [T] ) && ( [T] != 0 )
(where T is the train ID)
However, a train that is not empty will generate a "true" signal for the first frame that it is stopped.
That single tick false-positive is being a real pain in my butt right now with my current project. Is this something you can/might do anything about?
Thank you!
[0.16.36] Train stop circuit network glitch
-
regular_human
- Burner Inserter
- Posts: 6
- Joined: Wed Apr 05, 2017 12:50 am
- Contact:
Re: [0.16.36] Train stop circuit network glitch
Tested with a signal to pulse converter.
(it blocks all output after the 1st tick)
I get both signals in the counter. Only possible when they fire in the same tick.
Constant combinator is a reset.
(it blocks all output after the 1st tick)
I get both signals in the counter. Only possible when they fire in the same tick.
Constant combinator is a reset.
- read train.gif (862.27 KiB) Viewed 1633 times
BluePrint
Re: [0.16.36] Train stop circuit network glitch
Try it with an arithmetic combinator belt * -1 = belt.
The belt signal should be delayed one tick.
This scenario is common in LTN setups.
The belt signal should be delayed one tick.
This scenario is common in LTN setups.
Re: [0.16.36] Train stop circuit network glitch
Ah.. I misunderstood you, i think.
If you substract the T signal before you send the rest, you know that no signal -> no cargo.
Here is how i 'd do it in one tick.
Place this between the station and the rest.
If you substract the T signal before you send the rest, you know that no signal -> no cargo.
Here is how i 'd do it in one tick.
- sigsub 0.png (165.52 KiB) Viewed 1631 times
BluePrint