Circuit network features for 0.15

[dragontamer5788]

Can we put combinators onto a train?

Like a "Smart Wagon", that maybe allows you to build combinators on the train itself? If I can put constant-combinators on a train (and if 0.14 allows train contents to be "read into" a train station through the circuit network), then it would allow some very fancy stuff to be done.

Continuous wire building while running, somehow

Ghost-building of wires between two points would be more than sufficient. An A* Pathfinding across electrical poles between two points is all that would be needed.

-----------

All I really want though, are for "Set Filters" (for Stack Filter Inserters and filter Inserters) to actually be sane with regards to operation. For example, if Filter Inserters took the five largest signals in the network as their filters (and if stack-filter inserters took the single-largest signal), then these would be much, much more useful with the circuit network. As it is right now, "Set Filters" mode is hard to work with. There's no real way to control priority of the filters on the signal... I could build a sorting network, but that requires a good chunk of work.

[Drury]

Can we put combinators onto a train?

Like a "Smart Wagon", that maybe allows you to build combinators on the train itself? If I can put constant-combinators on a train (and if 0.14 allows train contents to be "read into" a train station through the circuit network), then it would allow some very fancy stuff to be done.

Wouldn't it be better to have the ability to read train contents, then just load some fish into it instead? Less items cluttering the game, works the same.

[dragontamer5788]

Can we put combinators onto a train?

Like a "Smart Wagon", that maybe allows you to build combinators on the train itself? If I can put constant-combinators on a train (and if 0.14 allows train contents to be "read into" a train station through the circuit network), then it would allow some very fancy stuff to be done.

Wouldn't it be better to have the ability to read train contents, then just load some fish into it instead? Less items cluttering the game, works the same.

For that case, yes.

For more complicated cases (ie: Decider Combinators or Arithmetic Combinators actually on the train, that are moving with the train), no. Sometimes I change methodologies between bases and maybe a mobile circuit network would be the best way to solve that.

Just throwing an idea out while the topic is up. My real need is for "Set Filters" to have a priority system programmed in. A lot of the other ideas in this thread are also good of course.

[siggboy]

Combinators on a train are bit wacky, but I'd like to be able to "tag" trains with data. Basically like a memory combinator that I can write to before the train leaves.

Choumiko is planning to add something like it to SmartTrains, and it has the potential to take my train scheduler to the next level. Somebody has made an even more crazy train scheduler that is completely decentralized, but it requires 50+ combinators PER OUTPOST, which is nuts. However, if your trains can actually carry information with them, then such undertakings become more feasible.

I'm currently limited because if I wanted to send a "queue" of trains to the same outpost, I'd have to store data for each of them in memory, which is inflexible and bulky (for example my trains need to know what the next hop is, if I could tell the train itself then that would be awesome).

Of course dragontamer's idea is not without merit -- having an actually moveable circuit could be fun. I just don't think that more than a handful of players would ever use that. So it's not going to become a part of Vanilla by any stretch (I guess).

[Mustacheion]

I would love to see roboports able to display the total number of robots of each type currently existing within the roboport network. This number would not change as robots enter and leave the roboport to complete tasks, only when they are killed or removed from the roboport. This would be most useful for resupplying remote base roboport with construction robots that get destroyed from combat without risking flooding the roboport. For example, if you are trying to thrifty and only have a few, say 10, construction robots at a remote base to keep up with repairs from combat damage, and you want your resupply train to be able to resupply robots that have been lost. Suppose the supply train shows up while the robots are currently away doing work - the network already has enough robots and you do not want to add more, but they aren't in residence at the roboport right now, so you can't really account for their presence.

I would also love to see combinators that can perform computations on each input simultaneously but separately. Similarly, I would love it if constant combinators could output a vector of signals (specific values on different channels). For example, suppose you want to fill a chest from a train with specific counts of specific items. You run a green wire from the chest to a decider input, which carries information about the contents of the chest. You run a red wire from the same decider input to the output of a constant combinatory. The constant combinator is programmed to output the quantities of all the items you want to have in the chest - outputting several different signals at once. The decider is programmed to compare the values on the red and green wires on each channel. If the signal on the green wire is less than the signal on the red wire, the chest does not currently have enough of the desired item. If the signal on green is less than the signal on red, the decider outputs a 1 on that channel. The output from the decider is then connected to a filter inserter set to "set filters" mode. This way, the inserter only moves items until the contents of the chest are greater than specified in the constant combinator. Of course, such a setup is relatively easy to create within the current circuit system, but you have to treat each item individually, which is a bit of a hassle to set up. It would be so much more elegant if the combinator could perform its operation on each signal being delivered to it, so that you can use substantially fewer combinators in total.

[aubergine18]

UI alert on condition.... There's a mod for that: https://mods.factorio.com/mods/Nexela/CircuitAlerter

[fod]

I think it has been proposed already but there should be the possibility to compare the value of two different signals in the decider combinators and operate with different signals in the arithmetic combinators.

[piriform]

So many goodies. Want them all. But if it's a matter of choosing only five here's my pick.
1. Set/Disable assembler recipe- A really programmable factory. On the fly! Rainbow belt types can go nuts.
2. More options for the combinators (~=,>=,<= ,% etc) would be really helpful. Another nice feature would be enabling user specified output for a decider. Currently, decider can output the input value or 1. By allowing specification of the output constant (say -1) many interesting constructs would be easier and faster.
3. Train station specification ( I assume this means train dispatch as well) seems like a win.
4. Radar reporting enemy count would be great . Ideally one would want distance,direction and size of the force (ex 1 big biter= 5 small etc), however this may be difficult to implement. Alternatively some way of specify the scan radius would be really helpful.
5. Wiring clean up.= let's face it , it does get messy and hard to read at times.

[RepairMan]

"Items needed for construction"
Great now we only need some way to automatically place down blueprints and we can have a Von Neumann factory \o/
(ik that there is a mod but it has gotten a bit messy)

[siggboy]

Another nice feature would be enabling user specified output for a decider. Currently, decider can output the input value or 1. By allowing specification of the output constant (say -1) many interesting constructs would be easier and faster.

Oh, yes I've thought about that sooo many times. "IF X>42 then output Y=23" is just so much easier than having to output "1" then use another combinator to multiply by the desired constant.

[piriform]

. "IF X>42 then output Y=23" is just so much easier than having to output "1" then use another combinator to multiply by the desired constant.

+ free NOT

[hitzu]

I think there should be a debug mode for circuit network when the time is 1/60th of normal and we can actually see signals passing through wires and converting and modified in combinators. Now this part of the game is lacking of visual clarity and illustrative aspect. For example in comparison with belts, we clearly see what's happening on belts and splitters, so dealing with them is very easy for learning. But circuit network for many of players is still the dark magick due to its opacity - we don't see processes, we just input something and almost instantly get an output. For guys like Kovarex with logical brains it's not a problem, but for guys like me... I just need some visualization, without it my brains just melt

[siggboy]

I think there should be a debug mode for circuit network when the time is 1/60th of normal and we can actually see signals passing through wires and converting and modified in combinators

Yes, please.

In this context, the following mod is interesting: https://mods.factorio.com/mods/xmnovotny/CircuitLogger

It logs all the signals into a CSV file, for later debugging. This is pretty much the only thing we have to debug the really complicated stuff.

[hitzu]

I think there should be a debug mode for circuit network when the time is 1/60th of normal and we can actually see signals passing through wires and converting and modified in combinators

Yes, please.

In this context, the following mod is interesting: https://mods.factorio.com/mods/xmnovotny/CircuitLogger

It logs all the signals into a CSV file, for later debugging. This is pretty much the only thing we have to debug the really complicated stuff.

For me it makes things even harder, not simpler.

[aeros1]

I'll put my opinion what is required and what is just would be easier shorter way. And how I see it.

• SoundBox - usefull to give player signal if situation beyond repair or something important that can't be stopped, would add here map marker even small one
• Train station, read train contents - could be usefull but now I can just set condition for train to move when set cargo reached, or on condition from network so not critical, it is even possible to make so inserters unload box fully once it reached proper value by using logic memory switches. What is more important it would be helpfull to know if any train is at station
• Same with disabling station - you may already sorta disable by making correct setup with circuit network and checking stocks. Seems unnecessary simplification but if intent to simplify game for more casual
• Radar ideas - ideas are not that bad. Though don't see how it could be used, but same with circuit network someone might find it useful
• Assembly machine set recipe - Please no. The game is already beatable with pretty small factory now. With this I may even beat game using teoretically 1 assembler of each type(by refeading recently crafted ingredients(although circuit logic would be fun if we could only have short pole for more visibility in network)). I wouldn't be against opening it for modding, but if the reason to encourage large factories it is counter productive as lots of things especially not urgent now can be crafted by omnifab
• UI alert - Pretty usefull I would like to have a way to issue that my ore actually exhausted or other stuff it wouldn't even require adding such possibility for mining drill
• Other operators - Really we have already all analogue logic operators which can be used as such *OR* is "+", *AND* is "*" *NOT* is "=0" output 1. This is even enough to write memory cell which can read and write information. What would be severly more useful is actually have counter. Not like it is impossible to write with memory cell though in fact if you don't normalize memory cell you get counter. And other operators are not required XOR is !(A==B) XNOR is A==B. Bitwise combinators are closer to useful, an selector ones would be at least somewhat usefull and preform unique option
• Tougle mode and pulse mode for combinator - yes, also if you may give it counting capabilities would be nice, but pulse mode would be excelent for timers as there is no synchronizers except circular belt with piece of iron on it. And it looks a bit strange. Also would allow timers. Also Fiddled a bit with pulse belts either my logic was horrible or pulse signal sent continuosly until some part of item leaves scaner. So Belt not actually counts tems on it. Though I am not sure would be good if somone confirmed.

[MeduSalem]

• Same with disabling station - you may already sorta disable by making correct setup with circuit network and checking stocks. Seems unnecessary simplification but if intent to simplify game for more casual{/list]

You can't really disable a station. Trains will still go there (if the station is free that is or if there's just no other free one around) even if you don't want them to. Yeah, the trains may wait there forever if you set the right conditions for leaving, but some people don't want trains to unnecessarily go to such stations in the first place if all they are going to do there is wait. In the end you only need more trains than necessary because a lot of them will be just waiting somewhere instead of going to where they are really needed.

• Radar ideas - ideas are not that bad. Though don't see how it could be used, but same with circuit network someone might find it useful

To avoid having to lay 10 miles of circuit network wire to the outposts... because it is really annyoing.

• Assembly machine set recipe - Please no. The game is already beatable with pretty small factory now. With this I may even beat game using teoretically 1 assembler of each type(by refeading recently crafted ingredients(although circuit logic would be fun if we could only have short pole for more visibility in network)). I wouldn't be against opening it for modding, but if the reason to encourage large factories it is counter productive as lots of things especially not urgent now can be crafted by omnifab

Yeah you could beat the game with one assembler of each type but it would take forever due to the assemblers having to do everything sequentially. It would be comparable to handcrafting speed (okay maybe a bit faster especially with AM3, but not by much), so you would eventually have to have multiple such smart assembling setups or otherwise it would be tedious. So in my opinion you are pretty overexaggerating the negative effect it would have. On top of that you would have to implement a lot of circuit network stuff around the assembler anyways to make the recipe switch for that many recipes even possible. And that's a lot of work too.

But what's more important is that you wouldn't have to use it if you don't like it, just like a lot of stuff in the game isn't really necessary to win the game or just a matter of taste. I for example never use Solar Power because I think it's boring and lacks serious downsides that make the feature "challenging", but if most other people are fine with it who am I to continue arguing about it. I used to but recently I came to the conclusion there's no point in it and if I don't like something I just don't have to use it. I don't have to ruin the "fun" for everyone else, even if I don't really understand what's really that "fun" about Solar Power in my case.

• Other operators - Really we have already all analogue logic operators which can be used as such *OR* is "+", *AND* is "*" *NOT* is "=0" output 1. This is even enough to write memory cell which can read and write information. What would be severly more useful is actually have counter. Not like it is impossible to write with memory cell though in fact if you don't normalize memory cell you get counter. And other operators are not required XOR is !(A==B) XNOR is A==B. Bitwise combinators are closer to useful, an selector ones would be at least somewhat usefull and preform unique option

[/list]

For example if you want to compare if both any amount of Iron Ore AND Copper Ore exist (meaning both could be any number greater than 0) you are out of luck though. Then you have to use the cumbersome approach of first scaling both signals down to either being "0" (if it doesn't exist) or "1" (if amount of ore is greater 0) using deciders so that they can be compared and then with a third decider compare if both signals in sum are >1. And for OR you basically have to do the same, just that you'd check if both signals in sum > 0.

So it renders certain contraptions really an overcomplicated mess because you have to use 3 combinators where one with an appropriate "AND" comparison (or "OR" respectively) would completely suffice. On top of that you have to start using virtual signals since you can't compare the original values directly, which makes things more complicated for the average user. And for people not that much into programming that's an issue because the game is not about showing off your math or programming skills... a fact many of the circuit network gurus seem to forget steadily.

It's something I have been stressing ever since the major overhaul of the Circuit Network introduced back with 0.12... that Factorio's approach to the issue may be unique, but in certain aspects way too fundamental, as if it was designed for a bunch of assembler programmers instead of gamers. It's an accessibility problem and a reason why a lot of people avoid getting into Circuit Network stuff because it seems overly complicated for anything more than just turning on/off some pumps in your refinery (the only real application as many deem).

If dedicated AND/OR comparisons would treat a signal value as "true" as long as it's anything BUT zero it would help with some contraptions greatly and it would be something that most people, even the ones who are not that much into programming would understand without having to look it up somewhere.

[siggboy]

• Other operators - Really we have already all analogue logic operators which can be used as such *OR* is "+", *AND* is "*" *NOT* is "=0" output 1. This is even enough to write memory cell which can read and write information. What would be severly more useful is actually have counter. Not like it is impossible to write with memory cell though in fact if you don't normalize memory cell you get counter. And other operators are not required XOR is !(A==B) XNOR is A==B. Bitwise combinators are closer to useful, an selector ones would be at least somewhat usefull and preform unique option

[/list]

For example if you want to compare if both any amount of Iron Ore AND Copper Ore exist (meaning both could be any number greater than 0) you are out of luck though. Then you have to use the cumbersome approach of first scaling both signals down to either being "0" (if it doesn't exist) or "1" (if amount of ore is greater 0) using deciders so that they can be compared and then with a third decider compare if both signals in sum are >1. And for OR you basically have to do the same, just that you'd check if both signals in sum > 0.

No, I think aeroes has a point there. In your example you can multiply Iron and Copper and the result will be positive if and only if both are present (that's the equivalent of a logical "AND"). The logical "OR" is simply the sum of both (zero only if none are present).

Therefore I don't really understand what the "AND"/"OR" operations in a combinator would actually do.

XOR, however, can NOT be simply expressed as "!(A==B)" (which is "A != B"), because we're not dealing with binary values only. So that's one case where you have to normalize to "1" before you can do the operation.

So it renders certain contraptions really an overcomplicated mess because you have to use 3 combinators where one with an appropriate "AND" comparison (or "OR" respectively) would completely suffice.

Maybe it's a little more difficult to understand how you do these logical operations, but it certainly does not create a mess.

Again, AND/OR would just be aliases for "+" and "*", and XOR would be the ugly stepchild of "!=" because it would normalize the inputs to "1"/"0" under the hood.

The problem for most players is that those are operations in the ARITHMETIC combinator, when you'd actually expect a DECIDER combinator to handle that. ("AND"/"OR" are much closer to decisions, even though a programmer will recognize that it's actually boolean arithmetic.)

Furthermore, there are lots of places where you cannot use arithmetic, to wit in all those places where you can specify a "circuit condition" (inserters, train stations, power switch, ...). I guess those are the places where the AND/OR stuff is actually missing; right now you have to do the arithmetic outside, then output a virtual signal and do the comparison on that signal.

BTW "!=" (not equals) is totally missing from the comparison operations. (That makes XOR difficult even after you've normalized to "1"/"0", because you still can't perform the "not equals" operation straight away, you can only output a "false" virtual signal and have to interpret that as the inverse of "true". But not having "!=" as an operation is awkward in many other situations as well.)

What is making a mess quite often is that you cannot specify a constant value directly as an output. You have to go through outputting "1" and then multiplying by the desired constant (as pointed out earlier in this thread already). That's one of the things that could easily be added, without confusing anybody and the UI for that would be obvious as well.

Bitwise operations are totally missing, many can not be emulated easily. However, if those were to be added, we'd also require a "decoder combinator", that would output the individual bits of the input. Just having bitwise stuff without that is somewhat pointless in my eyes (a decoder can be made with integer arithmetic shenanigans, but that's probably over the head of most people, even those who know what bitwise operations actually are).

Now we're in the area of having to deal with groups of signals already (decoded bits are distinct signals). That's something which became more apparent in 0.13 due to the filter inserters. If you have a bunch of signals it's just very awkward if you need to pick one (and you do not know which one you're picking). So we need the "anything" output in the decider.

On top of that you have to start using virtual signals since you can't compare the original values directly, which makes things more complicated for the average user.

Well, no, that's only necessary if you want to perform an "XOR". Also, if you're doing a "logical" operation, the output will always be abstract, so you'd output a virtual signal anyway. Again, it boils down to these things being arithmetic operations in Factorio, not something the decider combinator does.

It's an accessibility problem and a reason why a lot of people avoid getting into Circuit Network stuff because it seems overly complicated for anything more than just turning on/off some pumps in your refinery (the only real application as many deem).

There are too many quirks right now, because two worlds collide (doing the "really simple stuff" vs. "going hardcore"), and there are not enough tools to systematically build complex circuits.

In my opinion the two worlds should be more cleanly separated. Make some REALLY simple combinators for the easy stuff, and then give us a blackbox combinator where you can build proper circuits in an environment that's suitable. In that environment you could shed all of the arcana and quirks that stem from the fact that the combinators need to offer straighforward solutions to trivial cases.

If dedicated AND/OR comparisons would treat a signal value as "true" as long as it's anything BUT zero it would help with some contraptions greatly

Dedicated "AND/OR" would only help in those cases where you do not already use combinators (i.e. for conditions set directly in entities). Because if you do use combinators, then those operations are easy (as explored above).

Wow, this has become a lot longer than planned.

[siggboy]

Tougle mode and pulse mode for combinator - yes, also if you may give it counting capabilities would be nice, but pulse mode would be excelent for timers as there is no synchronizers except circular belt with piece of iron on it.

What is "toggle mode"?

What would "pulse mode" do?

The timer is very easy to build, and you can precisely specify the tick distance between pulses. Doing this with a circular belt is really just the low-tech way, generating a regular pulse is not that hard.

Of course there could be a really nice "clock combinator" that could do things like generate some waveforms (e.g. sawtooth, rectangular) and you could specify the period and amplitude directly, and it could also be able to hold and delay signals for a specific time; if done correctly you could even use that as a memory cell, for example if an infinite "hold" time is possible. If all of that would be packed into a nice combinator I guess it would be worth adding.

But certainly not just to generate pulses and a clock, that's really easy to do with what we have already.

[BlakeMW]

There's a big limitation of * = AND, + = OR

Taking how "or" works in most programming languages, if you say:

a or b

Then if a is truthy you get the value of a, if b is truthy you get the value of b

The distinction between A * B and A AND B, would be that when you use A AND B you can get the unmodified value of A or B for the output, when using * you get the multiplied value out and you have to renormalize the value to get the original value, for example you'd have to take the value of A*B then divide it by B to get A, or have previously normalized B to 0/1.

So AND/OR can actually work in subtly different ways than arithmetic operations. I would actually favor having AND/OR as decider combinator options and working like in scripting languages (i.e. more pragmatic than strictly boolean)

[MeduSalem]

@siggboy: I was about going to answer detailed to the AND/OR/NOT problem, but basically BlakeMW did it for me in a much shorter, easier way:

There's a big limitation of * = AND, + = OR

Taking how "or" works in most programming languages, if you say:

a or b

Then if a is truthy you get the value of a, if b is truthy you get the value of b

The distinction between A * B and A AND B, would be that when you use A AND B you can get the unmodified value of A or B for the output, when using * you get the multiplied value out and you have to renormalize the value to get the original value, for example you'd have to take the value of A*B then divide it by B to get A, or have previously normalized B to 0/1.

So AND/OR can actually work in subtly different ways than arithmetic operations. I would actually favor having AND/OR as decider combinator options and working like in scripting languages (i.e. more pragmatic than strictly boolean)

It's an accessibility problem and a reason why a lot of people avoid getting into Circuit Network stuff because it seems overly complicated for anything more than just turning on/off some pumps in your refinery (the only real application as many deem).

There are too many quirks right now, because two worlds collide (doing the "really simple stuff" vs. "going hardcore"), and there are not enough tools to systematically build complex circuits.

In my opinion the two worlds should be more cleanly separated. Make some REALLY simple combinators for the easy stuff, and then give us a blackbox combinator where you can build proper circuits in an environment that's suitable. In that environment you could shed all of the arcana and quirks that stem from the fact that the combinators need to offer straighforward solutions to trivial cases.

Also I agree that there are worlds colliding currently and that probably there should be a blackbox environment for complex stuff for those who really need it, altough it somehow would be a little bit against the "what you see is what you get"-feeling of factorio where each item that is doing something is somehow physically present on the map and where the transformation from input to output is transparent to the user.

It might be just me, but then again the devs are currently suffering a little dilemma throughout new feature development anyways... remember when they used to say "we don't want to convolute/clutter the crafting menu with unnecessary items that only serve one special purpose"... but that's basically what they have been doing (or had to do) for quite a while now, especially with the Combinator stuff and recently with the increased amount of special inserters as well as some other things... and yet all of these features are still quirky and fiddly or lack much needed functionality.