[0.17.66] Circuit network: Reading trains done a tick too late

Don't know how to use a machine? Looking for efficient setups? Stuck in a mission?
Post Reply
User avatar
planetmaker
Fast Inserter
Fast Inserter
Posts: 179
Joined: Mon Jan 21, 2019 9:30 am
Contact:

[0.17.66] Circuit network: Reading trains done a tick too late

Post by planetmaker »

In the attached savegame, look at [train=1585631][gps=-247,-236][train-stop=1532660]

The station has a setup where the load amount for the train for a plethora of items is controlled via constant combinators. This is compared to the train stopped at the station and the inserter for each item is activated only when there is a positive difference.

However upon entry of the train into the station, all inserters insert at least one item into the train which is in violation of the circuit condition.

Adding to this in an attempt to circumvent this behaviour: the inserters set to empty the train of "trash" remove items from a random stack in the wagons. Items just inserted into the train are removed again, but possibly from the larger stack(s) so that the wagons slots eventually WILL fill up with non-complete stacks of stuff which they should not.
Attachments
v017_automate_14.zip
(14.63 MiB) Downloaded 26 times
Last edited by planetmaker on Wed Aug 28, 2019 12:25 pm, edited 1 time in total.

User avatar
boskid
Factorio Staff
Factorio Staff
Posts: 1565
Joined: Thu Dec 14, 2017 6:56 pm
Contact:

Re: [0.17.66] Reading trains done too late

Post by boskid »

Not a bug (->gameplay help)

This is how circuit networks work: value computed on one tick is provided to circuit network in next tick. Because of this, every decider combinator or arithmetic combinator introduce 1 tick delay. Because of this, when there is no train, all inserters are enabled and they are enabled for some more ticks when train arrives. This is why this is not a bug.

You can fix this setup for example by using decider combinator that would prevent your "requested item count" from going into decider combinators until there is train (Signal T > 0) This signal could be then extra delayed to compensate for logic network. Here it would be one tick delay because you are using arithmetic combinator to invert train entity counts (to then increase them using constant combinators in same network). Another solution would be to change "check signals" to trigger when related signal count is "< 0", not "> 0", and then using pure train readout with inverted constant combinator values (by giving negative numbers or by using arithmetic combinator to inverts). Btw, why decider combinators for inserters? you can insert simple comparison directly into inserter enable condition.

User avatar
planetmaker
Fast Inserter
Fast Inserter
Posts: 179
Joined: Mon Jan 21, 2019 9:30 am
Contact:

Re: [0.17.66] Reading trains done too late

Post by planetmaker »

Right... actually I found the suggested work-around with a T>0 added to the logic after I posted this. Yet it feels as a hack... but reading about how it works with ticks makes this look very tricky to solve if at all.

Thanks for the hint wrt using the condition on the inserters directly. I might change my setup to use it that way, reducing its footprint. It has a tiny backdraw though: the fast or long-handed inserters don't show the item they work for in alt-mode - the decider combinators make it more bulky, but slightly easier debugable / changeable.

In essence: this report can be closed, I guess. Sorry for the noise.

mmmPI
Filter Inserter
Filter Inserter
Posts: 638
Joined: Mon Jun 20, 2016 6:10 pm
Contact:

Re: [0.17.66] Reading trains done too late

Post by mmmPI »

planetmaker wrote:
Tue Aug 27, 2019 10:40 pm
However upon entry of the train into the station, all inserters insert at least one item into the train which is in violation of the circuit condition.
I remember seeing this behavior long ago, designed my way around it not understanding.
boskid wrote:
Wed Aug 28, 2019 4:31 am
This is how circuit networks work: value computed on one tick is provided to circuit network in next tick. Because of this, every decider combinator or arithmetic combinator introduce 1 tick delay. Because of this, when there is no train, all inserters are enabled and they are enabled for some more ticks when train arrives. This is why this is not a bug.
I had learned that more recently, yet it didn't connect in my mind before reading it that it was the cause for the previous behavior which i had forgotten since then.
planetmaker wrote:
Wed Aug 28, 2019 8:43 am
In essence: this report can be closed, I guess. Sorry for the noise.
maybe it can be closed or moved to gameplay help, that feels to me like when someone ask a good question and everyone benefit the answer, thanks for asking :)

User avatar
planetmaker
Fast Inserter
Fast Inserter
Posts: 179
Joined: Mon Jan 21, 2019 9:30 am
Contact:

Re: [0.17.66] Reading trains done too late

Post by planetmaker »

mmmPI wrote:
Wed Aug 28, 2019 10:01 am
maybe it can be closed or moved to gameplay help, that feels to me like when someone ask a good question and everyone benefit the answer, thanks for asking :)
Not a bad idea... maybe it helps. I made the title of the 1st posting a bit more verbose so that it might be found easier

User avatar
boskid
Factorio Staff
Factorio Staff
Posts: 1565
Joined: Thu Dec 14, 2017 6:56 pm
Contact:

Re: [0.17.66] Reading trains done too late

Post by boskid »

75006.png
75006.png (314.74 KiB) Viewed 981 times

There is one decider and one arithmetic combinator connected directly to train station. First one is to detect if train is present (T>0) and if yes then output U=1. Second one is to multiply each signal by -1. Their output is merged. Assuming signals from train stop are tick perfect (that is, signal T and item count), then after this 2 combinators they will be also in sync. Then to this negative "item count" is added requested item count. This produce "item count delta" that is positive if you need to put items to train or negative if you should remove them. Then this "item count delta" is multiplied by signal U. Because of this, at output there are non zero signals only if there is train and there is item delta. Long hand inserters contain direct enable condition when given item delta is positive. Stack size is also set to same item delta to get max throughput while keeping this setup count perfect (if there are 500 items to put, stack size will be capped to max bonus, if there is 1 item left, stack size will be 1). Nothing complicated.

slippycheeze
Filter Inserter
Filter Inserter
Posts: 587
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: [0.17.66] Reading trains done too late

Post by slippycheeze »

mmmPI wrote:
Wed Aug 28, 2019 10:01 am
planetmaker wrote:
Tue Aug 27, 2019 10:40 pm
However upon entry of the train into the station, all inserters insert at least one item into the train which is in violation of the circuit condition.
I remember seeing this behavior long ago, designed my way around it not understanding.
FWIW, my personal rule of thumb is that in Factorio you should *always* design circuit-controled things to be "default disabled." There are enough places where this sort of thing crops up that trying to disable in response to something is always going to have a tick or two of error at least some of the time. So if you want to, eg, ensure nothing is in the train, use an "enable if" condition, not a "disable if" condition.

Always annoys me, too, because it feels like an unclean design, but even with careful timing management you still get edge cases where a signal comes out of a device late, or an inserter moves too fast, and you overshoot. Not everywhere, but often enough to give up on the idea I could have both default-enable and always-correct in the same design.

Post Reply

Return to “Gameplay Help”