0.13 Rainbow Belts and other madness

[Qon]

The PU modules does indeed seem to be a good fit for this technique.

[MeduSalem]

Processing units (with prod4) uses and outputs resources in a ratio of 20:2:1.4, so ideally you have a belt practically full of electronic circuits, and scatter in advanced circuits in a 10:1 ratio. Also since the electronic circuits are being removed at a phenomenal rate there is plenty of room on the input belt to accommodate the output.

So here is my latest feat of belt madness, count perfect belt mixing with asymmetrical input ratio and belt reuse for output. It feeds in green and red circuits in a 10:1 ratio.

[img]

Nice...

Notes:

• The first assembler outputs directly to the out belt - this is to break the "can't pick up, can't put down" deadlock that will otherwise occur if the processing units output (temporarily) gets backed up. With this special first output inserter it seems to be reasonably deadlock resistant.
• To make stronger guarantees against deadlock you can read the number of electronic circuits recirculating and use that as a condition to stop one of the input belts.

Another way to help preventing a deadlock would be also to use one assembler more down the line than the express belt allows total item throughput. That way all the excess circuits will get caught up in the last assembler at the end and almost nothing except the processing units return in the loop. And if something still passes (due to bad inserter timing etc) the first way around it gets grabbed the next round, but the returning items can't clog the loop anymore.

So basically abusing the belt throughput cap may suffice as deadlock prevention. But of course one of the assemblers will sit idle every now and then.

If you have too less assemblers then its guranteed to fill up eventually. At least I had to do that otherwise the outside belt lane would fill up and eventually block the output of processing units further down the line until the point that the "can't pick up, can't put down" deadlock occurred again.


The most punsishing effect is if you stop producing PUs and the belt getting filled by circuits. To start up from a clogged belt is pretty nasty... if not impossible with bad luck.. from what I noticed. It almost would be the best if one doesn't let that many circuits into the loop system in the first place.

So the advice of checking the circuit flow in the loop first hand might be the best way, though I am not really that good in circuit network contraptions to do that kind of thing...


For me Factorio circuit networks are not really all that logical compared to how other games do similar stuff. I for once can't really deal with how there are no boolean comparators like AND/OR/etc... how every boolean decision has to be implemented in a werid combination of arithmetic and decider combinators. It's absolutely not straight forward from a casual player's perspective and even one year after the advanced circuit network has been introduced I try to stay away from too complex circuit network stuff because of how ridiculously complex otherwise simple things may get because how certain functionality isn't there even it should be expected to be there.

So apart from simple IF-THEN-ELSE-trees becoming an absolute nightmare in factorio with circuit network combinators, I also find the wiring of stuff highly tedious. I hate that I always run short of red/green/copper wire even when I expect to have enough and how a mistake requires me to re-wire everything. Wish I could just simply drag&drop the wire out of electric poles or combinators and other items itself. :S

[BlakeMW]

The most punsishing effect is if you stop producing PUs and the belt getting filled by circuits. To start up from a clogged belt is pretty nasty... if not impossible with bad luck.. from what I noticed. It almost would be the best if one doesn't let that many circuits into the loop system in the first place.

Yes, if the output gets blocked the setup can easily deadlock. The strongest guarantee again deadlock is detecting recirculation and blocking input - under normal conditions the assemblers will gobble up all the electronic circuits so this shouldn't cause any loss of throughput. In my "production" model I set a recirculation detection of "Electronic Circuits > 3" so it could tolerate a few "inserter misses" without unnecessarily blocking the input.

For me Factorio circuit networks are not really all that logical compared to how other games do similar stuff. I for once can't really deal with how there are no boolean comparators like AND/OR/etc... how every boolean decision has to be implemented in a werid combination of arithmetic and decider combinators.

To me factorio's circuit network is more like a scripting language than traditional circuit logic because you work with variables which you perform arithmetic on. I agree it is pretty bizarre at times, and you almost need to learn patterns from more experienced players. Take for example AND/OR/NOR/XOR, these can all be calculated with a simple decider combinator:

In: Each > 0: Out: A (1)

The value of A is then how many input signals are truthy:

OR: A > 0
AND: A = 2
NOR: A = 0
XOR: A = 1

Now it's obvious to me how to do boolean, though when I started out I was frustrated with the lack of a simple AND/OR. But AFAICT there is no reason why the decider combinator can't have AND/OR as well as != as direct options to save having to use idiomatic combinator configurations.

[MeduSalem]

Yes, if the output gets blocked the setup can easily deadlock. The strongest guarantee again deadlock is detecting recirculation and blocking input - under normal conditions the assemblers will gobble up all the electronic circuits so this shouldn't cause any loss of throughput. In my "production" model I set a recirculation detection of "Electronic Circuits > 3" so it could tolerate a few "inserter misses" without unnecessarily blocking the input.

I did something similar... but somehow I couldn't find any values on how many misses to accept without "hitting" the input too much. It always ended up with too less items being inserted into the loop and assemblers eventually starving to death.

And also the inner belt lane gets used the most, with the outer belt lane being more prone to get stuck. And once that happens it prevents additional advanced circuits to be inserterted (in the case of crafting PUs) or PUs from being output to the outer lane, which both might lead either to further starvation or deadlocks.

It almost might be easier to pave the entire belt loop with a circuit network so you know exactly how many items there are on the entire belt... but then again you can't use underground belts etc.

Now it's obvious to me how to do boolean, though when I started out I was frustrated with the lack of a simple AND/OR. But AFAICT there is no reason why the decider combinator can't have AND/OR as well as != as direct options to save having to use idiomatic combinator configurations.

Well... the worst part is if I want to compare for example two item values with AND/OR etc, lets for example say I want to check if both Copper and Iron Plates are present simultaneously.

I can't do that directly. A single decider comparing Copper Plates and Iron Plates doesn't work directly because both items may be unpredictible numbers at the point of comparison.

So you have to use 3 combinators to do that. One that checks if Copper Plates > 0 and outputs 1, the second checks if Iron Plates > 0 and outputs 1, and the third takes the output from the first two deciders and checks if the output is =2 for AND or >0 for OR.

I have many practical usage scenarios where I have to perform exactly that kind of checks. Especially for load balancers and other stuff like that. Can't be done in a straight forward manner.


So having an AND/OR etc as direct option would solve the problem. The AND would return true if both input items are at least greater than 0. The Or would return true if at least one of the two inputs are greater 0, etc.


In my opinion circuit logic puzzles can be fun, but there is a limit to it as well. Requiring simple checks to become a huge project every time adds no fun.

[BlakeMW]

So you have to use 3 combinators to do that. One that checks if Copper Plates > 0 and outputs 1, the second checks if Iron Plates > 0 and outputs 1, and the third takes the output from the first two deciders and checks if the output is =2 for AND or >0 for OR.

My point is you don't. You only need 1 decider combinator:

In: Each > 0
Out: A (1)

The "Each" special signal iterates over each input signal. So if copper plates is > 0, then it outputs A = 1. Then if iron plates > 0, it outputs another A = 1, and the implicit adding results in an A = 2. You can then use that output signal of A directly in a connected inserter or belt.

Are you surprised that when you say "Out: A (1)", it can actually output A = 2? But that's because of how the Each signal works, the each signal is basically a shorthand for creating a bunch of combinators, each of which applies the operation and outputs the result separately.
In psuedocode the Each signal works like this:

Code: Select all

# put a A = 1 onto the network for each signal which is > 0
for signal_name in signals_names:
  if input_network[signal_name] > 0:
   output_network['A'] += 1

Unfortunately, making compact and expressive circuit networks requires a good understanding of implicit adding and how the Each signal works, and also how the green/red wires interact - best of all none of this behaviour can really be predicted and just has to be learned through experience. It's like a scripting language created by an insane genius.

edit: If you can't guarantee that iron and copper are the only signals on the network then you need two deciders: [Copper > 0, Out: A (1)], [Iron > 0, Out: A (1)] - you can then use the condition "A = 2" directly, relying on implicit adding.

[MeduSalem]

My point is you don't. You only need 1 decider combinator:

In: Each > 0
Out: A (1)

The "Each" special signal iterates over each input signal. So if copper plates is > 0, then it outputs A = 1. Then if iron plates > 0, it outputs another A = 1, and the implicit adding results in an A = 2. You can then use that output signal of A directly in a connected inserter or belt.

Yeah, I did know that "Each" iterates through all available signals... but I basically meant the situation you edited into your post:

edit: If you can't guarantee that iron and copper are the only signals on the network then you need two deciders: [Copper > 0, Out: A (1)], [Iron > 0, Out: A (1)] - you can then use the condition "A = 2" directly, relying on implicit adding.

Because for example with 0.13 I often connect the Circuit Network to a Roboport for convenience... so pretty much dozens of items get output to network. Then you really need to filter the two items you want to check for out with a decider per item basis so you can compare only those two signals implicitely. And that's when you can't get around using 3 deciders for what would be otherwise a quite simple setup. I say 3 deciders because I rarely can do something useful with the "A" signal... so I need to use the third decider to check if "A=2" so I can output another signal type.

A usage case for that is example a Load balancer in a smart furnace. Imagine you want to dedicate half the furnaces to Iron Ore and the other half to Copper Ore if both Iron Plates and Copper Plates are not at the specified target buffer limit. If one of them is at the limit then all furnaces shall smelt the type that is not at the limit. The output signals of the comparisons are eventually used as signal to set the Inserter filters at the furnaces. So basically if Both Iron and Copper Plates are "< Limit" then output Iron and Copper Ore as signal to be used as Inserter filter. If only one of both is "< Limit" only that signal should be output as a signal to set the inserter filter.

But of course we only want this construct to work when there are actually is enough Iron Ore and Copper Ore in the first place. If one of them is 0, then the furnace array would try to smelt that item type, but it can't because the input resource is lacking. In that case we want to dedicate the entire furnace array to the one item type that is available.

And if both Iron/Copper Ore are out of stock we don't want to smelt anything at all... So we can shut down the entire Furnace+Beacon array to save energy. But we also want to shut down the Furnace+Beacon Array if both Iron+Copper Plates are at the target buffer limit.

Currently this kind of IF-THEN-ELSE construct is quite... urgh. I got it to work though, so it's not impossible, but the setup could probably be more easier and compact if direct comparison with AND/OR would be possible rather than having to convert everything to intermediate signals which finally can be compared.

I use that kind of construct quite often... in every Beaconized setup to shut it down if either the target buffer limit is reached or one of the source items is out of stock.


But I guess that's far off topic now.

[Tricorius]

Brilliant. But it made my OCD scream in pain until I saw the "count perfect" version. So pretty.

[allon]

clearly underground belt braiding is superior especially in terms of raw throughput, but I consider that a grievous exploit and won't do it.

I am strongly opposed to the braiding cheat as well.

How can you consider it an 'exploit' or 'cheat' when it's explicitly and intentionally taught to the player by the "Tight Spot" campaign (starting from "Level 4", i.e. the second puzzle on map "level-02")?



If the developers made a level to teach you how to belt-braid, and made it a requirement to pass that level, I'd venture to think that they find it an acceptable practice, or perhaps even an important skill. It it realistic? Absolutely not, like many aspects of this game (and it's a better game for it). Is it an exploit or a cheat? I think not at all. Is it okay to hate it and avoid it at all costs? Absolutely. You have a huge freedom of choice in Factorio.

[MeduSalem]

How can you consider it an 'exploit' or 'cheat' when it's explicitly and intentionally taught to the player by the "Tight Spot" campaign (starting from "Level 4", i.e. the second puzzle on map "level-02")?

Because it wasn't always an official feature (nor required) in the game and has been only been declared official after some controversial discussion 2 years ago or something.

[allon]

declared official after some controversial discussion 2 years ago.

Well I guess that settles it. If it has been declared official then it's neither an exploit nor a cheat.

[MeduSalem]

Well I guess that settles it. If it has been declared official then it's neither an exploit nor a cheat.

But that's the problem... the decision to make it official is controversial because a lot of people still think that it is a cheat because it resulted of an unintended oversight or something.

[allon]

But that's the problem... the decision to make it official is controversial because a lot of people still think that it is a cheat because it resulted of an unintended oversight or something.

I wasn't around back then. How many is 'a lot'? What percentage of the player-base was against it?

Plastic and penicillin are unintended products that proved very useful. Would you advocate against their use just because their creation was a mistake?

[BlakeMW]

There's a number of things I consider exploits which probably aren't going to go anywhere. Atm my favorite is building gun turrets on islands (now you can even make the islands using landfill!), it's very overpowered against small biters.

Belt braiding is logistically overpowered, it could be said to be the no-brainer solution which precludes the need to come up with more creative solutions, furthermore it breaks suspension of disbelief as the belts "pass through" each other in a manner which real life belts would be unable to, highlighting the fact that in terms of game mechanics these are "item teleporters" (much as pipe to ground is in fact a liquid teleporter).

There is often a conflict between making the game play as intended and keeping its implementation straightforward. Offensive turreting is a really good example. Turrets have to be good against biters so you can build your factory in relative peace, and there's no logical reason why turrets shouldn't be able to blast away nests and worms. Turrets are generally the quickest and easiest way to take the offense against the biters and basically render pointless the actual offensive technologies such as the shotgun, tank, capsules etc. Now if offensive turreting were the intended way to take the offense to the biters then it doesn't make sense to have all those inferior options. The more logical conclusion is that turrets are intended for defense, not offense. But it's too hard to come up with a simple and intuitive game mechanism to prevent the offensive use of turrets, and so it kind of has the status "exploit which is here to stay".

As far as I'm concerned an exploit is something that breaks part of the game, and whether or not I use it depends how badly it breaks the game. Turrets on islands? I use that one, it only works where there is water, and only until small spitters, it's limited and amusing. But as a rule I don't use offensive turreting or belt braiding, I don't use them because they are be all and end all solutions to parts of the game.

[Qon]

Belt braiding is logistically overpowered, it could be said to be the no-brainer solution which precludes the need to come up with more creative solutions, furthermore it breaks suspension of disbelief as the belts "pass through" each other in a manner which real life belts would be unable to, highlighting the fact that in terms of game mechanics these are "item teleporters" (much as pipe to ground is in fact a liquid teleporter).
[...]
But as a rule I don't use [...] belt braiding, I don't use them because they are be all and end all solutions to parts of the game.

Is that for throughput you think they are OP? Would you use braiding for carrying input in one direction and output in the other or similar use where the braiding isn't used as "an even faster belt" replacement? Just curious.
Merging many UG belts together in a braid or splitting off anywheree or making non-straight paths and so on are challenges that make braiding not that straight forward. I personally have no problems with braiding.

But it's too hard to come up with a simple and intuitive game mechanism to prevent the offensive use of turrets, and so it kind of has the status "exploit which is here to stay".

If turrets needed 10 seconds to boot up after placing them then that would kill their offensive use and not affect their use as defence. It is very simple and if you have a small loading bar or similar it would also be intuitive. Nothing else have a similar mechanic on placement but if we are limited to that then we will probably not solve it.

As far as I'm concerned an exploit is something that breaks part of the game, and whether or not I use it depends how badly it breaks the game.

Victory poles. I tried it. I didn't like it. 0.13 improved that part I think. As long as my rails and such are safe.

[siggboy]

I love the rainbow belt.

About the last example, where you create a 2:1:1 belt for Advanced Circuits: this was possible in 0.12 by using a lane balancer (it created a perfect 1:1 of EC and Plastic on one side of a belt). The problem was what you mentioned, it could happen that a row of EC or Plastic developed and then the belt would slowly back off. I've actually never tried looping as you suggest.

I don't think the belt-counting balancer is "better" than the old-fashioned lane balancer, but I might be missing something. The belt counting balancer is a little more compact.

[siggboy]

But as a rule I don't use [...] belt braiding, I don't use them because they are be all and end all solutions to parts of the game.

Is that for throughput you think they are OP? Would you use braiding for carrying input in one direction and output in the other or similar use where the braiding isn't used as "an even faster belt" replacement? Just curious.

Chiming in here...
I'm also violently opposed to underground belt interleaving, just because it's ugly and cheesy. It only "works" if you use different belt colors, which makes it a poster child case of meta-gaming (bending the rules). If a particularly clever belt layout uses that, it does not count for the record.

If turrets needed 10 seconds to boot up after placing them then that would kill their offensive use and not affect their use as defence.

Man, that is actually quite clever. They should definitely change the turrets in that way. (Turret cheese is in the same league as belt interleaving.)

As far as I'm concerned an exploit is something that breaks part of the game, and whether or not I use it depends how badly it breaks the game.

Victory poles. I tried it. I didn't like it. 0.13 improved that part I think. As long as my rails and such are safe.

I don't think Victory Poles are an exploit, but they're another case of meta-gaming. Your knowledge about the game rules (biters don't expand where you build) enters the game world where it's not supposed to exist. Like talking to the gods, or having a sixth sense. It's even worse if you use the debug info (expansion candidate chunks).
People using it liberally shows that the combat/alien gameplay in Factorio needs work, since you should not have to resort to cheese in order to have fun.

[Qon]

As far as I'm concerned an exploit is something that breaks part of the game, and whether or not I use it depends how badly it breaks the game.

Victory poles. I tried it. I didn't like it. 0.13 improved that part I think. As long as my rails and such are safe.

I don't think Victory Poles are an exploit, but they're another case of meta-gaming. Your knowledge about the game rules (biters don't expand where you build) enters the game world where it's not supposed to exist. Like talking to the gods, or having a sixth sense. It's even worse if you use the debug info (expansion candidate chunks).
People using it liberally shows that the combat/alien gameplay in Factorio needs work, since you should not have to resort to cheese in order to have fun.

Well I responed to a sentence about exploits, but I'm not really opposed to it because of that and I'm not sure if it's an exploit or if I care. I think the cheesy victory poles are more boring than setting up turrets and just breaks the gameplay. As long as I have an efficient way to build and maintain my turret walls. Need some low terrain segmentation for that though...
Victory pole is a hilarious term though. I used power poles for them exlusivly because it made it funnier to think about even if the gameplay was void.

[MeduSalem]

But that's the problem... the decision to make it official is controversial because a lot of people still think that it is a cheat because it resulted of an unintended oversight or something.

I wasn't around back then. How many is 'a lot'? What percentage of the player-base was against it?

Don't know an exact percentage... for that we would need a poll and there never has been one about it... or at least none I would have known of. In my opinion if the devs are going to change certain game behaviour radically for whatever reason or enable certain things that developed out of an oversight/unintented side effect they should do something like a poll... which could be part of their Friday Facts Stuff, which acknowledges that a controversy exists (often the feeling of being heard is enough to calm people down, even if the course of actions following don't match their opinion).

If the community manager would take some popular topics of the forum and make another small poll (though they are never 100% representive but one may get general trends) every 2-3 weeks I think that they might gain some interesting insight on what the people think about certain stuff. Because reading everything people are suggesting or complaining about in the forum is obviously not possible without sacrificing development time. Many game development studios do something like that every month where the community manager gathers with the head of the development departments for an Q&A to discuss popular topics that players are currently concerned about or that are ongoing themes. So sometimes things come to their attention that they never realized, and on the other hand players get to know why some things are like they are and what's the intention behind them.

Plastic and penicillin are unintended products that proved very useful. Would you advocate against their use just because their creation was a mistake?

On a side note... I'm highly allergic to Penicillin. Makes me puke almost immediately. But I wouldn't advocate against its use because of it.

And well polymers have their own problems like environmental concerns since they take almost forever to decompose in nature.

That said one may consider me a member of the doom & gloom party because I think that mankind in general often is quite reckless with a lot of things they invented over the centuries. It's like many don't want to take the responsibilities for all the consequences that are coming with a new invention over the course of its existence. And because most people can't be arsed to care, which sadly is the truth, we are probably not going to need an asteroid to wipe us out like the dinosaurs. We are probably going to achieve that part on our own with some sort of doomsday device.

But now it's getting political and that's off topic... and if someone is interested in a debate over that feel free to PM me about it anyways.

[BlakeMW]

About the last example, where you create a 2:1:1 belt for Advanced Circuits: this was possible in 0.12 by using a lane balancer (it created a perfect 1:1 of EC and Plastic on one side of a belt). The problem was what you mentioned, it could happen that a row of EC or Plastic developed and then the belt would slowly back off. I've actually never tried looping as you suggest.

The main problem with a lane balancer is if one of the inputs dries up or is even less than saturated then it completely breaks down. The setups that use circuit-connected belts can handle such contingencies gracefully, the counter simply doesn't let either belt move, while the recirculation detection keeps gaps open in the belt to allow introduction of the dried up resource when it becomes available again.

[andywankenobi]

Could this sort of system be used for sparse ammo belt loops? I've been messing with various ways to keep a set amount of ammo on the belt but I haven't yet found a solution that works.