Factorio Forums

New player here. I'm finding circuit networks to be really fun, but the single letter variables are driving my nuts!

Two things, instead of A or C lets use a short variable names. "ironForBullets" or "spaceInCopperStation". And.. If the value of a variable is zero, still show it. Loosing any sign of a variable just because its zero makes debugging circuit networks really tough! (Clicking the power poles to see what's going on in the network was brilliant! I love that feature!)

-jim lee

jim lee wrote: ↑Wed Feb 20, 2019 9:14 am I'm finding circuit networks to be really fun, but the single letter variables are driving my nuts!

Two things, instead of A or C lets use a short variable names. "ironForBullets" or "spaceInCopperStation".

I agree that having just letters can be confusing. Therefore, I think it would be best if it were possible somehow write comments for your combinator setups, just like a computer programmer writes comments for the code he writes.

Comments for combinators has already been suggested and discussed in the following threads:

viewtopic.php?f=6&t=63023 Commenting combinators
viewtopic.php?f=6&t=56214 Comments on Deciders, possibly other entities
viewtopic.php?f=6&t=62279 Combinators information
viewtopic.php?f=6&t=58685 Signs

I disagree. The circuit network is low level for a reason. It is up to the player to design their own solutions.

If you want an alphanumeric signal readout for debugging you can always build one.

The circuit network leaves so much for the player to accomplish. IMHO it is the best feature of factorio and what sets it apart from any other game. You could probably make your own compiler and programming language with it.

The wires are like circuit paths on a motherboard, except you can actually already see more at a pole than you would in real life without digital circuitry at the pole.

jim lee wrote: ↑Wed Feb 20, 2019 9:14 am And.. If the value of a variable is zero, still show it. Loosing any sign of a variable just because its zero makes debugging circuit networks really tough!

The thing is...every value is zero, unless it's not. If you hover over a power pole, and it says there are 53 Electronic Circuits and nothing else, what that really means is that in addition to the 53 Electronic Circuits, there are also 0 Transport Belts, 0 Train Stations, 0 of Signal 0, 0 of Signal Blue, 0 Rocket Fuel, 0 Lubricant, 0 Crude Oil, etc.

How would the game know which signals to show, even if they are 0, and which signals not to show?

Yes, as it is now, it would spew everything out if zeros were shown. My idea is that nothing shows unless you name it. You have to name it for it to exist. Just like c++. In fact, I see the entire thing as a big visualization of c++ objects. It would be neat if in the base class there was a char* that could hold an object's name. Then anything could be named.

Signals, storage chests, favorite robots, my precious army tank..

Speaking of tanks, can we get a little better set of brakes for that thing? I've caused no end of destruction to my own base running into stuff when I couldn't stop in time.

-jim lee

QGamer wrote: ↑Wed Feb 20, 2019 8:29 pm

jim lee wrote: ↑Wed Feb 20, 2019 9:14 am And.. If the value of a variable is zero, still show it. Loosing any sign of a variable just because its zero makes debugging circuit networks really tough!

The thing is...every value is zero, unless it's not. If you hover over a power pole, and it says there are 53 Electronic Circuits and nothing else, what that really means is that in addition to the 53 Electronic Circuits, there are also 0 Transport Belts, 0 Train Stations, 0 of Signal 0, 0 of Signal Blue, 0 Rocket Fuel, 0 Lubricant, 0 Crude Oil, etc.

How would the game know which signals to show, even if they are 0, and which signals not to show?

As the game is right now, it can't.

But I'd like if a distinction between "signal is zero" and "signal is not present" were added.
Most entities would continue to work as now
- Outputting a signal results in that signal being present
- Reading a signal that isn't present is treated as zero
For arithmetic (mainly the arithmetic combinator, but also the implicit add when merging cables), the result is present if at least one signal operand is present, except that division by zero should result in "not present".
For decisions there would be are two new tests: checking for the presence and absence of a signal. Output is present when condition is true.
All/Each/Any act on all present signals; as result "any == 0" is no longer a pointless test

The implementation could be a bitset, which should be both compact and efficient to update, as most operations will either output specific signals (machines, combinators not using "each"), forward the input set (arithmetic, decider with output "everything"), or or'ing multiple sets together (implicit add). Deciders using "each" would have to set each bit individually based on the condition, but compared to evaluating said condition setting the presence bit should be minor work.

Here's possible a better way of looking at it.

Leave all the signals as they are, except remove the lettered/numbered ones. Now, add in custom signals. You give your signal a name and it goes on the list as a custom signal. When hovering over a power pole you get the list of "primary" signals you see now along with a scrolling list of derived custom signals.

What do you think?

-jim lee

jim lee wrote: ↑Mon Feb 25, 2019 6:59 am Here's possible a better way of looking at it.

Leave all the signals as they are, except remove the lettered/numbered ones. Now, add in custom signals. You give your signal a name and it goes on the list as a custom signal. When hovering over a power pole you get the list of "primary" signals you see now along with a scrolling list of derived custom signals.

What do you think?

-jim lee

And throw away optimization? Oh no!

jim lee wrote: ↑Wed Feb 20, 2019 9:14 am the single letter variables are driving my nuts!

Two things, instead of A or C lets use a short variable names. "ironForBullets" or "spaceInCopperStation". And.. If the value of a variable is zero, still show it. Loosing any sign of a variable just because its zero makes debugging circuit networks really tough!

I don't know that we need to go this far. Maybe we could allow variable names, but they have to be all uppercase and start in column eight

And throw away optimization? Oh no!

I don't understand, what do you mean bt "throw away optimization"?

I don't know that we need to go this far. Maybe we could allow variable names, but they have to be all uppercase and start in column eight

What? Like in assembly? Now I'm really confused.

-jim lee

Nidan wrote: ↑Thu Feb 21, 2019 1:08 am But I'd like if a distinction between "signal is zero" and "signal is not present" were added.
Most entities would continue to work as now
- Outputting a signal results in that signal being present
- Reading a signal that isn't present is treated as zero
For arithmetic (mainly the arithmetic combinator, but also the implicit add when merging cables), the result is present if at least one signal operand is present, except that division by zero should result in "not present".
For decisions there would be are two new tests: checking for the presence and absence of a signal. Output is present when condition is true.
All/Each/Any act on all present signals; as result "any == 0" is no longer a pointless test

just an idea that flew through my head: you could use the value -1 to signalize that something is "zero" and use the value 0 as "not present"

Could that work for you?

jim lee wrote: ↑Tue Feb 26, 2019 3:49 am

And throw away optimization? Oh no!

I don't understand, what do you mean bt "throw away optimization"?
...
-jim lee

I mean fixed number of parallel signals probably highly optimized. If you add new custom signals number would not be fixed and optimization would go away.

Sad_Brother wrote: ↑Tue Feb 26, 2019 4:55 pm I mean fixed number of parallel signals probably highly optimized. If you add new custom signals number would not be fixed and optimization would go away.

I think the answer to that would just be to implement custom signals as a separate indexed hash table. Whenever you were not using a named custom signal, all the same optimisations would exist, and the number of named custom signals would probably be low - so named signals alone would be using a slower but more flexible system. If that's not acceptable performance-wise, you would still have the existing single-letter customs.

Still not convinced this is a great idea, but there's no major technical barrier that I can see. Mostly it's an interface question. How do you name your signal, and how do you tell something to use your named signal?

Ok, this is a real long shot but.. Instead of having text names (Like I'm used to) How about a little icon editor so we can make custom icons for our derived signals? Then the interface doesn't change, just an extended set of icons, and something we can paste a bitmap into.

-jim lee

rldml wrote: ↑Tue Feb 26, 2019 12:33 pm

Nidan wrote: ↑Thu Feb 21, 2019 1:08 am But I'd like if a distinction between "signal is zero" and "signal is not present" were added.
Most entities would continue to work as now
- Outputting a signal results in that signal being present
- Reading a signal that isn't present is treated as zero
For arithmetic (mainly the arithmetic combinator, but also the implicit add when merging cables), the result is present if at least one signal operand is present, except that division by zero should result in "not present".
For decisions there would be are two new tests: checking for the presence and absence of a signal. Output is present when condition is true.
All/Each/Any act on all present signals; as result "any == 0" is no longer a pointless test

just an idea that flew through my head: you could use the value -1 to signalize that something is "zero" and use the value 0 as "not present"

Could that work for you?

I didn't have a specific circuit design in mind when writing this, but rather some issues that pop up in the forums from time to time, e.g. "reading train content gives nothing but wagon still contains 0.x fluid" or "AAI can't handle coordinate 0, 0" (not actual thread titles). These can't be solved by the player alone but require game support.

For "normal" circuit contraptions your proposal may or may not work as having non-continuous arithmetic (i.e. 1 - 1 -> -1 instead of 0; 2 - 5 -> -4 instead of -3) makes any arithmetic that might cross / result in 0 complicated; changing the canary to a different value wont help either as you'll still have to catch and swap zeros everywhere. Carrying the presence information on a separate wire and updating it in parallel would double the circuit size but be quite a lot easier.

jim lee wrote: ↑Tue Feb 26, 2019 10:34 pm Ok, this is a real long shot but.. Instead of having text names (Like I'm used to) How about a little icon editor so we can make custom icons for our derived signals? Then the interface doesn't change, just an extended set of icons, and something we can paste a bitmap into.

-jim lee

Ok, how about this.

The more I thought about the idea of editing the letter/number icons the better I like it.

How about allowing people to paste custom bitmap on a letter/number circuit icon? If we could copy one of the existing icons, edit it and paste it over a letter/number icon, it would completely solve the problem of documenting what the letters mean. No longer need text names. Just get creative with a bitmap editing program and create your own custom icons.

All we would need is the ability to copy an existing icon and to copy/paste into a letter/number icon.

Thoughts?

-jim lee