Friday Facts #384 - Combinators 2.0

[Burrguy]

It would be nice if there were some way to monitor power networks directly, yes you can use accumulators, but it would be nicer if you could measure power and then make a decision, like shut down parts of the factory before you have a blackout

[mrvn]

I still think we REQUIRE stack comb in the game because there is currently no way to DIVIDE an input signal by respective stack sizes. I.e., you are designing a Garbage Collector for your interrupt-based trains (a system that scans logistics inventory and pushes all items that can & should occupy a full train to a train). Let's assume we use 1-2 trains (1 locomotive, 2 cargo wagons). The train can hold up to 80 stacks of items. Okay, we know how to deliver it; we know how many to deliver, but WHAT to deliver?

What we SHOULD ACTUALLY do, is to export a logistics network inventory, divide it by a respective item stack size and select all signals >= 80. From those, we can now select a random one to put into a train. (The reverse, however, is quite possible because, unlike vector by-component division, vector by-component multiplication is possible due to the power of math.)

If you can select red/green wire as input source then you can divide a red input by green input. Now you just need a bunch of constant combinators to output the stack size of ever item. Inconvenient for a general, blueprintable station but no longer impossible. A stacksize in the airthmetic combinator would still be way more convenient.

A more general idea of this would be that the input should have a unit multiplier, where unit can be 1, stacksize, size of chest / tank / vehicle, k/M/G (unit of 1000 multiplier), s/m/h/d (units of time multiplier). With that more general idea you wouldn't even have to check for 80 stacks of an item to fill 2 cargo wagon but you divide the items by "each * cargo wagon" and check for >= 2.
Note: mods have differently sized cargo and fluid wagons.

[mrvn]

It would be nice if there were some way to monitor power networks directly, yes you can use accumulators, but it would be nicer if you could measure power and then make a decision, like shut down parts of the factory before you have a blackout

Especially if you could check the current and potential energy. Especially with solar power you need to know how much energy the solar cells can provide at the moment. I know you can make a clock and compute the amount but the clock can easily get out of sync and then all the calculation is wrong.

Why not have a wire connection on solar panels that give out the current power draw, maximum power and current power available?

[Tertius]

If you can select red/green wire as input source then you can divide a red input by green input.

Unfortunately, the screenshots in fff-384 show you can select the input source (red/green wire) with the new decider combinator, but not with the arithmetic combinator. The enhancement of the arithmetic combinator is just a display of the current values in the combinator GUI. Functions like EACH(red input) * EACH(green input) seems to be still not possible.

[mrvn]

If you can select red/green wire as input source then you can divide a red input by green input.

Unfortunately, the screenshots in fff-384 show you can select the input source (red/green wire) with the new decider combinator, but not with the arithmetic combinator. The enhancement of the arithmetic combinator is just a display of the current values in the combinator GUI. Functions like EACH(red input) * EACH(green input) seems to be still not possible.

Verry unfortunately. But I think that problem has been stated multiple times here already.

[Tertius]

Well, uh, it cannot be stated often enough.

[Hares]

I still think we REQUIRE stack comb in the game because there is currently no way to DIVIDE an input signal by respective stack sizes. I.e., you are designing a Garbage Collector for your interrupt-based trains (a system that scans logistics inventory and pushes all items that can & should occupy a full train to a train). Let's assume we use 1-2 trains (1 locomotive, 2 cargo wagons). The train can hold up to 80 stacks of items. Okay, we know how to deliver it; we know how many to deliver, but WHAT to deliver?

What we SHOULD ACTUALLY do, is to export a logistics network inventory, divide it by a respective item stack size and select all signals >= 80. From those, we can now select a random one to put into a train. (The reverse, however, is quite possible because, unlike vector by-component division, vector by-component multiplication is possible due to the power of math.)

If you can select red/green wire as input source then you can divide a red input by green input. Now you just need a bunch of constant combinators to output the stack size of ever item. Inconvenient for a general, blueprintable station but no longer impossible. A stacksize in the airthmetic combinator would still be way more convenient.

A more general idea of this would be that the input should have a unit multiplier, where unit can be 1, stacksize, size of chest / tank / vehicle, k/M/G (unit of 1000 multiplier), s/m/h/d (units of time multiplier). With that more general idea you wouldn't even have to check for 80 stacks of an item to fill 2 cargo wagon but you divide the items by "each * cargo wagon" and check for >= 2.
Note: mods have differently sized cargo and fluid wagons.

I've recenently managed to design almost-fully-functinoal vector to vector divisor. It has some flaws (i.e., it likes off-by-one errors due to calcuations precision), but it generally works for larger numbers. How it works:

1. Divide a very big constant by a denominator
2. Use vector multiplication to multilply a nominator by the result of previous operation
3. Divide the result by that big constant

Code: Select all

R = A / B - what wee need to find
C - Constant

R = A / B = A * (1/B) = A * C/C * (1/B) = (A * (C/B)) / C

[Nidan]

I've recenently managed to design almost-fully-functinoal vector to vector divisor. It has some flaws (i.e., it likes off-by-one errors due to calcuations precision), but it generally works for larger numbers. How it works:

1. Divide a very big constant by a denominator
2. Use vector multiplication to multilply a nominator by the result of previous operation
3. Divide the result by that big constant

Code: Select all

R = A / B - what wee need to find
C - Constant

R = A / B = A * (1/B) = A * C/C * (1/B) = (A * (C/B)) / C

Mind adding a blueprint and some discussion to this thread? If this one stays within +/-1 for any input, it's a decent size improvement over the one currently posted there.

[mrvn]

Code: Select all

R = A / B - what wee need to find
C - Constant

R = A / B = A * (1/B) = A * C/C * (1/B) = (A * (C/B)) / C

That about halfs the precision, so basically only for numbers up to 32767 in general. So generally useless.

You can also generate the division in a loop taking a multiple of 32 ticks. Again generally useless when you have constantly changing inputs.

[Hares]

Code: Select all

R = A / B - what wee need to find
C - Constant

R = A / B = A * (1/B) = A * C/C * (1/B) = (A * (C/B)) / C

That about halfs the precision, so basically only for numbers up to 32767 in general. So generally useless.

You can also generate the division in a loop taking a multiple of 32 ticks. Again generally useless when you have constantly changing inputs.

You are completely right, but the most common use-case of vector division is to determine how many stacks of each item is in the set, which this will do perfectly fine.

[mrvn]

With mods I have a stacksize for e.g. Landfill of 1000. Which means the division is limited to values up to 2 million, which my store of ore can exceed quite easily. So not even a general solution for computing stacks.

[dragon-architect]

I'mm'a wake this thread back up a bit because I dunno if anybody else has asked about it but I would like to know:

Since y'all have certainly gone in and massively re-worked whole chunks of game code for both previous and subsequent FFF features, would it be possible to also overhaul the circuit network code to give the circuit network and especially circuit control behavior a more moddable API? It would certainly make it easier to not have to hack-mod reporting statistics into, say, the Constant Combinator, just to know more about what a particular entity is doing, when we could just mod the control behavior of the entity itself to have the entity directly output to the circuit network.

I know that this has been requested in the past elsewhere on this forum, and quite harshly shot down as a won't do, but that was before serious work had been started on Factorio 2.0, and the reasons given were that it would have required far, far, far too much refactoring of the game's code to make it happen.

Would this still be a too daunting task to refactor the circuit network code to implement a more moddable API?

[mrvn]

First I would just want to have 3 or 4 colors for the wire. The interface already has 2 so enlarging that to 4 should not be such a daunting path.

[dragon-architect]

First I would just want to have 3 or 4 colors for the wire. The interface already has 2 so enlarging that to 4 should not be such a daunting path.

Oh, yeah, definitely. Having a couple of extra circuit network channels would be nice. But I suspect that the idea may get turned down as overcomplicating it a bit too much.

Edit: After thinking about it, yeah. Adding additional wire colors would require having to re-do basically ALL of the entity graphics associated with the circuit network in order to add third or fourth connection points for the new channels.

Would it be awesome to see? Heck yeah. I'd love it.

Are we likely to see it? I'd be pleasantly surprised if the devs said they'd consider it.

[mrvn]

First I would just want to have 3 or 4 colors for the wire. The interface already has 2 so enlarging that to 4 should not be such a daunting path.

Oh, yeah, definitely. Having a couple of extra circuit network channels would be nice. But I suspect that the idea may get turned down as overcomplicating it a bit too much.

Edit: After thinking about it, yeah. Adding additional wire colors would require having to re-do basically ALL of the entity graphics associated with the circuit network in order to add third or fourth connection points for the new channels.

Would it be awesome to see? Heck yeah. I'd love it.

Are we likely to see it? I'd be pleasantly surprised if the devs said they'd consider it.

Changing the graphics I think would be the least problem. I'm pretty sure there are lots of cases where the code basically reads:

Code: Select all

for (i = 0; i < 2; ++i) { ... }

instead of

Code: Select all

for (i = 0; i < MAX_WIRES; ++i) { ... }

. That goes for mods too.

As for overcomplicating ... I would guess the opposite: "It makes wires too easy so there is less of a puzzle there." sort of argument.

[dragon-architect]

Changing the graphics I think would be the least problem. I'm pretty sure there are lots of cases where the code basically reads:

Code: Select all

for (i = 0; i < 2; ++i) { ... }

instead of

Code: Select all

for (i = 0; i < MAX_WIRES; ++i) { ... }

. That goes for mods too.

As for overcomplicating ... I would guess the opposite: "It makes wires too easy so there is less of a puzzle there." sort of argument.

I'm not going to speculate on what the code actually says, since I'm not one of the developers.

But I do see the argument that adding wires would make complex circuits less of a puzzle as making some sense. It is certainly a pathing puzzle not too dissimilar to planning a 2-layer PCB.

[mrvn]

Changing the graphics I think would be the least problem. I'm pretty sure there are lots of cases where the code basically reads:

Code: Select all

for (i = 0; i < 2; ++i) { ... }

instead of

Code: Select all

for (i = 0; i < MAX_WIRES; ++i) { ... }

. That goes for mods too.

As for overcomplicating ... I would guess the opposite: "It makes wires too easy so there is less of a puzzle there." sort of argument.

I'm not going to speculate on what the code actually says, since I'm not one of the developers.

But I do see the argument that adding wires would make complex circuits less of a puzzle as making some sense. It is certainly a pathing puzzle not too dissimilar to planning a 2-layer PCB.

If only there where instant through holes. A wire with one side red and the other side green.

[dragon-architect]

If only there where instant through holes. A wire with one side red and the other side green.

I could suggest an arithmetic combinator set to Each+0=Each to accomplish that.

[pleegwat]

If only there where instant through holes. A wire with one side red and the other side green.

I could suggest an arithmetic combinator set to Each+0=Each to accomplish that.

That's not instant. That's got a delay of 1 tick.

[FuryoftheStars]

If only there where instant through holes. A wire with one side red and the other side green.

I could suggest an arithmetic combinator set to Each+0=Each to accomplish that.

That's not instant. That's got a delay of 1 tick.

I have a feeling the devs will not want to add anything that can take in a signal and then output another in the same tick due to the continuous loop issue.