netlist language for combinators.

[y.petremann]

I think that to have a netlist language for combinators could be a good idea so if you would like to contribute :

This a simple example of what I'm thinking for having a blinking device :

Code: Select all

DEF Blinker
  NODE main RED                   # a network is a group of cables connected to each other
                                  # not defining it would make a simgle use cable
                                  # a device could get or send from two network if their color are not the same

  # INPUT Example                 # Inputs could be written from external circuit.
  OUTPUT output                   # Outputs could be read from external circuit.
  # DUAL Data                     # Dual could be read and written from external circuit.
  CONSTANT main:lenght_total=60   # Constants could be redefined from call but could not be read from external circuit
           main:lenght_on=30
  STATIC CONSTANT main:counter=1  # Static constant could not be redefined from call

  DECIDER main:counter = [main:counter < main:lenght_total]
  DECIDER main:output ? [main:counter < main:lenght_on]
END

DEF Special_blinker
  REM Blink two times then one times 
  Blinker output,90,30
  Blinker output,20,10
  LAMP [output > 1]
END

I'm sure that we can create a neat language to define a circuit, and I also think that we could add structural information so people would program a circuit for a specific use and later use a program to create blueprints

[ratchetfreak]

for definition per combinator you can use the circuit ID debug overlay and enumerate each combinator:

Code: Select all

Arithmetic, input green 4 input red 5, each * signal 0, output green 7 output red 10 signal each

[y.petremann]

for definition per combinator you can use the circuit ID debug overlay and enumerate each combinator:

Code: Select all

Arithmetic, input green 4 input red 5, each * signal 0, output green 7 output red 10 signal each

This is a good idea, these id could be used if you aim to "reproduce" an existing circuit, but the language would also support name.

[Gus_Smedstad]

While I understand what you're trying to do, and I gatherer there's established precedent, I found that almost unreadable. My own experience is with procedural languages, so I don't know what the common choices are for describing circuits via text, but a quick search of Wikipedia suggests that something like Verilog would be a lot easier to read.

Keep in mind that you need to address the symbols somehow. Combinators don't just have "pins," they have symbols associated with those pins. A >= Combinator with "Green Science Pack 0 or 1" as an output is different from one with "Copper Plate 0 or 1" as an output.

Honestly, Verilog looks pretty primitive to me as well, like the first version version of C where function inputs inexplicably had their types declared after the function declaration instead of inline, as has been standard now for 30+ years.

Given my own devices I'd probably pattern a language after C or Pascal, with the symbols standing in for types (which are all integers). The main danger is that Combinators aren't really procedural, they're circuits.

[y.petremann]

While I understand what you're trying to do, and I gatherer there's established precedent, I found that almost unreadable. My own experience is with procedural languages, so I don't know what the common choices are for describing circuits via text, but a quick search of Wikipedia suggests that something like Verilog would be a lot easier to read.

Keep in mind that you need to address the symbols somehow. Combinators don't just have "pins," they have symbols associated with those pins. A >= Combinator with "Green Science Pack 0 or 1" as an output is different from one with "Copper Plate 0 or 1" as an output.

Honestly, Verilog looks pretty primitive to me as well, like the first version version of C where function inputs inexplicably had their types declared after the function declaration instead of inline, as has been standard now for 30+ years.

Given my own devices I'd probably pattern a language after C or Pascal, with the symbols standing in for types (which are all integers). The main danger is that Combinators aren't really procedural, they're circuits.

Firstly this is a first draft but I've already think about a better "language" today, two aims are to describe functions as structure, to have the "compiler" to validate the viability of the circuit and finally to export a valid blueprint string.
This need for this to be aware of the structure of the system and to diferentiate between integer and boolean.

I don't say I have the better language but having one would be really cool.

For me it would be important because it would permit to think about a huge circuit without having to verify the configuration of each objects.

[y.petremann]

Here a new syntax I've think about :

Code: Select all

define Blinker {
  // Example = INPUT MULTIPLE BINARY;
  output = OUTPUT BINARY;
  // Data = DUAL MULTIPLE BINARY;
  lenght_total=60;
  lenght_on=30;
  main:counter = main:counter < lenght_total;
  main:output ? main:counter < lenght_on;
}

define Special_blinker {
  // Blink two times then one times
  output = Blinker(lenght_total=90, lenght_on=30);
  output = Blinker(lenght_total=20, lenght_on=10);
  LAMP([output > 1]);
}

define main {
  Special_blinker()
}

[Adil]

Unlike Gus_Smedstad I don't understand what are you trying to do.

[y.petremann]

Unlike Gus_Smedstad I don't understand what are you trying to do.

The idea is to have a language that would permit to describe circuit network, so instead of placing manually things and thinking of each things as a part of a whole big things, you would define small parts to use them in bigger parts and again, so it would be easier to define things like processors, memory and things like in the "Factorio leds banner".

[Adil]

The idea is to have a language that would permit to describe circuit network,

Like for description of player creations? Aren't languages already in existence sufficient?

so instead of placing manually things and thinking of each things as a part of a whole big things, you would define small parts to use them in bigger parts and again, so it would be easier to define things like processors, memory and things like in the "Factorio leds banner".

As in blueprints, right?

[y.petremann]

The idea is to have a language that would permit to describe circuit network,

Like for description of player creations? Aren't languages already in existence sufficient?

so instead of placing manually things and thinking of each things as a part of a whole big things, you would define small parts to use them in bigger parts and again, so it would be easier to define things like processors, memory and things like in the "Factorio leds banner".

As in blueprints, right?

More of a language to describe thing to be exported to blueprint.
Imagine you found the combinator configuration for an NAND gate, and then one for an RS latch made out of NAND gates, then ... then a whole processor made of all complicated stuff you have, you basically have a "blurprint" for that processor, but now imagine you found that a specific part repeated all hover you circuit is taking too much time or using too much combinators, you coul freely redesing this part and your complere processor would benefit from it.

[Gus_Smedstad]

Like for description of player creations? Aren't languages already in existence sufficient?

Possibly not.

The problem is that combinators aren't a procedural language, since combinators are evaluating everything every tick in parallel. Nor are they a rule language like Prolog. They're circuits, with timing issues and energy levels. They're closer to Prolog than to C, but timing issues can turn around and bite you - as I discovered the hard way.

There are engineering languages for describing circuits, but they're not very good. At least, that's my initial take on what I've seen. I mentioned Verilog up thread, and as I said, it looks about 40 years behind procedural languages I know, just in syntax.

A language is probably a better way to design circuits than messing around with them in game. My experience with trying to design "seat of the pants" is that it's often not clear what's going on, since you can't single-step through execution to see why something isn't working, and the user experience is a bit hostile. You can't delete combinator connections, the only way to undo a wiring error is to delete an item and re-place it, and you lose the logic wires every time you do that.

Blueprints are good for getting a design without dropping the items yourself, but it doesn't tell you why a circuit works the way it does. If you want to adapt or improve another person's combinator circuit, you really need something more descriptive.

If I were going to put the effort in - which I probably won't - my main focus would be on creating a language that was highly readable. For example, I'd expect the item block header to define inputs and outputs, which he's avoiding doing so far. For example:

Code: Select all

define Latch : connections( start : A, stop : B, result : A)
// this simple block takes two input signals, of types A and B. It outputs A as 1 until it receives B as 1.
{
  decider combinator_1( greater_than( A, B ), A as 1 ); // how you set the decider's dialog. Output is always "as 1" or "input count."
  
  connection( start , combinator_1 input )
  connection ( stop , combinator_1 input )
  connection( combinator_1 input, combinator_1 output ) // wire looping output to input, so A stays set.
  connection( result, combinator_1 output )
}

// example usage:
  circuit latch_1 Latch( combinator_2 output, combinator_3 output, combinator_4 input );

That's a trivial circuit with a single combinator. The main thing a circuit definition does is define what combinators or more complex circuits it contains, how they're connected, and how the input and output wires connect to those circuits.

The main problem I'm having with his examples is that I can't imagine how they translate into actual circuits. You can't define constants and parameters like "30" and "60" the way he's doing, and I don't know what symbols he's using. As we know, Combinators in Factorio all require associated symbols for each variable, such as "iron ore" or "oil barrel," but there are also a bunch of abstract symbols just for combinators, letters (A and B in my example), colors (Red, Green, Yellow) and numbers as variables (0-9).

[ratchetfreak]

You can't delete combinator connections, the only way to undo a wiring error is to delete an item and re-place it, and you lose the logic wires every time you do that.

You can by putting the wire down again which will delete it (though you don't get the wire back)

[Adil]

More of a language to describe thing to be exported to blueprint.

You want to have blueprint generated by game based on your code?

Imagine you found the combinator configuration for an NAND gate, and then one for an RS latch made out of NAND gates, then ... then a whole processor made of all complicated stuff you have, you basically have a "blurprint" for that processor, but now imagine you found that a specific part repeated all hover you circuit is taking too much time or using too much combinators, you coul freely redesing this part and your complere processor would benefit from it.

I wonder, how many people would actually go and do something like that.

[Gus_Smedstad]

I wonder, how many people would actually go and do something like that.

Not many, but I think there's a lot of room for discussing useful circuits that are not full-blown computers. Because combinators are so primitive, a lot of basic tools require 2-3 combinators. A lot of if-then constructs require a decider hooked to an adder or multiplier to get the result you actually want.

I think the root issue is that while screenshots completely describe most Factorio setups, they don't capture the vital internal settings of Combinators, and the wiring is much, much harder to see than transport belts and inserters. Individual components also often require comments to explain their function, so a wiring diagram isn't enough.

I agree that I don't see much point in a language that can be compiled to create blueprint code. If you're going to do that, just paste the blueprint code.

[Zeblote]

and the wiring is much, much harder to see than transport belts and inserters.

I think this is a big problem with the circuit network. Red and green wires are too hard to see above the terrain/machines, it would be better to have blue and black wires or something like that. More contrast.

[y.petremann]

I agree that I don't see much point in a language that can be compiled to create blueprint code. If you're going to do that, just paste the blueprint code.

One point is that a lot of peoples I've seen want to make a way to display numbers, there is some ways I found by myself :

• logarithmic display : really easy to setup, only use lamps configured at these values : 1,2,3,6,10,20,30,60,100,200,300,600,1000,2000,3000,6000 ...
• linear decimal display : quite more dificult to make but easier to read, you need to have a repeatable circuit that would divide by 10 for the next decimal each time and calculate the modulo so a line would represent a decimal number by it's number of lights on.
• 7-segment display : the hardest one but the most easy to read, you basicaly need the linear decimal display circuit and 7-segment displays.

With a netlist language it would be for example easy to setup and optimize these things.

[ratchetfreak]

the netlist would allow discussing and compiling into sections. So when building the circuit you can use the sub assemblies to create a larger whole.

For a modulo operation requires a divide multiply and subtract. The netlist would allow describing that into a single component and let you repeat that throughout the larger build.

When buiding it you would put that into a blueprint and then stamp it down where you need it and only adjust the input and output combinators as needed.

[y.petremann]

the netlist would allow discussing and compiling into sections. So when building the circuit you can use the sub assemblies to create a larger whole.

For a modulo operation requires a divide multiply and subtract. The netlist would allow describing that into a single component and let you repeat that throughout the larger build.

When buiding it you would put that into a blueprint and then stamp it down where you need it and only adjust the input and output combinators as needed.

That a great explanation, thanks.

[ratchetfreak]

on reddit u/KHaim submitted this very nice diagram of his memory array design:



This is a very clean way of representing designs IMO

[y.petremann]

on reddit u/KHaim submitted this very nice diagram of his memory array design:



This is a very clean way of representing designs IMO

Yeah, I've seen this and I've think of three things :

• A netlist language would still be interesting.
• This type of diagrams are really good to explaining the logic of a system, but not on building blueprints.
• Diagrams like that do not solve completely dependency.

I often use draw.io and I think that having a program to convert from and to diagrams, blueprints and netlist file.

So it would permit to have 3 things, a descriptive netlist file, a comprehensive diagram and a usable blueprint.

For blueprints and netlist, I don't think this should be a problem since blueprints string are in short compressed json string, uncompressing them and making them more readable could permit to have a base of a netlist language, we simply need to have a way to represent and read from a diagram and also a way to define sub-blueprints (which could be really interesting for huge factories).

If you want to uncompress a blueprint to see the json code on linux based system:

Code: Select all

cat "blueprint-file" | base64 -d | gzip -d > "uncompressed-blueprint-file"