A circuit controlled Splitter set to Set Filter with a static Input Priority (untested with circuit controlled Input Priority), on every belt tier except Basic (15/second), will allow both inputs to flow for the first tick, rather than only the prioritized input, even when provided only 1 tick of control signal. Issue is most noticeable when both inputs are saturated.
Expected behavior under 1 tick conditions: One set of items from the prioritized input
Observed behavior under 1 tick conditions: Two sets of items, one from either inputs
Expected flow behavior while filter is enabled: Prioritized input flows freely
Observed behavior while filter is enabled: Both inputs flow at the same time for the first tick, delaying the prioritized input until the belt ahead has space for another set, then the prioritized input flows freely
[2.0.69] Circuit Controlled Splitter with Input Priority Disregards Priority for First Tick
Re: [2.0.69] Circuit Controlled Splitter with Input Priority Disregards Priority for First Tick
Given there is no clear save file provided showing the issue i am going to claim that this is Not a bug due to inherent delay it takes for a circuit network to process signals and take effects.
Re: [2.0.69] Circuit Controlled Splitter with Input Priority Disregards Priority for First Tick
Isolated the build in editor for logging and save file attachment here
Also a blueprint available here: https://factoriobin.com/post/qpv27i
Anticipated result would be drawing only from the priority belt for all belt tiers with a 1 tick command
Live result in 2.1.8 experimental is currently both belts pulled from at all tiers except yellow
Also a blueprint available here: https://factoriobin.com/post/qpv27i
Anticipated result would be drawing only from the priority belt for all belt tiers with a 1 tick command
Live result in 2.1.8 experimental is currently both belts pulled from at all tiers except yellow
- Attachments
-
- splittersave.zip
- (1.42 MiB) Downloaded 65 times
-
- factorio-current.log
- (7.86 KiB) Downloaded 56 times
Re: [2.0.69] Circuit Controlled Splitter with Input Priority Disregards Priority for First Tick
I experimented with this step-by-step quite a bit, and I was not able to find anything "wrong". It looks like the Fast/Express/Turbo splitters internal "buffer positions" are being used to move items directly to the Output lane - they briefly have a content of 22 Items, vs the standing-still 18 Items. This happens during the tick where the Control Behaviour is toggled off by the circuit.
Whereas the yellow Belts/Splitter take an extra Tick to move the items far enough to reach the Internal Buffer; this makes it happen on the next tick where the Control Behaviour has taken effect.
Whereas the yellow Belts/Splitter take an extra Tick to move the items far enough to reach the Internal Buffer; this makes it happen on the next tick where the Control Behaviour has taken effect.
Re: [2.0.69] Circuit Controlled Splitter with Input Priority Disregards Priority for First Tick
Looking into this, i am not sure if there is anything that can be done to make splitters only output one set of items in this scenario. Splitters are full of extra cases aiming at keeping output belts compressed in various scenarios which involves having item buffers that are part of input lines, buffers that are 51 positions long. In order for the output belts to remain compressed in all cases, at the tick the items are allowed to go onto west output of your contraption, first item is taken from priority input but since the item is already 51 positions ahead of buffer start, it is inserted 51 positions ahead of the back of output line plus distance caused by belt speed. In case of a yellow belt (speed of 8 positions per tick), first item lands 59 positions from the end of line and there is no more space for extra items on output line (item spacing on belts is 64 positions), however starting from red belt (speed of 16 positions per tick), first item lands 67 positions from the end of line leaving an empty spot for one extra item, and this gap is filled from the secondary output because there are items present in the buffer, there is a gap and so the item is moved.
I am not considering trading belt compression for this feature to be valid due to history of belt compression related bug reports.
If i was forced to fix this, i would probably make split items to be inserted at most 63 positions from the back of output line such that there would be no gaps to put a second item on a line, but this would cause problems for modded belts and splitters if their movement speed is above 64 positions per tick because splitters would be capped at 1 item per tick per output lane throughput which would be also likely considered a bug.
Overall i am not considering this to be a minor issue. I see what you want to achieve but this was never a feature in the first place to have splitters output at most one set of items on a pulsed filters. Splitters can insert items far downstream to avoid gaps and this allows for multiple items to be transferred even if output side is set only for 1 tick.
I am not considering trading belt compression for this feature to be valid due to history of belt compression related bug reports.
If i was forced to fix this, i would probably make split items to be inserted at most 63 positions from the back of output line such that there would be no gaps to put a second item on a line, but this would cause problems for modded belts and splitters if their movement speed is above 64 positions per tick because splitters would be capped at 1 item per tick per output lane throughput which would be also likely considered a bug.
Overall i am not considering this to be a minor issue. I see what you want to achieve but this was never a feature in the first place to have splitters output at most one set of items on a pulsed filters. Splitters can insert items far downstream to avoid gaps and this allows for multiple items to be transferred even if output side is set only for 1 tick.