[0.17.66] Circuit network: Reading trains done a tick too late
Posted: Tue Aug 27, 2019 10:40 pm
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.
Re: [0.17.66] Reading trains done too late
Posted: Wed Aug 28, 2019 4:31 am
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.
Re: [0.17.66] Reading trains done too late
Posted: Wed Aug 28, 2019 8:43 am
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.
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.
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.
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
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
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.
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.
