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

[kovibear]

I don't post very often, but definitely feel the need to voice my dislike of these changes.. at least, on paper.

Massive changes to the way the smart functionality and the things attached to them seems like a lot of work for what I (and clearly multiple others) don't see as an improvement. It feels a lot like complexity for the sake of complexity. I don't know why it wouldn't be easier to have toggles on smart devices that enable or disable their "extra"/"optional" features like logistics check-ins. I'd be way happier to see component cost increases, or other "nerfs" than another hit to an already suffering and limiting layout options.. and I say that as a player who has been using my own 90-degree inserters mod for over a year. It's so odd seeing so many things be rotatable for layout orientation and convenience, but then things like this be arbitrarily added for a sake of "consistency"?

I just don't really see how needlessly adding an extra block to do something that is already explained with the components of an object (smart devices are made smart by specific electronic components) can be perceived as anything but a waste of development and programming time. I'll withhold final opinion on it until we see the final implementation, but right now.. I'm not seeing anything good coming from it.

I definitely see the applications and need for an official sensor-type object that will allow us to detect build logic around conditions of blocks they pointed at (detecting inventory of train cargo, fuel, etc..) to couple more functionality with what is already in place. Sensors, train logic implementation, and a few other logic objects will pretty much give us players everything we need and want for the majority of applications we can't currently achieve.

All of that said, you're the developers of the game and what you feel is the right choice for balance and optimization is ultimately your choice.. but I personally see these changes being something a majority of veteran players (the people who have supported and played the game for this long) will mod out, assuming they actually go through. It's possible there's more to it that we're not seeing or isn't being explained ideally, but I'm just concerned about these changes. You guys are great about taking feedback and working with the community to make the best choices, and I just hope that the best compromise or option for everyone is what ultimately gets implemented.

Looking forward to seeing how the changes unfold or evolve, though.. and hoping I wind up being wrong.

[Cbrad24]

I have a suggestion for the train controlling.

Connecting a "Reader" to a track reads whether there is a train in the block (i.e. whether a signal facing into the block would be red).
Connecting a "Reader" to a signal reads whether the signal is red.

Writers could have two conditions for two different "levels" of how much they affect the train network.
Connecting a "Writer" to a track, at level 0 does nothing, at level 1 makes the game behave like there was a train on the track (so that signals leading in become red), at level 2 makes it like that the track didn't exist (so trains don't path through that track piece).
Connecting a "Writer" to a signal, at level 0 does nothing, at level 1 makes the signal behave like a chain signal, at level 2 turns the signal red.

I believe with these you could make fancy prioritisation or time-division signal systems, which is something I've wanted to do for a while, as well as make a safe at grade crossing (manually switch constant combinator -> turns signals red), and just generally be able to have the factory react to a train showing up.

Also +1 to whoever it was that suggested calling them "sensors" and "actuators".

Also also, they should be able to connect to gates. Readers tell whether it's open or not, writers force it open (or force it closed).

Also x3, the newspost mentions turning belts off and determining number of items on belt. Does this mean just one belt square, or the whole line of connected belts (traversing corners but stopping at merges/splitters/side-loaders/perpendicular underground belts)? Because the latter would be much more useful than the former

+1 to this. Need gate control and some bare minimum of turning a signal red. Wanted to make safe crossings for so long (I play with my 12 year old brother who dies on trains every now and again + It'd be awesome to setup ).
Apart from that the new control sounds good, but reading through all this thread there is some good improvements to be considered.

[Swich]

I think it's a good choice. It makes some logic more simple. I think it's the way final game should look: you just have few simple components, and few logical component to control simple. And from this you don't need to think "I have only smart inserter", or "I need to make something to control charging and discharging accumulators". Of course, this things make some kind of challenge in the game, but I think it will be better when you have some simple construction's block, which you can connect to each other and make some complex and great thing. And the process of construct don't need to make special challenge, I think the freedom in construction and more possibilities in function will be much better. It's sound great, when you don't need to think about smart inserter, or anything else like this, and just place any kind of inserters, and connect it to some kind of "smart controller" which will control how it work. I think it's also a more "natural" way to constructor difficult things. I can't wait to try this type of construction!)

Am I understanding correctly, that every single entity that we want to have a circuit condition is going to need its own circuit network condition writer? For example, if I have 32 red circuit factories that I only want working on a single network condition, I will also need 32 writers next to each assembler? If that is the case that sounds incredibly and unnecessarily tedious.

I also hope you can connect 1 writer to many things.)

[Kalanndok]

I also hope you can connect 1 writer to many things.)

That's what got me concerned...On the reader side it is supposed to actually be like that. That's why they wrote lamps would stay as they are so that you don't have to put a reader to each lamp. So that would imply that for the writer you'd also need one writer per chest to put on the wire.

[Fatmice]

Why can't the two new objects be one, call it a local controller, and allow it to have an area affect where it can service or sense things, much like the beacon? This would ameliorate the concern that 1x1 entity will complicate the layout of things. Drop this maybe 1x1 entity with a service area of say 5x5 in the middle of some entities you want to control and it will give you sensory information and control points for the entities. Registration/unregistration of entities to this controller is based on seniority if there are overlaps. Access to individual entity under the service area is by index where you simply number them ascending starting with 1 from upper left to bottom right. This allows the turning on or off of certain entities when condition is satisfied. There should be some global control like turning off all entities or change recipes of all entities. I think these changes would make the new object more liken to a combinator and not some dangling modifier.

[Uristqwerty]

Sounds like an interesting change with valid motivations; too bad it's attracting the all-too-common response of "it sounds less convenient than what I'm used to, therefore it will suck".

[Kalanndok]

Sounds like an interesting change with valid motivations; too bad it's attracting the all-too-common response of "it sounds less convenient than what I'm used to, therefore it will suck".

The complaints are rather "If it works how it appears to work I'll be required to refactor all my combinator builds which got distributed through 50 outposts via blueprints."

[psihius]

Sounds like an interesting change with valid motivations; too bad it's attracting the all-too-common response of "it sounds less convenient than what I'm used to, therefore it will suck".

The complaints are rather "If it works how it appears to work I'll be required to refactor all my combinator builds which got distributed through 50 outposts via blueprints."

Make a new blueprint, copy-paste.
Yes, it will take some work, but really, in Factorio, that can be automated

What I would really like them to fix, is train positioning. So we can finally have predictable station loading/unloading layouts and inserters on the sides not having to reach into the middle (although, writing it, did they actually fix it in 0.12.x? I don't see that happening any more in Arumba/Steejo current play-though...)

[Oxyd]

What I would really like them to fix, is train positioning. So we can finally have predictable station loading/unloading layouts and inserters on the sides not having to reach into the middle (although, writing it, did they actually fix it in 0.12.x? I don't see that happening any more in Arumba/Steejo current play-though...)

Inserters reaching into the middle of the cargo wagon was fixed in 0.12, yes.

[ske]

One change I'd like to see is having this as a module instead of extra entitity on the map.

Right now I don't like the module system because it's pretty unspecific and works like magic spells making a factory faster or consume less energy. That doesn't really make sense.

Having a logic module, a transport module etc. to be inserted into other items like assemblers, inserters, chests, turrets, etc. to give them extra abilities would make much more sense to me.

Insert the logic module into something and you can attach a wire to it.

Insert the logistcs module into something and it can send/receive items.

An assembler requires a motor. You can insert a coal burner motor, a diesel engine or an electric engine and the result is different speeds.

[SWSe]

This doesn't seem like a bad idea, but I still don't really like it. That's partially because I'm not sure I completely understand how it's going to be like when it's done.

The problem that I see is these huge 1x1 blocks just make no sense at all. You have all these cool machines, but for simple tasks of comparing values and whatnot, you need computers 1000% the size of what we use today. Sensors aren't that big, and mobile phones are capable of everything necessary for that. I already thought combinators weren't fitting into the world very well.

What's even worse, I can't really think of how this would enhance gameplay. I'd gladly take the absence of logical explanations if it's for cool additions, but this doesn't seem to give you new awesome possibilities, but only uneccessarily limits your options. This adds complexity that might be more tedious than fun.

I could imagine something like others already proposed: Basically not building a special entity next to something, but rather enhancing any existing building (like modules do) or to build these new connectors ON TOP of the existing thing.
So you basically have a normal chest, you select the connectors that you have in your inventory, and build it on the same spot as the chest. Its graphic is then updated with some kind of device that can be easily recogniced, but doesn't take too much space (so it's somewhere on the edge of the chest, in this example).
-> The problem with the GUI can be solved by adding a Network button that appears on the interface of any entity that you've enhanced with a connector, so it's always working the same way. The network can then be managed in an own window, and you can switch back to the normal gui, like it's always been the case with trains.

Or just allow all these entities to be connected to the network without any special added buildings. Just add that button as just described.
That'd have the advantage that it doesn't need any new buildings to be added into the game.

As for the performance savings: Can't you get the same effects in some way by simulating this the way you intend, but the player doesn't have to use these connectors? Just add in an "invisible" connector if a belt is linked to the Network.
To be honest, I didn't completely understand how you meant that. I'm sure you'll do a good job, whatever it is going to be.

[ratchetfreak]

I also hope you can connect 1 writer to many things.)

That's what got me concerned...On the reader side it is supposed to actually be like that. That's why they wrote lamps would stay as they are so that you don't have to put a reader to each lamp. So that would imply that for the writer you'd also need one writer per chest to put on the wire.

And this is the problem with the reader/writer terminology. confusion about what is being read/written.

• "Circuit Network Connector Reader" that is responsible for reading stuff from the connected entity, like reading chest contents, reading accumulator capacity.
• "Circuit Network Connector Writer" that is responsible for controlling the connected entity, for example turning entities on or off.

[Lupoviridae]

I really like the concept here, but I definitely think it needs some tweaking. Namely:

1) Having a sensor for chests seems superfluous. I would much rather have wires directly connectable to the five "smart" chests as they are now. It is simpler to understand, requires less elements, and (considering these are electronic chests) makes more sense to me. If it ain't broke, don't fix it.

2) I agree with what other people are saying in this thread. One actuator to one building/inserter would get old pretty fast. From what I understand the main reason for this is to have a separate entity that executes the necessary code to increase performance and limit GUI changes. You are also trying to tackle a lot of design challenges with a single implementation. So here is my suggestion; have the actuator attach to power poles instead, and turn off power to buildings/inserters in that grid when a certain condition is met. Advantages to this approach:
-Still adds some additional design challenges (2x1 power poles, need to make sure power grids don't overlay), without being obnoxious
-Allows controlling of multiple buildings/inserters with minimal logic/performance impact
-The actuator can take circuit information directly from the pole! No wires needed.

The sensor idea seems solid. One sensor per pipeline or belt will be enough to serve the necessary function. (Honestly I would have tanks and accumulators able to attach directly, but needing one sensor per tank setup or accumulator array isn't bad.)

3) I also really want to see a push button entity (generates a 1 tick signal) This opens up a huge world of possibilities. Imagine building tetris or snake in game, you need up/down/left/right buttons.

[hitzu]

I don't see the necessity in having two different entities serving opposite functions. Instead of the distinct Sensor thing let's embed this function to all entities by default.

[tecxx]

The problem that I see is these huge 1x1 blocks just make no sense at all. You have all these cool machines, but for simple tasks of comparing values and whatnot, you need computers 1000% the size of what we use today. Sensors aren't that big, and mobile phones are capable of everything necessary for that. I already thought combinators weren't fitting into the world very well.

+1, same here.
i always wondered why we have to build these strange combinator parts instead of simply getting a script interface where i type some if/then/else code. would be way more geeky and fitting anyway. that said, i never used combinators because it simply didn't fit my playstyle.

[tecxx]

3) I also really want to see a push button entity (generates a 1 tick signal) This opens up a huge world of possibilities. Imagine building tetris or snake in game, you need up/down/left/right buttons.

don't take this personal please, i just find this comment to be the best example of why i think that factorio development has went the wrong way in the past couple of month. christmas lights and computers-in-computers and these things are nice and all, but what about the core game?
where are long needed features like fluid container trains, offical FARL implementation, resource spawner tuning, biter overhaul, a nice tech tree, making it actually challenging, a proper endgame, i could go on with a long list. mods are no excuse, the core game needs polishing. factorio promised to become the "next gen" transport tycoon, it definitely has the potential for it, but for me it feels that development has stalled for quite a year or so.

[Keks]

Am I understanding correctly, that every single entity that we want to have a circuit condition is going to need its own circuit network condition writer? For example, if I have 32 red circuit factories that I only want working on a single network condition, I will also need 32 writers next to each assembler? If that is the case that sounds incredibly and unnecessarily tedious.

not really just use a single writer to stop the Belt that delivers one of the resources and the whole complex will stop working.
Or better create a sub power-network using the power switch and turn even the Idle Powerdrain off.
as long as you can narrow the conditions to shut off everything in an area down to a single condition it's no problem

it's a bit worse for your smartinserters put a powerswitch between the pole powering your smartinserters and the energy network and you can turn them off you won't be able to control them individually though, which sucks.
i think the writers aren't the biggest problem the readers are making it impossible to put more then two chests next to each other if you want to wire them up (at least if they are filled and emptied by inserters. Logistics chests won't be to terribly affected ) . or we all will have to unload trains by logistics bots in the future which wouldn't be so bad once you are in the endgame.

Please consider leaving existing 1x1 entities that can be wired at the moment as they are.
I at least can't see the downside of doing so.

the next best solution would be this

Make each connector link to a block of contiguous identical entities and I'm sold.

So four chests in a row (or square) would all contribute to the signal if any of them are linked to a circuit connector. Same with inserters. This greatly mitigates the space issue. As written, connectors basically make smart chests and smart inserters into 2x1 entities, which is horrible. Allowing connectors to link to a block means you don't have to blow up your designs, you just need to use an extra space on each row.

but a 100% increase in required space for smartinserters & smartchests is a terrible Idea

greetings a Cookie

[Ohlmann]

As described, this update look *horrible*. There is three problem :
* the addition of a shitton of 1x1 stuff. 1x1 is a lot of space already, and as written I may very well need 3 of thoses per assembling machine
* the addition of a lot more wiring, since what was done with 1 wire will need 2 or 3 now.
* the removal of a system who was very simple to understand and very deep to use.

In short, despite the clarification, that look so spectaculary bad a feature I might want to stay on 0.12 to avoid having to deal with that shit.

Can the dev at least ensure they will be able to rollback that change if it end up being too bad ? It might end up good after adjustment, but for now it look like it's on very bad tracks.

[Linosaurus]

tldr: Please make an exception for smart chests and inserters. Sounds great for other things though.

A separate control block is a good way to add a second GUI to something like an assembler without confusing new players.

• Belts - good because only a few will be connected thus an obvious visual identifier is helpful.
• Assembly machine - ok because a control block will fit into my current blueprints without making them bigger.
• Tanks, pumps, train stations, roboports - ok because I only connect a few and there's free space around them.
• Accumulators, miners - if I need it I'll accept a bit of clutter. Space usually isn't a problem there.

But I really don't like it for chests and inserters.

• They are small and used in big numbers, so an extra block is a big change.
• A line of inserters would have ~half the throughput with logic blocks added.
• Chests don't seem to need a new GUI to connect them to the network.
• Smart inserters... yes, current gui is a bit confusing but really useful.

Compromise idea: remove logistics network (only) from smart inserter.

• GUI now has 2 functions instead of 3.
• For a single inserter I can use a logic block.
• For a line of inserters I can use wires and a logistics-to-circuit network logic block (this would need to exist)

Maybe consolidate the circuit reading and writing blocks into one. You only need a checkbox in the gui to toggle reading, this is worth it to have one less item to transport to new outposts.

[malcmiller]

You know what they say.
If it aint broke...