Friday Facts #66 - Merry christmas

[ssilk]

Being able to fill a box with exactly 10 ore 10 copper and 10 rocket defences is something very basic and should be handled by smart inserter. Currently i dont know any wat to achieve this without using 3 "smart" inserters.

Therefore we have the logistic robots.
Choose the right tool for the right work, my grandpa said.

[kovarex]

Being able to fill a box with exactly 10 ore 10 copper and 10 rocket defences is something very basic and should be handled by smart inserter. Currently i dont know any wat to achieve this without using 3 "smart" inserters.

With combinator it will be possible. It will not be so easy, but it will be possible. You could make a two conditional combinators, one would send a signal when there is less then 10 copper, the second would send a signal when there is less than 10 ore. The signal would then be connected to the inserter.

[Cloner]

Being able to fill a box with exactly 10 ore 10 copper and 10 rocket defences is something very basic and should be handled by smart inserter. Currently i dont know any wat to achieve this without using 3 "smart" inserters.

With combinator it will be possible. It will not be so easy, but it will be possible. You could make a two conditional combinators, one would send a signal when there is less then 10 copper, the second would send a signal when there is less than 10 ore. The signal would then be connected to the inserter.

Really? So will the inserter add only copper when it lacks and add only iron, when iron lacks? Because from what I see now - i send signal and inserter picks one RANDOM item and plases it.

[Cloner]

Being able to fill a box with exactly 10 ore 10 copper and 10 rocket defences is something very basic and should be handled by smart inserter. Currently i dont know any wat to achieve this without using 3 "smart" inserters.

Therefore we have the logistic robots.
Choose the right tool for the right work, my grandpa said.

Good luck using logistics robots to unload a wagon.

[kovarex]

Being able to fill a box with exactly 10 ore 10 copper and 10 rocket defences is something very basic and should be handled by smart inserter. Currently i dont know any wat to achieve this without using 3 "smart" inserters.

With combinator it will be possible. It will not be so easy, but it will be possible. You could make a two conditional combinators, one would send a signal when there is less then 10 copper, the second would send a signal when there is less than 10 ore. The signal would then be connected to the inserter.

Really? So will the inserter add only copper when it lacks and add only iron, when iron lacks? Because from what I see now - i send signal and inserter picks one RANDOM item and plases it.

Not really, sorry it was an error in my thought

[just_dont]

This (and many similar situations) could be resolved pretty well if we had variable-sized storages. At the moment, the biggest limiting factor with chest-based layouts is the fact that chests are 1x1, and a single chest can be worked by only 4 inserters, never more.

Well, we have train wagons used as big chests, but (much like the belt lane splitter trick) I consider this a non-normative way of doing things. Besides, it looks rather ugly.

PS: Or by having adjustable inserters. Same story. If a chest could be worked by (for example) 8 or 12 or 16 inserters instead of only 4, it would ease things quite a lot.

[Cloner]

Not really, sorry it was an error in my thought

See ... even you thought that it will be possible .. because this is the thing that is needed from smart inserter
Can you perhaps add quantities to the "filter" menu? (This way I can designate how much of each item i want at destination.)

Just imagine, you could load on belt the exact quantities of everything that an assembler down the lane needs.
Plus with your new combinator I could use a single belt for all low quantity production, and just toss the exact needed amount of items of each type.

If a chest could be worked by (for example) 8 or 12 or 16 inserters instead of only 4, it would ease things quite a lot.

Big chests is not a complete sollution (we have a 2x1 chest already - a car). Smart inserters should be smart.

[ssilk]

This (and many similar situations) could be resolved pretty well if we had variable-sized storages. At the moment, the biggest limiting factor with chest-based layouts is the fact that chests are 1x1, and a single chest can be worked by only 4 inserters, never more.

But can by worked by any amounts of bots.

PS: Or by having adjustable inserters. Same story. If a chest could be worked by (for example) 8 or 12 or 16 inserters instead of only 4, it would ease things quite a lot.

For me this is going into a meta discussion, cause I think there are many ways to change inserters in a way, that they can do this, but none will be really good. None will be so that everybody thinks: yeah, that's it!

Either use robots, or we invent a completely new way to do this, but inserters have those "physical limitations".

Maybe a completely new device, some kind of selective vacuum cleaner, which sucks the items from the belts. Something, which is physically connected to the source/target-devices, so that really only one device can be plugged in. Even the character cannot change the contents of that, if this is connected. Some kind of lock.

But as long as you can connect many inserters to one device you will always have this problem, that the inserter cannot know what has changed meanwhile.

[Cloner]

...there are many ways to change inserters in a way, that they can do this, but none will be really good.

There are several good methods:
1. Add quantities for each item in smart inserter filter. "I want this smart inserter to only pick ore and copper until there is 10 of each at destination"
2. Smart inserters should serve requester chests the same way robots do - insert only requested items, in requested quantities. This makes game mechanics consistent. I do not see a single reason why smart inserter shouldn’t follow this rule already.

None will be so that everybody thinks: yeah, that's it!

The listed methods are super intuitive and everybody thinks: "yeah, that's it!" (even now most new players think that this is how it works, until they find out that it doesn’t work)

[kovarex]

That seems reasonable.

[just_dont]

Either use robots, or we invent a completely new way to do this, but inserters have those "physical limitations".

Please excuse me for derailing the discussion somewhat, but this is a very wrong statement. Inserters are presented in-game as a (relatively simple) automated mechanic arm manipulator, and most of their current "physical limitations" are, in fact, very counter-intuitive. For example, the reason that people very often suggest ways to make inserters customizable, starts from the very simple "logic check": why a flexible robotic arm can pick things only from a certain point in its reach and put them back only into a certain other point? Why not any point?

The reasons why current inserters behave like they do are mostly "gamey", and has nothing to do with intuitiveness, common sense, or other such things. And about the only reason why extended inserters mods are never always popular -- is the fact they always create rather horrible clutter (having ~20 different types of inserters for each case is just overkill). As far as I know, nobody (yet) made a nice modded customizable inserter with easy-to-use customization GUI and that could be usable in blueprints.

PS: The "current state check" that you're referring to is NOT a problem. You can always "lock" a certain logic state via a secondary logic circuit (effectively serving as a boolean variable) and then execute certain commands in certain order without caring for fluctuating conditions.
(the oft-used practical example of what I'm talking about: on certain conditions, get a piece of wood out of a special chest, then execute some other unrelated stuff for as long as there's no wood in that special chest, and that piece of wood will be picked back up on certain conditions signifying the end of current active cycle).

PPS: This post, of course, is not exactly related to the issue raised by Cloner, but it's more about general belts+inserters/bots balance.

[branetown]

PLEASE add to the network the option to upgrade buildings.

I.e. if the network senses "yellow" belts and I have "red" belts in the network, and I have checked the option to do so, construction robots remove the "yellow" belts and replace them with "red" etc. Large factories are in desperate need of this....

[just_dont]

Another general thought about "endgame content":

There should be enough of stuff to do on the current gameplay level (making factories). One of the problem of automation is that it naturally scales extremely fast (simplistically speaking, 1 factory makes stuff to build another factory, then 2 factories make stuff to build 2 more, and so on, and after a moment you have 4537943728 factories making stuff for 4537943728 more). Thing is, we don't have any gameplay that covers such scale. Thus, the game quickly becomes rather boring once you have some modular blueprints and resources to just plop then where you need it -- we're done with the "making factories" step (which was fun) and we're just plopping them now -- and it's rather bland.

Now, I'm not proposing that there should be another type (sim-management game?) of gameplay to cover things on large scale. Games that try to bring in several gameplay types without a really good idea on how to combine them usually fail big time.

I'm proposing that we (the players) should have enough deterrents to keep us busy and away from the "exponential growth" phase. One such deterrent could be the combat (naturally), expect that at the moment it doesn't work this way. Currently, combat is a time-based tech-gate (either you have certain tech levels vs. certain biter levels and you faceroll them, or you don't and they faceroll you) rather than some complex and less predictable process.

Other deterrents could be somewhere in the direction of increased complexity -- we already have "nonstandard" liquids that can't be handled like items, and thus require different approaches. We could have more of such things (there's, for example, a suggestion about "big and heavy" things that won't go into any inventory), and so on.

The bottom line is: when the game passes "we're making factories" phase -- it quickly becomes bland (you'll be probably still making rail networks, but it's already much more bland than making factories). Therefore, the game should be adjusted in any possible way to prevent players from reaching that stage (ideally forever, but at least for some time).

[kovarex]

Don't forget, that the game can't be infinite, that is why we want to add the ending.

I totally agree, that adding more and more recipes and technologies with the same principles is not bringing much more additional fun to the game, that is why we should add new concepts if we want to extend the game.

[Cloner]

Don't forget, that the game can't be infinite, that is why we want to add the ending.

I totally agree, that adding more and more recipes and technologies with the same principles is not bringing much more additional fun to the game, that is why we should add new concepts if we want to extend the game.

I like how game transitions from factory building in early game to resource managment and logistics in late game. I think sine everyone likes trains, it would be good if resourses patches got bigger on large distances from base + resourses demands for space ship would be ennormous (10 outposts?). This way the game would naturally transit from base building to outpost and railway network building. On top of that it would be good if some creep bosses would be naturally attracted to such bit resource deposits, that would require some skill to kill.

[ostrichbean]

Please don't spend too much time trying to make the save files smaller because the difference between 60 or 120MB makes little difference to players. I wouldn't even care if it was 2GB: HDD space is cheap.

Also, I love the game and you are awesome!

[Garm]

Save file makes a lot of difference for multiplayer.

[zbeeblebrox]

Don't forget, that the game can't be infinite, that is why we want to add the ending.

I totally agree, that adding more and more recipes and technologies with the same principles is not bringing much more additional fun to the game, that is why we should add new concepts if we want to extend the game.

I like how game transitions from factory building in early game to resource managment and logistics in late game. I think sine everyone likes trains, it would be good if resourses patches got bigger on large distances from base + resourses demands for space ship would be ennormous (10 outposts?). This way the game would naturally transit from base building to outpost and railway network building. On top of that it would be good if some creep bosses would be naturally attracted to such bit resource deposits, that would require some skill to kill.

To piggyback off this, it would be really cool if maps generated better and rarer resources the further away from spawn you go. And perhaps the mk1 rocket you first make can't actually leave the planet, but lets you fast-travel say several km in a cardinal direction to set up outposts in exotically populated areas that only begin generating at great distances (and which are totally infested with aliens of course) - including precious metals to be used in creating useless trinkets whose only purpose is to be sold for ridiculous profit ;P

[Nova]

Please don't spend too much time trying to make the save files smaller because the difference between 60 or 120MB makes little difference to players. I wouldn't even care if it was 2GB: HDD space is cheap.

Also, I love the game and you are awesome!

And there's a big difference between 8 GB and 4 GB. (If you consider 70 save files with either 120 MB or 60 MB. Yes, 70 save files is not uncommon.)


Oh, and there are SSDs, which are much more expensive for the same space.

[mngrif]

Please don't spend too much time trying to make the save files smaller because the difference between 60 or 120MB makes little difference to players. I wouldn't even care if it was 2GB: HDD space is cheap.

Also, I love the game and you are awesome!

It has less to do with space and more to do with the time it takes to generate the save and flush it to disk. It's all about speed.

I like how this thread is quickly becoming the largest reply thread on a Friday Facts. I'm super excited about these changes, as it gives me something fantastic to look forward to in the coming months. As always, thank you for your hard work.