[BUG?] Crossroad / T interaction (esp. with process time 3)

Crossings do not seem to play nice with process time 3 equipment.

i.imgur.com/aucLUOC.png

The purplish material is input for the UV curers, and the white material is output from the chromatographs which come after them, and they should cross smoothly with the first crossing advancing the input belt twice for each time the chromatograph outputs (because one direction should flow freely if there’s nothing waiting for a turn to cross its path). With the output collector belt (taking the white material to the Ionizer) spaced with a gap between it and the input belt with the crossings, as shown, so that there’s a straight belt section between them, this is indeed how it works out unless things get jammed up somehow.

But if the belt is positioned as in the next screenshot, when that first crossing accepts an item from the chromatograph’s stubby output belt, it forces the T junction opposite that stub to roll the white material toward the ionizer, even when the crossing itself was empty at the time and nothing moves onto the T, creating a gap in what should be a process time 1 line. It seems like an “obvious solution” to have the T junction roll the item waiting along the straight portion of the output collector belt forward if the crossing itself was empty. In other words, to check if it’s possible for the waiting line of items to advance into the T, toward the ionizer (despite the crossing pulling an item in from opposite the T), so that no gap appears, the same way everything advances when there’s the straight belt in between the crossing and the T.

i.imgur.com/CJWwEwP.png

Also:

In the first screenshot, one of the white material coming out of the chromatographs took a left turn instead of going straight (and is now trying to go into the last UV curer for a second ride). Crossings acting like corners seems to occasionally happen when playing with the belts or resetting machines by picking them up and putting them down again, but in this case I had just reloaded the game.

Ignore the blue item chasing the gap in the second screenshot, it’s apparently the result of a mixer crossing error, only having traits of the base material. Probably also happened on game load, and just took a few cycles to reach that point right as I managed to grab a screenshot as the belt advanced and left a gap on the T.

Apparently I was half asleep when I posted this and never completed the subject line… and I can’t find an edit option. I’ve put it in properly on this one. Maybe a mod could update it for me?

I think this might be fixed from v0.45.02. Can you check?

Nope, it is still an issue… I’ve fiddled around like 4 hours already… but it seems like crossroads cause awkward issues with a process timing of 3.

Since the movement on crossroads alternates each tick it doesn’t work properly. For process timing 3 it should work in a 2:1 ratio instead of 1:1 ratio otherwise it will cause a stall and other awkward behavior that can’t be solved easily.

One has to be very specific with the layout and with exact timing so that the item is able to pass through the gap in the right moment… it’s the only way to make it work. So you have to make sure yourself that the travel distance to a crossroad matches the 2:1 ratio perfectly otherwise weird things happen.

I’m not sure if I understand the 2:1 ratio correctly, but can get the following to work w/ 2 T-belts at input of 3 machines and 2 T-belts at output
section. (For T-BELT, no 4 way CROSSROADS in this one)

There is a slight “stall” at the output where the T-belts at output are waiting for a gap to move forward, but once it is all set up I get a
full processing (input port moves at every tick and output moves at every tick)

(btw, 3 syringe makers)

prntscr.com/882vsv

A set up w/ T-Belts and Crossroads, that has input moving at every tick and output (into analyzer in this case) at every tick w/ machines w/ 3 tick processing (sequencers). v0.45.02

Again, I may not be understanding the “ratio” term correctly.
3 screenshots showing the progress.

prntscr.com/8831ub
prntscr.com/88329q
prntscr.com/8832pv

Tried re-creating OP’s line in v.0.45.02. Still get a “stall” of belt after a bit.

Initial processing, getting about 2/3 processing at top (into analyzer)
prntscr.com/883bag

Processed further. All lines before the Ionizer at top have stopped

prntscr.com/883cid

Everything stopped (but 1 more going into analyzer)

prntscr.com/883d9k

I could delete a jammed crossroad and get it going again, but at 3 out of 4 output at best.

Added some colored belts to illustrate (hopefully)
prntscr.com/883hvn

What I mean with the ratio is that if you build 3 parallel machines each with a timing of 3 somewhere you have to cross the input belt with the output belt 2 times or the other way around, you have to cross the output belt with the input belt 2 times. Like your pictures show.

The problem with that is that if a belt crosses two other belts is that the timing needs to be very specific because otherwise the input item and the output item reach the crossing at the same tick. Which is very, very bad for the pipelining, especially if they both want to enter at the exact same time. When that happens one has to wait for the other to move through the intersection, which causes a gap in the line that has to wait, because it will take 2 ticks before the waiting item is allowed to move.

That obviously causes stalls in the pipelining with near to unavoidable gaps.

The only way to prevent that is to move the crossing as far away from the input/output of a machine that the input/output item reaches the crossing exactly when there’s a gap in the other line, which can be tricky to achieve, if possible at all and is mostly huge waste of space depending on the timing.

That’s what I mean it should work with a 2:1 ratio. Because one of the crossings in such a setup will unavoidibly behave exactly like that. 2 items for one direction for every 1 item of the other direction.

Since a crossing doesn’t know that it should move 2 items from one direction for every 1 item of the other direction it will cause pipeline stalling with gaps due to shared resource conflict with the resource being the crosstile shared by both lines. That happens because crossings work in 1:1 ratio, with alternating direction in each tick.

Thanks, I understand how you mean it now. The particular setup you want is for the crossroad line to move twice in 1 direction, and then once in the other direction. (but it moves 1:1 ratio).

After playing around with it more, I think the issue still exists in v0.45.02 and in particular is when a 3 tick machine output is directly followed by a crossroad and then directly followed by a T-Belt.

As shown in this image, the T-belt and the crossroad w/ the arrows, and the circled 3 tick machine output (Chromotograph) are the only things that matter. I can move any other T-belt, Crossroad, etc. and it still will eventually jam at the T-Belt at top (w/ the arrow).
prntscr.com/88trra

EDIT - Add example
Even a simple (albeit nonsensical example) set up like this will jam at the T-Belt:
prntscr.com/88u180

I still have that save, so I loaded it up in 1.0 and moved the belt back into the “broken” position. Yep, still broken. Additionally, shortly after loading the game, I noticed a lone incorrect material making its way down the line, apparently thanks to one of the crossroads before the mixers forgetting which way the item on it was supposed to be moving. So that’s still broken too. If I can figure out where the save files are stored, I could toss it on google drive and leave a link to it, if that would be of help in testing potential fixes.

(Okay, apparently there is an edit option, but only for a minute or two, and even if you start editing before it goes away, by the time you finish you’re locked out of actually posting that edit. Looks like it’s double post time.)

The issue with a crossroad and an adjacent T belt might actually be a problem with the T’s logic for when to move an item. I’m not sure how the belts are coded, but maybe the T is assuming that if there are two inputs and one output that it will always alternate between the two inputs if there is an item present on the belts leading to both of those inputs. If so, when the crossroad contains an item that shouldn’t actually be sent onto the T belt, that might cause the T to try to leave room for an item from the crossroad to move onto the T even though that isn’t going to happen, rather than letting the item from the straight belt move onto it. At any rate, the result is that the T closest to the destination, which should be accepting two items from the straight belt for every one item that comes from the crossing belt, ends up introducing gaps and causing the machines further back the line to slow down.

Found it! (My Documents/My Games/Big Pharma/Saves) Here’s that game with everything set up in the way that causes problems:

drive.google.com/file/d/0B-WyBI … sp=sharing