T-Junction Issues


#1

So far I’m really enjoying the game - I hope this is just the start and that we’ll end up with more complexity in the machines, effects and tuning of our production lines.

For now though, a problem with T-Junctions.

As you can see, my wonderous machine should be splitting it’s production after the second evaporator, with half the good stuff going straight to the pill presses in order to fulfill the cheaper end of the market, whilst the other half goes for more treatments to be upgraded into a new cure.

Unfortunately, I cannot get the belts and junctions to behave correctly, and all of the drugs are taking the long route.

Any cure for this ailment please?


#2

Obviously I can solve it without a junction, but this is just a simple example. This bug kind of prohibits complex machines because one T-Junction, it seems, cannot lead to another without confusion ensuing.


#3

This may not help you, but I’ve seen on other T-Belt issue posts that having a machine (of any kind) in between 2 T-Belts helps the game determine the direction to go. I think Tim wrote or said something about belts needing to be “deterministic”. I’ll act like I know what that means :).

This is re-creating of your set up - same thing, the top T-belt will not “split”.



Here a dissolver was added and the T-belt now splits:


And the pilmakers are outputting both:

Not sure if you can still use your “cheaper market” after going thru a dissolver (try an evaporator?) - yes it will cost you to buy and to process.

MOD======
I was thinking of doing a mod that would take the analyzer/incinerator (1x1 footprint), give it an output, no processing effect, no purchase cost, no processing cost, 1x process time - so that it would essentially be a special “belt” but the TBelt would treat it as a machine.

Of course with that mod, you would no longer have a true analyzer. I’m looking at adding new machines but haven’t figured it out yet (if it is possible).


#4

Actually, I think a “pass-through” analyser would be a great mod. You could have it as you say, 1x1 (or not), with an input and an output, and have it perform the work of an analyser.

The difference between this one and the regular one is that this would in some way be disadvantaged, to offset the fact that it doesn’t consume your ingredients - so maybe a process time of 2, or a higher monetary cost of processing per unit, or it’s 25% as good at analysing since it isn’t destructive, so you have to pass through 4x as many ingredients.


#5

I got it to work (sort of - need to fix the footprint, pretty sure I can get it down to 1x1). Fooled it by increasing concentration by “0”.
I picked shavings as output, think I have to pick SOMETHING… but still, it works as a 0 cost directional belt.
This in place of the analyzer/incinerator in the equipment.data would work (snipping out all the steam stuff).

This would show a 2x3 footprint, but the output is linear. will fix it later.

{
	"type":"machine",
	"id":"incinerator",
	"fixedIO":{
		"ioTiles":[
			{"m":0,"n":0,"d":2,"drugType":"all_except_box","io":"INPUT"},
			{"m":1,"n":0,"d":0,"drugType":"shavings","io":"OUTPUT"}
		]
	},

// “incinerator”:false,
“processor”:{“linearConc”:0},
“toolOffset”:{“x”:0,“z”:0},
“size”:{“x”:2,“z”:3},
“spriteName”:“incinerator”,
“spriteCollection”:{“all”:“incinerator”},
“animCollection”:“incineratorAnims”,
“ghostMaterial”:{“all”:“incineratorGhost”},
“layerInfo”:[
{“name”:“incinerator_a_”,“shadow”:true},
{“name”:“incinerator_b_
”},
{“name”:“incinerator_c_
”},
{“name”:“incinerator_d_
”},
{“name”:“incinerator_e_
”},
{“name”:“incinerator_f_
”,“mask”:true}
],
“steamInfo”:[
SNIP
],
“cost”:10,
“processCost”:0,
“processTime”:1
},


#6

I got it to the 1x1 footprint, will post the mod files in separate post, but here is it used to ‘solve’ your issue.

The “pass through analyzer” mod is do-able…bu note some people use them as incinerators though (complicated use case - w/ a chromatograph, IIRC).

Simple re-creation of 2 TBelt issue - not working:


Fixed w/ 0 cost analyzer mod:



#7

I might have to take that back… Can create a “pass thru” “analyzer” as shown above, but if you actually want an analyzer (find max concentration), not sure it is possible.
Guessing that if the code to perform analysis is left in, the ingredient will be deleted (incinerated).


#8

Yep, everything that has been said here is correct.

Sorry, I probably say the “Deterministic” thing a lot. What I mean is belts are by their definition, flexible. They need to be told what direction to move in by the machines they are connected to. This has been in the game since the very beginning of development and it’s not changing any time soon! :wink:

I agree that some kind of 1x1 machine that lets you tell the belt what direction to go would be pretty useful for this sort of thing.


#9

So I guess the issue is really that one machine can pass its “direction of travel” to one T Junction, but the junction then resets that, and a following junction just has to guess at which way to go?

In which case why can’t the machines pass a direction of travel back along from its “entrance” that informs the first junction it sees as it goes backwards… At least that way you could have two junctions chained instead of just one.

Or, a junction “machine” with settable entry/exit points would work, especially if you could upgrade it to pass two left for every one right, etc - could make some interesting lines that operate at different speeds with that.


#10

It’s a bit cleverer than that.

If you have a t-junction connected to 2 outputs then it knows that it must be a MERGER so it sets its remaining free connection to an output.

The same is true with 2 inputs to create a SPLITTER.

You can indefinitely chain T-Junctions of this nature because they are deterministic.

The problem only occurs when you have a truly indeterminate case such as in the screenshots above. If you think about it, the part of the line that never has any drugs on it could go in either direction and it would be a valid line. Given that the game cannot possibly know which the player is after*, it will just ignore that bit of belt.

*Unless there is an extra machine that lets you define the direction of a belt directly, as discussed.


#11

Was curious what this meant - not sure where I’d use it, but am sure it’ll come up.

Example of deterministic chained “SPLITTER” T-belts. I think the game logic proceeds in this way:

  1. Input ports on the Evaporators determine the 2 red (out) arrows on the 2 T-belts
  2. Purple (in) arrows only possibility left for the 2 T-belt
  3. 2 Purple arrows forces the Blue (out) arrows on the remaining T-belt
  4. Pink (in) arrow only possibility left for remaining T-belt

Note the ingredients coming from the top came from a port, but I can cut that line
(or stop the port) and the line will still continue until ingredients run out b/c it is deterministic.


Similar for deterministic chained “MERGER” T-belts. w/ less MSPaint.
Lines from top determined from ingredient ports. Bottom (non-terminated) spur is determined.



#12

Understood… That is clever, until the point where it isn’t (as per my OP).

I get that my belt in the original image could technically operate either way, in which case I naturally expected (and tried many times, as it happened) to be able to influence it by the way in which I chose to lay the belt.

I expected the belt to run in the way in which I dragged the mouse to lay it, in cases where it wasn’t able to calculate my intention by its usual method.

Alternatively, switchable or one-way belts would help greatly.


#13

Yes one-way belts would be be another perfect solution to this issue. PS Your diagram and explanation is absolutely spot on SCHMID6SIG. That’s exactly how it works.