Friday Facts #123 - Better circuit network (Part 2)

[ratchetfreak]

I think people are overestimating how many things actually need to be connected to the network.

When you have several tanks you are reading you could just connect one and then multiply the value. They balance out anyway.

Same with accumulators, unless they are in different networks but then you have space to put the reader down anyway.

If you are controlling several smart inserters then you can probably control the belt feeding it.

Having more range than just 1 to allow connections is necessary. (at least 4 seems to be the minimum to connect all the chests and inserters on a train unloading setup).

A good (non-tedious) way to connect and disconnect the wires is also needed.

I know I'm a broken record on this but what about moddability? Modders need to be able to read what the writer puts on the modded entity. Same with being able to specify what the reader will read.

[ssilk]

I see nearly all of this issues will be fixed with this change: The display problem can be solved (half ways), there is no need for wires anymore (nearly?), because there are now own "poles" for circuits only. And so on, I see only advantages, when I look on it like so.

Wait what? Power poles (or something) that automatically connect everything in range to the circuit network? Cool. I think it's the first I've heard about it.

That is just my invention. Based on logical conclusion of how I would implement it. Sorry, for not making that clear.

[Marconos]

Hi all,

After reading your comments, posts and feedback, both here and on the subreddit, it is clear that not everyone is happy with some of the proposed changes.
While some people say "but the game is alpha its going to change", i do somewhat agree with some of the arguments against the changes.
By reading it seems most of the issue is with smart inserters and smart chests, and that the changes may break current factories when upgrading,
it might break loading/unloading stations, might be more difficult and awkward to setup compact smart systems, and many other great points.

I will talk with Twinsen this week, and hopefully strike a balance that will be more digestible for old and new players, so rest assured your feedback has not fallen on deaf ears

Whether or not you go with any of these suggestions or stick fully to your own plan is up to you. The best part, you are listening to the community and lovers of your games and taking their feedback into account. THIS is one of the best things about this game. Keep it up developers, I'm sure you'll get it the way you want.

My suggestion: Add "module" slots to more things allowing them to get a circuit module added to them if they need to be connected to the network. Takes care of the performance issues of having to check everything and the wonky display issue of having a weird 1x1 block all over the place. Another side benefit is we get more stuff to make and potentially research in the game.

[Fatmice]

A) Instead of having only one device, that is able to connect to one entity we need two more:
1. A device, that is able to connect to multiple devices in range. I think to something like the substation: All devices of the same type are connected.
2. You can insert in some (most?) devices a "module" instead. See former post https://forums.factorio.com/forum/viewtop ... 50#p124907
I'm very unsure, if that will help, but it should be at minimum prototyped to see, how that plays.

B) Add a "global network". That is just like logistic network, but everywhere on the map available (or at very large scale). Other networks (Railway network? Satelite network?) might follow.

And the rest will find. There is no need to make too much changes.

Your #1 is exactly my proposition. We have three entities that already operate on an area, namely roboport, beacon, and substation. We need to start moving away from wiring as the primary means of directing logical flow/messaging. The wiring is nice at first, but ends up being a mess very quickly even with small amounts of complexity, which leads to the case of whatever logical processing that you setup becoming inscrutable, even to you, after a short time. Having said that, I would not advocate to change anything about the combinators that have been implemented. I think shrinking their footprint is also a bad idea since all you're doing is making the wires even more crowded together. Leave them alone, warts and all.

Now onto the new entities. I really like that we're moving more towards directly manipulating the inner workings of a factory via logical processings. In fact, I was going to mod the effector and sensor entities in myself this weekend until I read this FF, so much for that . However, given that you have direct access to the code, there is no reason to make two entities, one a sensor and one an effector, when one entity can be given both functionalities. The advantage of one entity with dual functions is clear, namely less entity proliferation and less wiring and of course less sprites. Given that it will be possible to modify assembler recipies "on the wire", so to speak, fine-grained control of assembler-types is going to be the worst offender of entity proliferation. Believe me, many experienced players have been hankering for fine-grain control of their factories and we are the worst offenders when it comes to entity proliferations...less is more in this case.

So how might this new entity behave so that we can have new toys to play without crippling our base with them? It should operate on an area basis and can transmit energy, a modified substation of sort. A 1x1 entity that operates on a 5x5 or even 10x10 area would not be unreasonable. For balance purposes, make the energy consumption scale with the number of entities that fall under the operational area. Call this new entity an operator and let us assume that it operates on a 5x5 area for now. It has the ability to expose different sets of entities given the input signal, which is programmable in its gui. It manipulates entities via instructions from decider combinator, which will need new functions, under its area of operation. It outputs entity state of operation (active/inactive/on/off), recipe, sensory (temperature/charge/amount). All of this will not be available on its side gui as that would quickly clutters the thing, but rather that information will be available to the decider combinator, where its gui will need a face lift. The only thing seen on the side gui of the operator are the entity type (quantity), and recipe (quatity). The decider combinator needs to be able to operate on entities and signals. The types of manipulations here are diverse, but can be limited to these two.

• Given signal A and {range of entity [1...n] or [1,4,7] or for type a}, do action on {range of entity [1...n] or [1,4,7] or for type a}, where action is (toggle/recipe change)
• Given {range of entity [1...n] or [1,4,7] or for type a}, output signal B

The addressing of entities under the operator is simply an ascending list of interger [1...n] where 1 is the entity of the upper left most corner while n is the entity of the bottom right most corner of the area of operation. Operators can overlap and in that case the entities in the overlapping area should be registered to the operator that was earlier in the list of operators. Operators can be connected, or unionized, by wires, in which case all the entities under the total area of operation can be accessed from any operator.

This is a nice segue to the connectivity of roboport. I think it is ripe for some change. We need to be given the ability to manually specify the network connectivity of roboports and not just be limited to connectivity by area overlap. This change will allow us to design the topology of our logistic network. We also need the ability to designate which logistic nodes (being logistic chests, requester chests, and the player) are part of such network, while strictly observing roboport's area of service of course. And finally, we need to be given the ability to designate weights to the roboport and occupancy limits within the logistic network so that robots can be directed to flow and rest where we deemed most efficient. This is good for you since ai behavior of robots will be rudimentary. Leave it to us players to optimize the robot's behavior with manual logistic network manipulation. This is far more satisfactory anyhow.

[ssilk]

... effector and sensor entities

Effector is also a very nice name for that.

[bobingabout]

With this sort of change, there is no need for the "smart inserter" at all, so will that be eliminated from the game entirely?

The smart inserter can still filter things, so it stays for now.

It is also attached to any robot logistics network it is within too, which is 95% of what I use them for. The other 5% split between wire networks, and item filtering.

[Twinsen]

Just a quick update, that I've been following this thread since it was posted and read all the feedback.
We are in the process of rethinking the idea of the circuit connector, so your feedback has been helpful

[Masterpintsman]

A rapidly expanding thought after reading the blog post and through this thread:

Instead of some extra object placed next to the object you want to control, it IMHO would be better that you could fit a controller into the object which allow to extend the behaviour and interface of an specific object.

A controller would have slots (amount of them according to level of the controller) for uplink, control and logic modules. And for controllers with more than a single slot (or two) some way to create internal wiring (similar to the one we can do now on macro scale between chests, inserters and the logic objects) so we can direct the flow of data inside the controller.

Having that it would be possible to insert:

• a range of uplink modules tying into different data networks (wired giving an external pole to connect to, wireless to attach to global logistic storage, bluetooth for local range, ...) to obtain or send data
• a range of control modules selecting what to work on, examples would be: filter modules to make smart inserters, belt sensors or smart chests, ways to alter pickup/placement points for inserters, receipt selection for factories, railroad track selection or signal setters, readout probes, ...
• a range of logic modules (or a configureable one) to do some bool stuff inside the bigger controllers

The user interface should be somewhat along the current interface for smart inserters/chest, but modular (portions like type selections, amount selectors, filter lists) depending on modules inserted, and as a result of the generic approach should work identical for all smart objects.

Without an uplink module only the control ones will be active (example would be to create an unconnected smart inserter), in case no control module is in then it would simply be on/off through the connection module, through logic modules we could do basic 'if we dont have enough of this, but enough of that then...' inside the object.

This would also directly implement the Logistic Network Connector which would be a control enclosure, internally containing a bigger controller which could manage a cluster of assemblers and inserters through a local LAN while being hooked up to some WAN to get the data for decision making, or act as a bridge between networks, ...
Simplest way with the proposed system in place and no additional world graphics needed:
A lamp made smart with a (more or less big) controller

And in case the controllers can get big enough it would give the option to put the logic we currently build in a discreet manner on flat ground into something similar to a rack located near the area of its influence (like every sane engineer building a factory would do) and would solve a good part of the problematics with wires and poles and visibility.

This proposal would also nicely spread along the research tree to not overwhelm a new player (since options would come over time and build upon another) and be consistent since it would be a generic mechanic for all 'smart-able' objects, with the option to do complex logic.

Given such a mechanic the game could built on that in a generic way:

Build a lamp, have light. Upgrade it with a small controller and you can add remote features, turn it into a bridge to another network with multiple interface modules, or even something to manage a cluster of assemblers with a big enough controller in it.
Build a splitter, have standard functionality. Make it smart to be able to add on/off or filter control modules, ...
Build an assembler, have standard functionality (in the tiers as-is, regarding speed and number of source materials). Upgrade to a smart one to change recipt, turn it on/off or read some data (or whatever), or attach a bit enough controller to control the inserters around.

Controllers could come in different levels (with more slots and internal wiring for big ones, which build chain upon each other similar to Electronic Circuits), which would also open up for a progression on the controlled objects itself (basic object being dumb, upgradeable to smarter versions with increasing size of controller), which could be done through a factory receipt of 'install controller' which would take a controller and a smartable object (similar like furnaces take several materials, so we don't need to inflate receipts needlessly) and output a smart version (basic object with controller).
The opposit ('remove controller') should also exist so both objects and controllers can be upgraded (detach controller from object, upgrade one or both, reattach).

Regarding inserters:

I think they currently lack in several aspects: They are basically multi-axis robot arms, so why can't they deliver over 90° or pickup from multiple sources? With a system along the proposed one we could build a standard inserter frame which comes in small and big (= yellow and red) in the first step, attach a motor - burner, electric motor or two for speed, or even a windup one for the very early start - (to be back at the current speed classes of burner, yellow and blue), then smart them with various levels of controllers to be able to add filters and remote control, or even add a module that let it pick up from two lanes, or drop into multiply assemblers, or configure different places to pick/drop stuff in a different configuration than from behind to far side of belt infront.

Regarding the idea to turn transport belts on and off and read their contents:

A sensor tile (1x1 size, available in the usual speeds, created with a belt, some additional materials and a controller) that can sample the belt and read fill rate (amount of items on belt), relative speed of the objects on the belt (to be able to detect congestion) - both maybe averaged over a second or two - would nicely do the trick and enable interesting ways to react to changing loads - plus can be turned on and off through an uplink. Built with a bigger controller it could possibly, maybe when equipped with multiple filter modules, also report on different kinds of items on the belt in parallel.

I also would like that one could control splitters through the proposed concept, so upgrade a splitter to a 'smart' one and be able to attach control modules (corresponding to left and right side) to switch them on or off or filter stuff that comes along by some criteria.

Might sound a bit convoluted at first, but it is intended to generalize the way 'smart' stuff across the board (both from a logic, as from an UI standpoint), no exceptions - so please give it a thought before tossing it out. In case of interest I can flesh out the idea a bit more in detail, like how the modules could work and how they would play together.


[edit]Took a while to write, so the dev was here before me [/edit]

[Vim Razz]

The addition of the CNC and LNC blocks sounds pretty cool, but you can add me to the "removing Smart Chests entirely sounds like a terrible idea" camp.

Maintaining at least one chest type and one inserter type that have integrated CNC functionality without the need for another block item would be greatly appreciated.

[Gecko]

At first it sounds like a bad idea, now you need extra space to connect something to the circuit network? This sucks!

Yea, this definitely sucks! The simple argument 'you're base building til' now was so bad, you should have figured out a new layout by now anyway. Now you have the opportunity to do so. Is this not GREAT?' is just a empty hull of justification. As comments already suggested (and also IMHO) the player should be able to choose from either one. IF you're making the exception for lamps, you have to leave in the remains of the code responsible for the circuit network as it is now, anyways. So you can leave the choice of the 'better fitting' network setup to the player with no extra work on this part. You pointed out the memory usage would change only marginally, so no real need to worry there either.

I'm not gonna lie, I'm really craving the logic train network addition implemented to the vanilla game. If the cost is a super-ultra-usefull additional block... Well, I guess I'll pass on this one. There are a couple or even more mods out there implementing train logic using the logistic network as it is right now quite well.

• An example from the history of changes made in Factorio (yes, I'm with Factorio for a while now):
  
  I remember the change of the default request stack size amount for the logistic network. A not-so-small amount of people brought up really good arguments against it but it got implemented anyways. Soon after a mod popped up changing the default back to the value prior to the update Here. The funny point is: A few month after this change a thread popped up in the suggestion section requesting the default request amount to be zero or one Here.
  
  I admit it's a hard task to review all the changelogs, especially the ones produced from the Factorio team just because those are as plentiful as detailed (yea, I'd love a lot of other kickstarters and betabuild games would just do a fraction of the exhaustiveness) but it's funny for especially this topic to come up in the seen way. The suggestion for a config-option (which IMHO would have solved the problem for the convenience of all concerned parties) was never implemented. Still wondering why.

From History I became acquainted with taking the changes and waiting for a mod to change it back to 'normal'. So, I have no doubts this particular mod will come up eventually, because of the amount of people who are not content with especially this change. I'm really not sure if this should be the way to go...

[Koub]

Just a quick update, that I've been following this thread since it was posted and read all the feedback.
We are in the process of rethinking the idea of the circuit connector, so your feedback has been helpful

Just saying, chill (and Netflix )

[ssilk]

Instead of some extra object placed next to the object you want to control, it IMHO would be better that you could fit a controller into the object which allow to extend the behaviour and interface of an specific object.

I think that idea is nothing else, than the module idea - see https://forums.factorio.com/forum/viewtop ... 50#p124907
The idea is not possible for all devices, because it is then very important (I think I need not to explain why) to show somehow, that this device has a module/controller. And it will also not look good for some other types of devices.

The rest of that post is quite interesting.



The next part is a bit off-topic.

We are in the process of rethinking the idea of the circuit connector, so your feedback has been helpful

I remembered back and found this old thread from 09 Aug 2014
https://forums.factorio.com/forum/viewtop ... f=6&t=5276 Thoughts about circuit network (while I'm just on it)
I'm guilty.

Why I point to it: This thread is sometimes very vague, not very clear, it is just some discussion about possibilities. On the other side it becames very clear and clean:
https://forums.factorio.com/forum/viewtop ... =20#p43057

So it is eventually worth re-reading it.

Cause some problems has been seen here.
For example the problem with the cabling. It is too difficult to cable complex stuff directly on ground. As a player I want to hide the complexity once something is running.
I thought about a patch panel for that. Important is this part:

The module has one ore more input-signals and one or more output signals. So now I can connect a single signal from the incoming wires/wireless to the input-signal of the module and the output signals back to the wires/wireless, and give it also eventually a new name.

I played a lot around with that idea. And when I read, how Twinsen wants to fix this problem by adding just input-/output networks I thought: Well, that simple? Nice! That might be really a way to fix this problem.

Another idea was the comparison with the rack in Reason:

They (Propellerheads) solved the cludder with the cables with fantastic ideas. What you see here is just one of many.

Or a cool post by DerivePi:
https://forums.factorio.com/forum/viewtop ... =10#p41304
http://i.imgur.com/0lMrLFE.jpg


So I hope this brings in some new ideas.

[Masterpintsman]

Instead of some extra object placed next to the object you want to control, it IMHO would be better that you could fit a controller into the object which allow to extend the behaviour and interface of an specific object.

I think that idea is nothing else, than the module idea - see https://forums.factorio.com/forum/viewtop ... 50#p124907

With the slight difference that I propose that we can upgrade initial dumb devices with a controller, abstracting the interface (from UI and code perspective) once and for all smart objects, resulting in the system being completely modular:

• enable progression of research for base objects, controllers and function modules separately
• clear upgrade path for all smart enabled devices (replace controller with bigger one)
• mix/match according to needs (how many modules needed to wire an intended function decides size of controller needed)
• remove need to having an object type inflation with an individual crafting recipe for each
• the smart functionality would be unified (from player and code perspective)
• easily be bolted on currently existing objects to make them smart without having to redo them on an individual basis (graphics)
• cheap and easy to reuse for new objects (from UI, code and graphics standpoint)

The idea is not possible for all devices, because it is then very important (I think I need not to explain why) to show somehow, that this device has a module/controller. And it will also not look good for some other types of devices.

The information should be clearly visible in the (alt) overlay, which I guess most use when setting up stuff.

I'm not fixed on the idea that object and controller have to be mated inside an assembler, on second thought it would be simpler (in terms of being easier to implement, manage for the player, and buildable by robots) to have a special slot in the object to recive a controller item (like the speed/etc modules now for assemblers) which, when inserted, will extend the user interface with slots for modules and object specific wire connection pins.
It could also simply add a (purely cosmetic and reasonably small scaled) cross-connect box like this RL one:
(source: https://de.wikipedia.org/wiki/Datei:Kab ... Italia.jpg)
next to the object in the world, indicating existance and level of the controller (through size and/or color).
Add small antenna to it in case it has wireless interface (maybe with a colored light ontop to show newtork it links in), small poles or connectors (also color coded) for wired interfaces, maybe some blinkenlights showing state/amount of modules/stuff. So this would need only a handfull of base graphic assets (the boxes, and overlays for poles/antennas to be dynamically added in case corresponding modules are installed) to implement, instead of a complete grapnical redo of all the assets. The idea is to have it generic, so it can be added easily to every object in need without much special handling of the pecific object, so behind the curtain a location in relation to the object for the box and a list of wire endpoints (together with their corresponding get/set functions references to read/modify object state) for the controller would make up the definition needed per individual object.

Question is if it would be possible to have an item ingame that both can be placed in the world (in case we want a standalone controller, because I would really like that) and at the same time add-able as a subcomponent to a placed object (like current modules work), but I guess that shouldn't be a big issue.

Would something along that be enough to make it clear and be feasible, or which objects do you have in mind where that would not work?

The rest of that post is quite interesting.

Thanks.

I have not read through the forum in completion, so please excuse me in case I reinvent(ed) something already suggested.

For example the problem with the cabling. It is too difficult to cable complex stuff directly on ground. As a player I want to hide the complexity once something is running.
I thought about a patch panel for that.

That's one the reason I suggested to have a controller item (to make it flexible in terms of amount of functionality possible) that needs function modules (to make it flexible in terms of type of functionalities) and moved the logic wireing inside the controller UI, so that would not clutter the world that much (since there only the connections to other controllers, or power lines to objects with only an interface module for on/off control, would be needed).

[DOSorDIE]

Why not make a own layer for the cable? (like the ALT key for more Info)
And when i click on one item the cables for the maked item are more visible (thicker) as the other to see better where it go.
Also great where that we can move the combinators.
Why?
Make a concept with a wide range setup for better reading, and when finish move it to a block that we can blueprint it.

[ske]

Why not make a own layer for the cable? (like the ALT key for more Info)
And when i click on one item the cables for the maked item are more visible (thicker) as the other to see better where it go.

I'd like to second this idea.

Currently, when you hover over an item, the power poles are highlighted.

The same could be done for signal cables. Just give the cables a glowing outline or display them in bold bright red/green when hovering over a connected item. Similar to the the blue outline around items which are power connected, the signal connected items could be outlined with a red/green outline.

Combinators have two sides. Treat them separately for the hover-function and it should be very obvious which items are connected by which cables.

[ratchetfreak]

Why not make a own layer for the cable? (like the ALT key for more Info)
And when i click on one item the cables for the maked item are more visible (thicker) as the other to see better where it go.

I'd like to second this idea.

Currently, when you hover over an item, the power poles are highlighted.

The same could be done for signal cables. Just give the cables a glowing outline or display them in bold bright red/green when hovering over a connected item. Similar to the the blue outline around items which are power connected, the signal connected items could be outlined with a red/green outline.

Combinators have two sides. Treat them separately for the hover-function and it should be very obvious which items are connected by which cables.

or a little animation showing the data flow (to the combinator for the input wires and away for the output wires) So you can still show both and keep knowing what is input and output.

[Smoovious]

One thing that disappointed me while trying to build up some stuff, is I can't choose if the light is taking its condition from the provider chest only (circuit), or from all of them combined (logistics)...

I've come up with a way to do it, but it is very kludgy and involves using a few inserters and extra chests... hardly an ideal situation.

If I could pull the state of a smart inserter's condition, so if the inserter is enabled, the lamp could indicate that it is enabled, and same for disabled, that would fix my dilemma, but this still wouldn't be ideal.

Would you guys mind giving the lamp the same kind of option that the smart inserter has, where we can choose which signal(s) to evaluate to light the lamp? green wire, red wire, logistics?

I'm looking forward to being able to have the lamp's color changed as well, but given the choice, I'd rather have more options with the signal choice.

-- Smoov

[ratchetfreak]

One thing that disappointed me while trying to build up some stuff, is I can't choose if the light is taking its condition from the provider chest only (circuit), or from all of them combined (logistics)...

I've come up with a way to do it, but it is very kludgy and involves using a few inserters and extra chests... hardly an ideal situation.

If I could pull the state of a smart inserter's condition, so if the inserter is enabled, the lamp could indicate that it is enabled, and same for disabled, that would fix my dilemma, but this still wouldn't be ideal.

Would you guys mind giving the lamp the same kind of option that the smart inserter has, where we can choose which signal(s) to evaluate to light the lamp? green wire, red wire, logistics?

I'm looking forward to being able to have the lamp's color changed as well, but given the choice, I'd rather have more options with the signal choice.

-- Smoov

one of the sensors will be a logistics sensor that will output the contents of the logistics network

[MalcolmCooks]

With the new circuit network reader/writer, will electric mining drills be connectible? my favourite use for the circuit network is to switch off mining when not needed, so the belts don't get clogged up with ore. If I didn't need to use smart inserters that would be very useful!

[Supercheese]

With the new circuit network reader/writer, will electric mining drills be connectible? my favourite use for the circuit network is to switch off mining when not needed, so the belts don't get clogged up with ore. If I didn't need to use smart inserters that would be very useful!

Why not just keep mining until the belts are saturated...?