Factorio Forums

Talguy wrote:Instead of using the circuit network to control trains, wouldn't it make sense to just have a "goto schedule line IF" rule in the schedule? The conditions could even support reading contents of a specific item type (for filtered train wagons)

This is what was suggested. The conditions could also be "circuit conditions", and then you have the option to use the circuit network for train control (without losing the simpler possibilities).

At least you should be able to take the "order number" (station number) from the circuit network, because that's required to actually "calculate" dynamic routes in a circuit.

The main thing I want to see improved that is on that list is the building of roboport outposts while some of it is off the build zone of the nearest roboport.

Things I don't see on there, that I wanna see are a second tier tank, reduction of the # of bots that follow you and making guns/biters longer range again.

When it comes to train control, look at this thread!

"Smart dynamic train deliveries with combinator Magick [0.13]"
viewtopic.php?f=8&t=25311

If you can incorporate functions like send train to station etc. so the above can be done without the need for a Smart trains mod it would be awesome!

I only voted for 4 options, because I want to use my last one to downvote "assembling machine set recipe".

The beauty of this game is being able to see production lines on the map. Hiding a production line inside the circuit network ruins that.

DaveMcW wrote:The beauty of this game is being able to see production lines on the map. Hiding a production line inside the circuit network ruins that.

Yeah, such a change would ruin the game for good. Just glad it isn't possible right now. Image we had robots to transport items directly between machines, belts would be useless after that point.

siggboy wrote:

DaveMcW wrote:The beauty of this game is being able to see production lines on the map. Hiding a production line inside the circuit network ruins that.

Yeah, such a change would ruin the game for good. Just glad it isn't possible right now. Image we had robots to transport items directly between machines, belts would be useless after that point.
[...]

... there is a downside to using circuit networks to set a recipe: Throughput.

Since basically the recipes would have to be processed sequentially... so it might not be appropriate to use such a setup for everything, but rather when the assembler is going to be idle a lot.

DaveMcW wrote:I only voted for 4 options, because I want to use my last one to downvote "assembling machine set recipe".

The beauty of this game is being able to see production lines on the map. Hiding a production line inside the circuit network ruins that.

I think having this feature would open new possibilities for new and creative designs. Nobody would be forced to use it.

If there would be even a chance rocket circuit conditions (remote control, autolaunch) wouldn't make it to the "implemented" list, I'd change all my 5 votes to go for it. It really is crucial in large rocket-churning factories, and I hate to make mod-dependent megabases.
EDIT: ok I didn't mean to whine about mods, just that it's so basic and useful that it should be in vanilla imo

BlakeMW wrote:Another voice for red/green selection, maybe something like this:

green red wire select.png

In the screenshot I suggest using two buttons per input which can be clicked on or off, but it could use a single button which cycles between three options:
Both, Red, Green

Technically there are more possibilities which can be imagined for the input side:
Red + Green, Red - Green, Green - Red, Red, Green

The ability to subtract signals within a single combinator would be pretty powerful. Technically you could go crazy, why not Red * Green, or Red % Green, although combinators with complex wire combining arithmetic would become positively cryptic so it would probably be best to only have 3 options.

I love that idea. It's immidiatly clear what it's about and what it does.
You could also add a 3rd grey state for adding both like it currently does.

MeduSalem wrote:... there is a downside to using circuit networks to set a recipe: Throughput.
Since basically the recipes would have to be processed sequentially... so it might not be appropriate to use such a setup for everything, but rather when the assembler is going to be idle a lot.

The ability to set an assembler recipe from a circuit falls into the same category as setting the train destination from a circuit. It is something that the majority of players will never use in a normal playthrough (the majority doesn't even use combinators, I certainly haven't in my first few games and now I'm addicted to them).

Some very clever, compact setups are possible if you allow circuit controlled recipes. Also, since it's already possible to manipulate logistic slots in requester chests, and set filters on inserters, and count belt contents, it would make a lot of sense to be able to control the assemblers as well.
It would also be great if we could read what's currently inside the assembler (input slots and output buffer), and the same should be possible with furnaces.

You're absolutely right that a "smart assembler array" would be very throughput limited, but that's OK. You could make a resupply mini-factory, that scans the resupply train for missing supplies and then crafts exactly those that are needed. If everything is circuit connectable and some of the inserter limitations are removed, a practially perfect on-demand manufacturing would be possible.

It's really not clear to me at all how Dave can be so opposed to this -- it's not going to make belts obsolete at all, you still need them for mass production of anything or you'd need mass robots (and that has been possible for a long time now).

siggboy wrote:The ability to set an assembler recipe from a circuit falls into the same category as setting the train destination from a circuit. It is something that the majority of players will never use in a normal playthrough (the majority doesn't even use combinators, I certainly haven't in my first few games and now I'm addicted to them).

Some very clever, compact setups are possible if you allow circuit controlled recipes. Also, since it's already possible to manipulate logistic slots in requester chests, and set filters on inserters, and count belt contents, it would make a lot of sense to be able to control the assemblers as well.
It would also be great if we could read what's currently inside the assembler (input slots and output buffer), and the same should be possible with furnaces.

You're absolutely right that a "smart assembler array" would be very throughput limited, but that's OK. You could make a resupply mini-factory, that scans the resupply train for missing supplies and then crafts exactly those that are needed. If everything is circuit connectable and some of the inserter limitations are removed, a practially perfect on-demand manufacturing would be possible..

Well, I voted for the ability to set Recipes by Circuit network because it opens a lot of new possibilities and it's not like anybody is forcing you take advantage of it. Though I would wish that if it really becomes a thing that Furnaces and maybe even Chemical Plants (depending on Pipe mechanics rework) would work the same way by being able to force a recipe switch with circuit signal.

My other concern is that without being able to specify an inserter stacksize via circuit signal as well it probably would be very much of a problem to switch recipes because of the residuals. If the Assembler/Furnace would take care of the residuals itself then the stack size bonus might be not that much of a problem anymore. That said it might still be a problem for smart train loading. So the Inserter Stacksize depending on Circuit network signal is definitely something the Twinsen/the Devs will have to have another look at.

MeduSalem wrote:My other concern is that without being able to specify an inserter stacksize via circuit signal as well it probably would be very much of a problem to switch recipes because of the residuals.

The "residual" problem needs to be solved comprehensively, or else a lot of solutions will always be very convoluted. Maybe the inserters should be able to put leftovers back, that would always work unless the item source is filling too quickly (that would be rather easily avoided).

If the filter signal would also set the stack size (i.e. the precise count of items that are picked up), that should be sufficient for feeding programmable assemblers. But there are still scenarios where it would simply be a lot better if the inserters could return the "residuals" to the item source.

siggboy wrote:

MeduSalem wrote:My other concern is that without being able to specify an inserter stacksize via circuit signal as well it probably would be very much of a problem to switch recipes because of the residuals.

The "residual" problem needs to be solved comprehensively, or else a lot of solutions will always be very convoluted. Maybe the inserters should be able to put leftovers back, that would always work unless the item source is filling too quickly (that would be rather easily avoided).

If the filter signal would also set the stack size (i.e. the precise count of items that are picked up), that should be sufficient for feeding programmable assemblers. But there are still scenarios where it would simply be a lot better if the inserters could return the "residuals" to the item source.

I think we are probably needing both... Filter Signal setting the Stacksize for Inserters... and if it's only to deal better with smart train loading. Because a stuck inserter is really bad for that setup and not being able to top off the slots is also inefficient.

... and a way to deal with the residuals, though an automatic way would be preferable.


I had a lot of time to think about the residual item problem ever since the idea of setting recipes with a circuit signal first came up and I actually think that removing the residuals with an inserter is ... urgh. It would make things rather a complicated mess... and quite inefficient because you have to move items more than once (in and back out and back in).
I mean I probably could live with having to remove the residuals first, but it would be highly inefficient because it would take a lot of time to remove all the crap from the assembler/furnace and then restock with the correct ones. So that's why I'm saying that once an item is inside the assembler/furnace it should be left inside to reduce uneccessary overhead.

I think the best approach would be to have some limited buffer slots (like 6-10 slots, and each of the 6-10 slots can be filled with another resource) within the assembler which the assembler can work with. If you set a recipe with a signal the assembler checks if the required resources are inside the buffer and if so starts crafting, if not it will wait until the buffer has the items. That wouldn't require you to remove any residuals from the assembler - they would stay in the buffer until you resume the other recipe again.
While the Assembler is working on a particular recipe you get even time to refill the buffer slots with resources (even ones the current recipe doesn't need) so that when you switch recipes the inserters don't have to start filling from scratch and instead the Assembler/Furnace can start to work immediately.
The amount of buffer slots would be obviously up for balancing and could be increased with research. The current items in the buffer slots could be an output signal from the assembler to the circuit network so you get feedback on what's currently in the buffer and adjust accordingly, though I imagine that being difficult to implement because that probably results in a feedback loop where the assembler can't differentiate between it's own buffer slot signal and the signal that sets the recipe.

With that approach one could build a smart assembler/furnace without having to worry about removing residuals first...

... and it would also satisfy Dave a little bit because then there's recipe switching but it can't be used to switch recipes universally... since you only have limited buffer slots the assembler can work with, so the recipes would have to have pretty similar resource requirements.

Perhaps your buffered assembler would work nicely as an upgraded (possibly a 4x4, depending on how nice it is?) variant on the regular assembler. It's a somewhat unusual item, and has additional complexity to using, in comparison to the regular one. Such things would, however, potentially also fix a problem I've had which is the inability to specify how many recipes worth of spare items should be buffered. I have, more than once, had situations where an assembler was waiting on input materials from an inserter, and the inserter would deliver them, then wait a bit before trying again. If the system attempted to keep a few more recipes worth of raw materials in stock, this would not be a problem.


Personally, for the residual problem, I think that the assembler should just enter a "passthrough" mode when the recipe changes -- it moves unneeded input-slot items to output (where they can be extracted as normal). This would produce slightly higher operational complexity (your output can either be your programmed output, or extra input), but I think it would be workable with filter inserters. In a system that used Logistics to do the sorting it would basically be no extra complexity, and a programmable factory is already something that requires some care, thought, and complexity management. I do, however, like this because it is a very simple and intuitive resolution to the problem.

siggboy wrote:

MeduSalem wrote:My other concern is that without being able to specify an inserter stacksize via circuit signal as well it probably would be very much of a problem to switch recipes because of the residuals.

The "residual" problem needs to be solved comprehensively, or else a lot of solutions will always be very convoluted. Maybe the inserters should be able to put leftovers back

If the residuals don't match the new recipe, the easiest solutions would be throw them in the garbage or stick them in an invisible active provider chest.

Another idea is to treat the assembler like a chest and allow access to the residuals via inserter. You could have everything lumped together and force the user to figure out what's residual, which is a PITA. Or the devs could visually separate the assembly machine from the residuals unit. If an inserter points to the assembly machine, items are only for the current recipe. If an inserter points to the residuals part, items could be anything (including maybe overflow for the current recipe).

I wouldn't object to a comprehensive solution to the "residual" problem. If that's something you really want, try to get it added to the list.
For me that's not in my top five.

On a lighter note, here's how I recently solved the residuals problems:



Isn't it beautiful? My first ever supply train. Twelve requester chests and 12 filter inserters. (The filter inserters aren't strictly necessary but I like to do it that way as a precaution.) I only made the supply train because I was doing the "raining bullets" achievement and it was getting too unwieldy to have all my outposts covered by a single large logistics network.

I have to add another comment here since I see its not voted high enough:

"New wire drawing: vectorial, primitives. Proper sorting order for wires on ground. Bonus: Wire dangling on pole hit, train pass, etc."

New wire drawing! For the love of all that is holy, give me a quickbutton so I can get rid of the graphical birdsnest and give me a clear picture of what is connected to what. Im talking VERY clear and straight wire diagrams here, just like you can see icons when pushing alt, we need something similar for wire connections.

Some designs are complex and even when I do stuff myself its sometimes nearly impossible to visually see if a wire is connected to a certain combinator.

doxsroxs wrote:For the love of all that is holy, give me a quickbutton so I can get rid of the graphical birdsnest and give me a clear picture of what is connected to what.

There's the debug option that will show you the network numbers, which sometimes helps with seeing the connection.

But of course you're right, the wires should be drawn schematically in "alt mode", so it would be easy to see what's going where.

The best thing would be to have a blackbox circuit where all of this would not even be an issue since there would be specialized UI for making circuits inside the blackbox.

How about Random generatort destroyed bases from other survivers

It is nice to see that we have a say in what might happen next

Hello and thanks for listening to the comunity and giving the oportunity to express our desires. We in a hostile planet appreciate that.

It was hard as many have mentioned to select only 5 improvements or wishes. I started using combinators seriously recently and I think is a great extension of the base "launching a rocket" game. There are so many possibilities and so many talented people doing cool stuff. I think the train control was improved in .13 but it has to be more. I love openttd and I love making trains so a better control and a programmable train system would make me so happy. Then more combinators, specially != and <= =< also logical AND and OR would be nice for space saving. Regarding this I think that something like factorissimo could be implemented to "build" the circuits in a "box" that after you can connect (with a number of pins) to other "boxes" or wires. I think this would solve the problem of people complaining of the size of the circuits that I agree is very unrealistic, given the size of the robots for example. And this way you also skip adding an special editor or paralell GUI for circuits, you just srink yourself to the sice of the circuit, build it and come back your size again . Then last the ability to choose the recipe for an assembling machine/refinery is great in my opinion since you could create smart factories where you put in a chest something and the factory produces it in a certain quantity (for example xDD).

So I love Factorio and I plan to spend lots of hours building stuff and trains, I'm just so happy wandering around with the trains.. I'll be waiting for the news on 0.14