Factorissimo2, but for combinators, and without extra surfaces...

[slippycheeze]

Dear lazyweb, please build me a mod that does magically awesome things, so I don't have to:

A device, 3x2 or so in size, that would contain a larger set of combinators that the physical footprint, to effectively hide the internal wiring. Factorissimo2 is kind of an inspiration, but not suitable here because signal transfer is done with lua scripting and the desire is identical behaviour to the same combinators without the "cover" hiding them.

Rather than words, bullet point list of desires:

• one input pair, one output pair, like a math or decider combinator. both red and green in/out.
• bonus points: two or three distinct input pairs. only one output pair needed.
• implemented by cloning all the combinators, making them invisible, and non-colliding, and wiring them together in a script. (see below for more on this)
• provides something -- a GUI, a separate magical surface dedicated to it, whatever -- to allow wiring arbitrary but space-limited amounts of combinators into a single thing, with the input/output points visible. but just as a template.
• blueprints successfully, even if you need to pack complex tables into a contant combo or whatever to make it work.
• since I'm already asking for ponies and unicorns, dress it up in a nice, pretty skin, like a fancy computer device.

Specifically, I'm thinking of an implementation to ensure that behaviour is now, and always will be, consistent with whatever circuit network things people choose to do:

Make a clone of all the circuit network entities, including sensors, and make them invisible, off-grid, and non-colliding.

This is instead of having a real separate surface for the complexity to live in (eg: belt/pipe layer mod, factorissimo), treat the "build" location as a way to wire stuff up, and wipe it when done. reconstruct if opened again. so, slower transitions in/out, but no surfaces involved.

once the insides are mutated, place all the same entities and wiring, but all sitting together inside the container, so that the third party mod sensors, etc, are positioned where the container object is positioned. wire things together the same way, so the "on the actual surface" entity is identical to the one inside the build ... and to doing the same build all spaced out with normal combinators.

[ZombieMooose]

My UPS dropped just reading this post.

[eradicator]

I've pondered the concept several times over the years, even did a proof-of-concept once, but since i don't use circuits that much myself i've never bothered to make it a complete mod. But i'll throw some questions at you that i only have partial answers for myself (due to lack of own circuit usage again):

How many in/outputs do you *really* need. No wishful thinking. Can you give examples for common circuit abonimations that you would use this for? If i think for example of a lamp-grid controller that would as far as i understand need at one (better two?) output channels (==wires) per digit.

Blueprintability is annoying. I can think of some hacks, but the more i know about the engine (and /editor mode) the less nice all the hacks i know are.

Do you really need *modded* circuit entities *inside* the computer? For all i can tell it should be a) sufficient to have the 4 base variants because mods can not add new compinator logic and b) for "sensors" the *implementing* mod author would have to actively support this configuration for the control-stage logic (which drastically decreses the maintainability of the "computer" mod). I'm not familiar with sensors either, but as far as i understand most of them need to be placed "next" to something (chest, tank, etc) so they would be worthless *inside* the "computer".

(Disclaimer: This post is more of a "let's talk about it" than a "i'm interested in implementing it" :p. Also pretty sure there's been similar topics before.)

[mrvn]

+1 for this

More than one input/output is certainly desirable. I would say the mod should have a number of containers. 1x2, 2x2, 3x2, 4x2 with the respective number of inputs/outputs.


I also would like a second mode for this. Instead of a totally custom build inside how about having an input field for a formula? You enter "(coal + iron) * steam / 5" and it builds a circuit network for it.

[slippycheeze]

I've pondered the concept several times over the years, even did a proof-of-concept once, but since i don't use circuits that much myself i've never bothered to make it a complete mod. But i'll throw some questions at you that i only have partial answers for myself (due to lack of own circuit usage again):

How many in/outputs do you *really* need. No wishful thinking.

One wire in, one wire out. Anything else could be built on top of multiple boxes. (and no recursion is needed, thanks.)
One red/green pair would be desirable. More ... eh, just convenience. Sometimes having more separate outputs is useful, but it is never mandatory. Can always do stuff to split them out or whatever.

Blueprintability is annoying. I can think of some hacks, but the more i know about the engine (and /editor mode) the less nice all the hacks i know are.

Yeah. The least worst option I saw was someone with the pure lua msgpack library stuffing words into a constant combinator. Not what I'd call nice, for sure.

Do you really need *modded* circuit entities *inside* the computer?

I was thinking of the various "constant combinator in a funny hat" that implement sensors such as time of day, or similar logic, and so don't have much configuration. In most cases they don't require a specific position like, eg, "inventory sensor" to tell them what to interact with, they just have a bit of lua attached that mutates the signals in the combinator from time to time.

It would be quite nice, but, eg, "only what can blueprint" would be fine so far as I was concerned.

(Disclaimer: This post is more of a "let's talk about it" than a "i'm interested in implementing it" :p. Also pretty sure there's been similar topics before.)

I don't expect anybody to implement this for me.

Can you give examples for common circuit abonimations that you would use this for? If i think for example of a lamp-grid controller that would as far as i understand need at one (better two?) output channels (==wires) per digit.

Heh. I'm too ashamed to post my roboport / logistic network robot count manager, because apparently it has a bug where it'll enter an endless loop if the storage box for unused robots is far enough away from the active provider they are put into when ejected from the network.

However, it was ten decider/arithmetic combinators to handle all the logic, so a 4x4 plus 2x2 chunk of space for the core logic. Input was the CC for setting the count, and a wire from a roboport, then output-wise it had three inserters, and two logistic chests setting request counts, from four different "final calculation" combinators. Plus a separate output for the "number missing" to allow LTN requests to happen automatically.

Small, but very desiring of pretty, the trivial nixie tube based percentage display. Those combinators do the fixed point math to get a `100.00%` format percentage display output as two separate numbers (one zero-padded) displayed nicely.

0eNrtWktu2zoU3YrBYSu3JPW1p28DGXXyEBi0TNtEZUqQqKRC4AW8XXTSjXUlJS1HUiTRJu04QYOXQQIpuoe85/B+SOkJLJOSZjnjAsyfAItTXoD5v0+gYBtOEnVPVBkFc7BOSrYCDuBkpy4fiaA52DuA8RX9AeZo74wYMUF3rc26mGIIO0Z41OiB5aKUdxq7+olp2LF0rSwzmsdUetjae/t7B8hbTDBaO3y4qBa83C2lY3PUYHD2g9GpKJdU4mZpIU1SrgaVMFPXAZX8g7/4EluSJ/I0WSzpljywNFcPxSyPSyYW8n+rxnLN8kIsjKd/B2rwQhAl0xQjL/QiN/AidXuXkZwINRr4/d8v9WhZUDlekubSM5GXtLbmNFbjF2pApH5tckp513epr5Tkfr9X5Pb4wGZ84I/GB+pwoa7d3jXyncanU/y5Zvyhv5i/nK4G7AUDdhzdunvJq6fh0RvhcUqSbEuGbMK3IJPwSmwZ37zkFA6Y/HkdkxhqqesvSV9DnW+0BNFHi2CvR0+goScwogd/sACdmQao36Mx1NAYWgSo+5ECFGmp0624qJnq87ymck5Lxg9zGhYH70iXhqw1S2RPpmnfXnZihRyAbKQ4hH+veSkVKZFtO+fDjrV3pq/TNYNHc4wv7O6UGB0Y2MCEVjCSEb6hXX/8BimyQhIKSLbUXbCgBZtZgVU0SdLHDtKsdRBBK6h6cbZICHagkBVUXJEukg/VTwumuiCLFN1LQuhMj4U08TRrZklyJrY7Klh8OqKOCQhqE1AL1Oag4kQSOh1mBVUgizYLYf9AWyo3KKSeF/gkzdNSZKVFivsHKD7M+Y76BMMhwQ7A+qYYmjW96jlLRfBtFWly1kAKH76LFOeWPrJTZlDOT8NphUPWwqGbC3csF8Mggu8j3fVR0xMHn1kLgVkaRNhWPClarZ4cEqxYXrt/aHZfQ8kThI/IiYZqfn0LNUdC46jmWN8cGgaSax1IdZeHXi2OdARREm91AlwfTN9G6ceG5wTape1dWOJvT+fdKJcqLV5L5Z1+JY9R6VtmJcMDLNQeH6xozFY0Nynket6PIK+6hm032L2dtL00z+PHaVYtDr3wYp2nuwXjEua4g7SQzrMrAPrNenRG9EHp8QwXQXBhX1Cvg05p8W4bjd8uWRWHenRt3bGMVtdUUrv65F64hULhpb0DfNPWQVu8eqXr8+1LFz7T1UWGzEe2zP8fWScjK9TGy3h8zQx1sj5lwO+i051Zb/f5dYUYpzaySV2601IM7Y5L67c/2CgtnTw61dFQiDTrnqZ1Dk/vzdep7kUXRnbuurd2t/MS/TqP6zcHss4ddvjzzhcIDkjIkibPXxtMEvpAk8ku5Uy6PJlO1DnapKgKaTd5lGEyIbyaPH+Y8CA9OjgduhBFgRu5brDf/wFXrjz3

Copy blueprint

Image, not inlined: https://cdn.discordapp.com/attachments/ ... eprint.png

Those honestly give the gist of it. I have a handful of other bits and pieces in various states of construction, such as a player safety gate for a railway. That one is in a state of disrepair as I found a nice trick someone else posted to eliminate many of the combinators I previously used.

The oil cracking and level management is similarly sized, a variety of input/output balancing things to control buffer size, etc, some warning systems built with programmable speaker alerts for, eg, power fail-over events if generation isn't keeping up.

Not too extreme, just things that are a bit sprawling, and attached to things supposed to look pretty, or that are tied, haha, by wire length to things I see a lot like train stations.

[slippycheeze]

I also would like a second mode for this. Instead of a totally custom build inside how about having an input field for a formula? You enter "(coal + iron) * steam / 5" and it builds a circuit network for it.

Both LuaCombinator, and some other mod, both already implement this.

[mrvn]

I also would like a second mode for this. Instead of a totally custom build inside how about having an input field for a formula? You enter "(coal + iron) * steam / 5" and it builds a circuit network for it.

Both LuaCombinator, and some other mod, both already implement this.

But afaik they do that with LUA script on_tick. That makes it totally unusable for more than a few instances.

I'm talking about taking the formula and creating a network of standard combinators to compute it natively in the game. That way it runs way faster and only when a signal changes.

[eradicator]

Do you really need *modded* circuit entities *inside* the computer?

I was thinking of the various "constant combinator in a funny hat" that implement sensors such as time of day, or similar logic, and so don't have much configuration. In most cases they don't require a specific position like, eg, "inventory sensor" to tell them what to interact with, they just have a bit of lua attached that mutates the signals in the combinator from time to time.

It would be quite nice, but, eg, "only what can blueprint" would be fine so far as I was concerned.

It's not possible to automatically discern between "sensors" with or without location awareness at data stage though. And trying to manually support the whole fuckton of "something-sensor" mods would probably make hell feel like a nice place for summer vacation. So personally i'd go either the "nope" route, or implement simple sensors into the mod itself. (Reinventing the wheel is meh, so heavily biased to "nope".)

I'm talking about taking the formula and creating a network of standard combinators to compute it natively in the game. That way it runs way faster and only when a signal changes.

Turning an arbitrarily long and arbitrarily complex formula into a working combinator network is a huge load of complicated theorycrafting and optimizations. Though no doubt worth it, it sure would help if there was some groundwork done for whoever-implements-this to look at. If you want it to ever happen you should make a thread about just that part.

[slippycheeze]

Do you really need *modded* circuit entities *inside* the computer?

I was thinking of the various "constant combinator in a funny hat" that implement sensors such as time of day, or similar logic, and so don't have much configuration. In most cases they don't require a specific position like, eg, "inventory sensor" to tell them what to interact with, they just have a bit of lua attached that mutates the signals in the combinator from time to time.

It would be quite nice, but, eg, "only what can blueprint" would be fine so far as I was concerned.

It's not possible to automatically discern between "sensors" with or without location awareness at data stage though. And trying to manually support the whole fuckton of "something-sensor" mods would probably make hell feel like a nice place for summer vacation. So personally i'd go either the "nope" route, or implement simple sensors into the mod itself. (Reinventing the wheel is meh, so heavily biased to "nope".)

Uh, yeah, I'm honestly just thinking of "if it breaks you get to keep both parts" level of support for them. Likewise, "if it doesn't blueprint correctly, you get to keep both parts" for moving the entities to a different surface. perhaps it'd be possible to use a single chunk in the furthest corner of the world for this. wonder if that'd work, too, I guess, since you can teleport entities on the same surface, and there is no wire distance checking on that. *shrug*

I'm talking about taking the formula and creating a network of standard combinators to compute it natively in the game. That way it runs way faster and only when a signal changes.

Turning an arbitrarily long and arbitrarily complex formula into a working combinator network is a huge load of complicated theorycrafting and optimizations. Though no doubt worth it, it sure would help if there was some groundwork done for whoever-implements-this to look at. If you want it to ever happen you should make a thread about just that part.

Yeah, several different tools exist that do this. They are ... far from optimized, shall we say? I see why you would like this. Seems like a decent idea. I think that like anything other than "we do our best" level stuff here, it is extremely challenging to anything that isn't very limited in scope.

For example, the Factorio state machine language builds a system driven by a counter, using that as an instruction pointer incremented every tick, to walk through the machine. Latency between instructions will vary, but a backward jump has a cost based on having to wrap around the far end of the device, back to the start, then reach the destination address. (if I understand the model correctly, at least.)

I'm not honestly sure that the problem space doesn't hide at least one NP-hard problem inside it, too. So, not just hard, but hard in a way that is impossible to do better than polynomial time processing to solve. That scales ... poorly, in-game, in Lua, even just calculating the layout.

Just trying to apply standard computation models with Factorio combinators is ... challenging, at best. They have semantics that are wildly different to standard computing models. Trivial operations that could easily be built by a human, those are easy. Once you start to try and do anything difficult, like loops, or conditionals, things get hard.

We don't have good programming language models for a system with analog logic between components, digital logic within them, a combination of wildly SIMD and extremely limited SISD operations, and nothing but delay-line memory. They have more in common with SISAL or Single-Assignment C than anything else, but a wild combination of things. Those are rare languages, usually in specialized domains, and optimizations on them even less known than algol style procedurals.

You can see this is the relative performance of classical CPU components built on top of combinators.

....but this is getting way off topic for this thread, even if it is interesting.

[mrvn]

I'm talking about taking the formula and creating a network of standard combinators to compute it natively in the game. That way it runs way faster and only when a signal changes.

Turning an arbitrarily long and arbitrarily complex formula into a working combinator network is a huge load of complicated theorycrafting and optimizations. Though no doubt worth it, it sure would help if there was some groundwork done for whoever-implements-this to look at. If you want it to ever happen you should make a thread about just that part.

"All" you do is parse the input into an AST (abstract syntax tree). For a purely mathematical term this is rather trivial. The AST then directly translates into the combinator setup. Each node in the tree is one combinator. I'm not talking about optimizing anything there. No common subexpression elimination for example. Only thing I might consider would be something to equalize signal run times, which just inserts a few "each + 0 = each" combinators into shorter branches of the AST.

Yeah, several different tools exist that do this. They are ... far from optimized, shall we say? I see why you would like this. Seems like a decent idea. I think that like anything other than "we do our best" level stuff here, it is extremely challenging to anything that isn't very limited in scope.

For example, the Factorio state machine language builds a system driven by a counter, using that as an instruction pointer incremented every tick, to walk through the machine. Latency between instructions will vary, but a backward jump has a cost based on having to wrap around the far end of the device, back to the start, then reach the destination address. (if I understand the model correctly, at least.)

I'm not honestly sure that the problem space doesn't hide at least one NP-hard problem inside it, too. So, not just hard, but hard in a way that is impossible to do better than polynomial time processing to solve. That scales ... poorly, in-game, in Lua, even just calculating the layout.

Just trying to apply standard computation models with Factorio combinators is ... challenging, at best. They have semantics that are wildly different to standard computing models. Trivial operations that could easily be built by a human, those are easy. Once you start to try and do anything difficult, like loops, or conditionals, things get hard.

We don't have good programming language models for a system with analog logic between components, digital logic within them, a combination of wildly SIMD and extremely limited SISD operations, and nothing but delay-line memory. They have more in common with SISAL or Single-Assignment C than anything else, but a wild combination of things. Those are rare languages, usually in specialized domains, and optimizations on them even less known than algol style procedurals.

You can see this is the relative performance of classical CPU components built on top of combinators.

....but this is getting way off topic for this thread, even if it is interesting.

A non-programmable pocket calculator (because that's the level of complexity I'm talking about) has none of that. The only operations you have are those the arithmetic combinator provides and (). No loops, no branches, no memory cells.

[slippycheeze]

I'm talking about taking the formula and creating a network of standard combinators to compute it natively in the game. That way it runs way faster and only when a signal changes.

Turning an arbitrarily long and arbitrarily complex formula into a working combinator network is a huge load of complicated theorycrafting and optimizations. Though no doubt worth it, it sure would help if there was some groundwork done for whoever-implements-this to look at. If you want it to ever happen you should make a thread about just that part.

A non-programmable pocket calculator (because that's the level of complexity I'm talking about) has none of that. The only operations you have are those the arithmetic combinator provides and (). No loops, no branches, no memory cells.

Ah. I see. Then yes, it isn't as hard as I thought. If I had understood your statement as you intended, I'd have agreed that it was fairly easy to have that automagically done. Probably even by applying the "build normal combinators" logic to the current mods that do it in lua, the same way that the shortwave mod solves "radio" with normal, but invisible, circuit wire, rather than lua copying signals around.

[eradicator]

I'm talking about taking the formula and creating a network of standard combinators to compute it natively in the game. That way it runs way faster and only when a signal changes.

Turning an arbitrarily long and arbitrarily complex formula into a working combinator network is a huge load of complicated theorycrafting and optimizations. Though no doubt worth it, it sure would help if there was some groundwork done for whoever-implements-this to look at. If you want it to ever happen you should make a thread about just that part.

A non-programmable pocket calculator (because that's the level of complexity I'm talking about) has none of that. The only operations you have are those the arithmetic combinator provides and (). No loops, no branches, no memory cells.

Ah. I see. Then yes, it isn't as hard as I thought. If I had understood your statement as you intended, I'd have agreed that it was fairly easy to have that automagically done. Probably even by applying the "build normal combinators" logic to the current mods that do it in lua, the same way that the shortwave mod solves "radio" with normal, but invisible, circuit wire, rather than lua copying signals around.

Great, if it's so easy i'm sure it won't take long until someone makes it.