I've done a cursory search for this suggestion and found nothing, apologies if I missed a thread.
Consider a train stop with "read train contents" and "read stopped train", enabled, a train waiting at the station with the condition "empty cargo inventory", and inserters taking material out. Once it's empty, the train departs the station. The station's circuit signal goes straight from e.g. "61 T, 5 iron plate" to nothing. It would be very handy if the "61 T" signal stuck around just one tick longer, so it would be possible to determine that the train left the station empty. One possible way of implementing this would be to delay the train's departure just one tick.
The current work-around is to add "AND 1s inactivity" to the train's wait condition, which I think is really unfortunate.
Circuit networks: make it practical to determine whether a train was empty when it departed from the train stop
Moderator: ickputzdirwech
Re: Circuit networks: make it practical to determine whether a train was empty when it departed from the train stop
You can get exactly this effect by wiring the stop to a constant T -1000000000, setting it read contents read train send to train, and having the train depart on circuit everything < 0.
Re: Circuit networks: make it practical to determine whether a train was empty when it departed from the train stop
The way to do it is adding AND empty to the schedule.
Checking everything == 0 on circuit network doesn't work for fluids due to mathematical correct rounding down for values < 0.5.
See 2 year long standing request to change this: viewtopic.php?f=6&t=49274
Checking everything == 0 on circuit network doesn't work for fluids due to mathematical correct rounding down for values < 0.5.
See 2 year long standing request to change this: viewtopic.php?f=6&t=49274
My Mods: mods.factorio.com
Re: Circuit networks: make it practical to determine whether a train was empty when it departed from the train stop
I am against OP's suggestion. In my opinion, there are better suggestions to solve the problem, which would offer the player more flexibility.
In this thread, it has been suggested that the Train ID and other signals the train sends should be user-definable. Later in that thread, someone suggested that the signals the train sends should change according to the train's current orders (e.g. when a train leaves a station).
Also, in this thread, I suggested that track signals should be connectable to the circuit network and provide the Train-ID of the train currently in its track segment. Later in that thread, I suggested that it should also be possible to read the cargo contents of the train instead of only the Train-ID.
If these two suggestions were combined, it would make the suggestion made in the current thread redundant. The circuit network connected to a nearby track signal (not the station) could check whether the train's current order is to wait in the station or whether its order has changed to leave the station and go to the next station. Once the circuit network determines that the train's orders has changed, it could then check the train's cargo contents.
As a side note, I would also like to point out that In the following threads, it has been suggested that a wireless circuit network be implemented:
viewtopic.php?f=6&t=49317 Radio Links for signals transmission
viewtopic.php?f=6&t=47429 global circuit network
viewtopic.php?f=6&t=12652 Connection of circuit network over distances
viewtopic.php?f=6&t=51811 "Pipboy" for wireless network/circuit manipulation
viewtopic.php?f=6&t=62384Logistic circuit signals through radars
If it were possible to also connect trains directly to this wireless circuit network, then it wouldn't be necessary for the circuit network to read train contents indirectly over signals or stations, which may make things easier in certain situations.
In this thread, it has been suggested that the Train ID and other signals the train sends should be user-definable. Later in that thread, someone suggested that the signals the train sends should change according to the train's current orders (e.g. when a train leaves a station).
Also, in this thread, I suggested that track signals should be connectable to the circuit network and provide the Train-ID of the train currently in its track segment. Later in that thread, I suggested that it should also be possible to read the cargo contents of the train instead of only the Train-ID.
If these two suggestions were combined, it would make the suggestion made in the current thread redundant. The circuit network connected to a nearby track signal (not the station) could check whether the train's current order is to wait in the station or whether its order has changed to leave the station and go to the next station. Once the circuit network determines that the train's orders has changed, it could then check the train's cargo contents.
As a side note, I would also like to point out that In the following threads, it has been suggested that a wireless circuit network be implemented:
viewtopic.php?f=6&t=49317 Radio Links for signals transmission
viewtopic.php?f=6&t=47429 global circuit network
viewtopic.php?f=6&t=12652 Connection of circuit network over distances
viewtopic.php?f=6&t=51811 "Pipboy" for wireless network/circuit manipulation
viewtopic.php?f=6&t=62384
If it were possible to also connect trains directly to this wireless circuit network, then it wouldn't be necessary for the circuit network to read train contents indirectly over signals or stations, which may make things easier in certain situations.
Re: Circuit networks: make it practical to determine whether a train was empty when it departed from the train stop
Perhaps I'm wrong about this, but adding the "and empty" to the schedule fixes a separate problem that basically never happens with the circuit feedback, which already introduces a one-tick delay. There aren't many tank setups that drain less than 0.5 per tick and the train already waits exactly one tick after its contents round to zero. Departing on empty does not give you one tick of zero-content readout, I think the circuit feedback test is necessary.Optera wrote: ↑Mon Dec 02, 2019 7:44 am The way to do it is adding AND empty to the schedule.
Checking everything == 0 on circuit network doesn't work for fluids due to mathematical correct rounding down for values < 0.5.
See 2 year long standing request to change this: viewtopic.php?f=6&t=49274