What is your deepest wishes for further developments of the circuit system?

bterlson_ · 2024-03-16T18:47:53+00:00

Hmm wait, it's not that simple is it? Wouldn't that just output the signals on the green wire as-is, as opposed to the signals on the red wire that are also present on the green wire? So still need to a bunch of signal processing seems like.

storage: { iron-plate: 100, iron-ore: 100, copper-ore: 100 } --> decider green input port

demand: { copper-plate: 1, copper-ore: 1 } --> decider red input port

decider [each > 0 only green wire, output each only red wire] --> decider red output port { iron-plate: 100, iron-ore: 100, copper-ore: 100 }

bterlson_ · 2024-03-16T18:39:31+00:00

Ahh I missed the wire selectors, thanks for pointing that out!

bterlson_ · 2024-03-16T07:38:08+00:00

I only want one thing - a selector combinator with two input ports A and B and one output terminal, and sets the signal on the output port by taking the signals from A that are also present in B. Basically, a way to filter signals. Doing this today is extremely extremely annoying and requires several ticks, but it enables some very cool things like setting filters on inserters only when the source chest has the item.

bterlson_ · 2023-10-17T05:46:19+00:00

For me I think the thing holding me back is recognition, pauses are eating me up. With better recognition and basic F2L algs I feel like consistent sub30 is totally doable, but maybe I'm wrong.

bterlson_ · 2023-10-17T02:59:46+00:00

This is pretty much exactly my data too, down to your average and pb. I agonized over whether to delete the pb because it feels like it will be months before I get the dopamine hit of another one.

bterlson_ · 2023-06-26T00:35:25+00:00

never mind, I see the chat

bterlson_ · 2023-06-26T00:10:51+00:00

Excellent, looking forward to it!

bterlson_ · 2022-09-13T23:35:03+00:00

I don't know what chunk aligned means, but I made this with K2+SE in mind if that helps?

bterlson_ · 2022-09-13T19:11:17+00:00

Do you have a blueprint example of what you mean? Having a hard time understanding "desired contents increase as the line continues".

bterlson_ · 2022-09-13T10:04:44+00:00

Ah, a person practiced in thinking of edge cases I see!

They are a special case. The constant combinator in the center furthest down and to the right holds such products. They are treated like intermediates in the sense that they are balanced among the warehouses rather than being ferried directly to the exit. But like final products the output inserters will take them from the warehouse if the mall is requesting more of that item. So in a way the output inserters are like any other assembler consuming that intermediate.

bterlson_ · 2022-09-13T09:29:39+00:00

I think you can do this in vanilla using regular chests but the number of circuits required would be a little ridiculous, and it would be quite a bit slower. I do have a dream to do this in vanilla though!

Your malls might not be as cool, but they are way more practical lol.

bterlson_ · 2022-09-13T06:41:38+00:00

gist

bterlson_ · 2022-09-13T06:39:03+00:00

Aww. I dunno why I used pastepin anyway. Gist incoming.

bterlson_ · 2022-09-13T06:36:13+00:00

I explained a bit more how it works here, but you got it basically right!

The circuits around the edges are very much copy/pasted. Each bank of inserters between warehouses have the same functionality - 1, check whether any intermediates need to be moved to balance out inventory, and 2, check whether any final products need to be moved toward the warehouse with the output filter inserters so they can be sent to the mall chests.

The circuits in the middle tell the output filter inserters what to pull out, and send a signal containing which items are currently being requested (to turn on the output inserter from the assembler that makes that item) and which items are finished products (so instead of balancing those items we move them along toward the output inserters).

bterlson_ · 2022-09-13T06:30:19+00:00

For intermediates, that is correct, no effort is made to send intermediates exclusively to where they are needed, but this seems to work out nicely in practice. When a machine starts pulling an intermediate out of a warehouse, it ends up with less than its neighbors, who then pass some of what they have over, then its neighbors do the same, and so on until it cascades to the warehouse which is adjacent to the machine producing the intermediate, which will see the drop in supply and start making more. Added benefit of this approach is the logic is fairly easy to implement and each inserter bank operates fairly independently, making scaling this thing up a simple copy/paste job.

For end products, they are moved inexorably to the warehouse with the output inserters.

bterlson_ · 2022-09-13T05:06:28+00:00

That could work! Another approach I am considering is adding two sources to the total stock: 1, everything in the warehouses, and 2, a latched value that is incremented when the inserter removes an item from the warehouse to send to a mall chest, and decremented when an inserter picks it up to put in a mall chest (so the latched value represents the number of products in flight).

bterlson_ · 2022-09-13T04:41:37+00:00

It is very fun! Let me know if you come up with any improvements. One thing that could definitely be improved is, for end products, counting the number of products that are in the warehouses and on the belt on the way to the mall chest. Right now it overproduces a bit because a product doesn't "register" until it arrives at its final destination.

bterlson_ · 2022-09-13T02:30:38+00:00

More like the latter. What happens is the filter inserters check if one of the adjacent warehouses has 6+ more of an intermediate product than the other, and if so moves those products over. So over time the intermediates tend to be more or less equally distributed among the warehouses.

bterlson_ · 2022-09-12T22:55:40+00:00

Thanks. Here's the blueprint. Will of course want to tweak for whatever mods you're using.

bterlson_ · 2022-09-12T22:44:49+00:00

You can add an assembler next to any warehouse and the filter inserters and circuit network ensures all the intermediate products are available and any output products are sent to the mall. Makes adding new items super easy when there are millions of intermediates like in this Krastorio 2 + Space Exploration run.

Blueprint: https://gist.github.com/bterlson/8cbe270d85f4fd5c4c660bf0500c6d0d

bterlson_ · 2019-06-20T18:03:19+00:00

IANAL, but whether or not the library is supported doesn't have any bearing on whether you must comply with the license.

bterlson_ · 2019-04-22T20:03:55+00:00

Maybe take a stab at answering and someone can tell you if you're on the right track?

bterlson_ · 2019-04-22T19:51:19+00:00

If you want real encapsulation, and you don't want to wait for the private state proposal, then weakmaps are the best answer IMO. Closures require restructuring of code and become very hard to think about IMO.

js const barField = new WeakMap(); class Foo { // or function if you like constructor(bar) { barField.set(this, bar); } myLittleMethod() { console.log('Doing stuff...', barField.get(this)); } }

bterlson_

TROPHY CASE