Friday Facts #189 - Specifying the 1.0

[vanatteveldt]

It would be great to have a slot in roboports or another chest to be able to just release robots into the wild, and a way to call 1 logistics and 1 construction (or a configurable amount) to always land at a roboport and that these robots would still be counted as being active robots in the network.

Right now inserting robots into the roboports blocks when inserting large number of robots, especially construction robots, because if they are never needed, then they will block the roboport and you can't automatically insert more.

It would be great to be able to keep an exact amount of robots in a network. Add more when the number falls below (eg destroyed or picked up accidentally by players) and remove them when extra get in the network (eg. players just release extra ones).

The current mechanism usually blocks. No matter how many roboports you configure to insert and remove robots, the above two issues will always prevent it from working in all cases and there is no solution to this in the base game. Ie. you can't be cleaver and design some circuit system to do this because the bottleneck will always be a roboport as it's the only way to remove active robots and it's also the only way to add active robots. Unfortunately as metntioned, these roboports suffer from the 2 issues:
1) they can fill up with robots easily and not allow more to be inserted (eg filling up with construction robots because they are not needed), thus preventing adding more construction or logistics robots to the network indefinitely
2) there is no guarantee of a logistics or consturction robot landing at the desired roboports to be removed if the robots go past a certain number

What you need is a mechanism to tell the roboport to send robots away, or call robots to it.

What about a simpler solution: just have requester chests remove the bots from the current pool, and provider chests add them to the pool? (i.e. make bots in logistic chests work the same as in roboports). You can't treat bots as cargo anymore in the logistic system, but there's no real difference between a bot being ferried from provider to requester by another bot and the bot just flying there by itself. It does make it difficult to request bots, e.g. for transportation from the robot factory, without depleting the normal "worker" network at that factory, but that can be solved with smart circuitry.

[mathturtle]

I agree with many of the people above. The mining drill feels ok for blue science since it is about the same (in non-expensive recipes mode) as the assembler. But the assembly machine 1 in purple science feels wrong. It is too much an early game item to fit here (even if it made the switch-over easy since I already had them automated). Even if it was expensive, the pumpjack felt right here in terms of progression.

But if you are going to change it, I think you should take this as an opportunity to balance the iron/copper ratio for science back out. Pick something really copper-heavy so that the ratio swings back toward balanced consumption. Of all the suggestions I have read and heard the one I like best is productivity module 1s. It fits the theme of the science pack (production) and is copper-heavy so the iron/copper ratio gets better. It also removes an iron-heavy item which further balances the ratio. But between mining drills and engines and electric furnaces there are still plenty of iron-heavy items going into science.

I mostly don't care about the belt lengths, although the increased cost made me have to redesign my build to get blue belt made in a reasonable amount of time... blue undergrounds are really expensive now. I'll use it where I need the length if I'm making a more spaghetti-like build and ignore it otherwise.

[FasterJump]

Some thoughts about the new changes:

1) Underground belts length:
I think the 4-wide main bus will still be the most used bus type because:
- You build the bus early when you have access only to yellow belts
- 6 lanes or 8 lanes bus doesn't save a lot of space, and gives less flexibility
Anyway, I won't often use that 5/7/9 bonus in my bases, the bonus length won't help often. I'm more affected by the increased cost.
I'm neutral about 5/7/9 or 5/8/11.

2) New recipes costs:
-Blue science is more expensive now, is it intended? (btw i don't automate mining drills in default world options)
-For purple science, T2 assemblers could fit I suppose. [Edit: productivity I modules are also a good option]

3) Metal balance
Please consider rebalancing Iron vs Copper in either recipes or in map deposits.
Total cost of 1 of each science pack: this reddit post can give an idea of end-game costs. If the math is correct, at the moment there is 130 iron used for 60.3 copper (more than the double)
[Edit:] If that helps, after launching 9 satellites, my ingame "All" production statistics are 4.9M iron ore and 3.1M copper ore consumed. Yet at least 0.95M iron ore and 1.36M copper ore were spent in modules, the remaining total is 3.95M iron ore and 1.74M copper ore.

[AndrewIRL]

Pick something really copper-heavy so that the ratio swings back toward balanced consumption. Of all the suggestions I have read and heard the one I like best is productivity module 1s.

Yes copper and modules but why productivity? Speed and efficiency are both needed for power armor so either would be better than productivity.

Or, crazy idea, in a complete departure from every other recipe - make blue science accept ANY module 1.

[wwdragon]

Car, Tank and Train not listing their resistances anymore.

So how do we see what those resistances are?

[equitime77]

I like most of the changes to science, I think they still need work on tho. Can you include something in science that uses stone? There is very little use for stone in vanilla. Also, steel needs looking at, it feels far too slow and needs to be used more, ie steel gears instead of masses of iron gears could be a good thing?

[Nova]

Yes copper and modules but why productivity? Speed and efficiency are both needed for power armor so either would be better than productivity.

Because of exactly that. I would prefer if every module had to be automated.

[Albrat]

I admit now.. I have not read the entire thread.

I like the idea of the extended belt distances as you research higher levels of underground belts. (you probably know how many times we have placed the factory and then found a belt is 1 block short of passing under an inserter, assembly machine and inserter on the other side.)

The Science packs. I have played almost solidly since the release on 0.15.0 (not even done the patch updates.) The science packs are great. But I struggled to make the blue science, completely failed in making the purple ones at a decent rate and the yellow ones I produce at double the rate of the blue ones. (the yellow ones are basically the same as the old blue ones. my factory was already producing everything to make those by the time I got to blue science.)

Basically the science packs taking production items is great, but like mentioned in the friday facts... They need tweaking. I definately automated things differently that the order of what the science packs required. (untill I get flying robots and construction by blueprints... ) I do not really automate things beyond belts, ammo and inserters. I avoid making too much smelting untill I have the electric furnaces as well, the reason for this is that the entire smelting process changes at the point you hit electric furnaces. (size difference causes a total re-laying of all your smelting.)

The pumpjacks are always crafted in hand, never needed enough of them to warrant a production line before the research requirement of them. (what would be better is if all assembler speeds were faster than hand crafted speeds. even the basic ones.)

As for game modes and other options, maybe a default "no hand crafting" game mode / scenarion map! for those wanting a serious challenge. (you start with a factory, furnace and 4 miners. craft everything in your factory building. no hand mining except trees.)

[bripi]

While I am here, let me say that the upgrades to the visuals is terrific, and I love the way the ores now "pop". I've been playing for only two years so I still consider myself "new", but this seems to me to be a simple idea: why do we have to press ALT? Why wouldn't the default be that we would see what each machine was making? That seems to make sense. True, pressing this one key once is no great burden, but why should we have to press it at all? Every video, every image, everything I've seen on the interweb has the ALT feature already on, and I would assume people would just play it that way. When the "big 1.0" comes out, that seems like something that should be included. In fact, it should be the other way around - toggle the display OFF if you want, but the default should be ON.

[_Peter_]

Hi,

A quick comment about the blueprint based gameplay - I think random is an essential part of Factorio.

jon

I would love to see the blueprint based gameplay - maybe both for given fixed maps and for random maps - it would also be cool to compete like in the production challenge in two "parallel" maps of same layout with that setting.

[vanatteveldt]

I've played quite a bit of .15 now and in general really like the changes. I agree with most of the community that assembler 1 feels out of place for production, ass2 might be a better choice even though it's more expensive.

I really like how easy it is to create and share blueprints. I absolutely love the zoom to ground feature in the map, it allows you to inspect situations much quicker and I especially love making blueprints from the map view. I've so often walked all the way to a remote part of the base just to blueprint a particular setup. It is also a good reward for covering the whole base with radars.

What I think needs some tweaks is the interaction between blueprint and inventory. In the current setup, I get blueprints from my "B" library all the time and they end up cluttering my inventory, making me delete them one by one. I would prefer if blueprints are never part of your inventory: just grab them from the "B" screen, use them, and they go back to the library. Maybe make three divisions in the library (personal game blueprints (=default for new prints), shared game blueprints, and personal library).

[Albrat]

It would be great to have a slot in roboports or another chest to be able to just release robots into the wild, and a way to call 1 logistics and 1 construction (or a configurable amount) to always land at a roboport and that these robots would still be counted as being active robots in the network.

Right now inserting robots into the roboports blocks when inserting large number of robots, especially construction robots, because if they are never needed, then they will block the roboport and you can't automatically insert more.

It would be great to be able to keep an exact amount of robots in a network. Add more when the number falls below (eg destroyed or picked up accidentally by players) and remove them when extra get in the network (eg. players just release extra ones).

The current mechanism usually blocks. No matter how many roboports you configure to insert and remove robots, the above two issues will always prevent it from working in all cases and there is no solution to this in the base game. Ie. you can't be cleaver and design some circuit system to do this because the bottleneck will always be a roboport as it's the only way to remove active robots and it's also the only way to add active robots. Unfortunately as metntioned, these roboports suffer from the 2 issues:
1) they can fill up with robots easily and not allow more to be inserted (eg filling up with construction robots because they are not needed), thus preventing adding more construction or logistics robots to the network indefinitely
2) there is no guarantee of a logistics or consturction robot landing at the desired roboports to be removed if the robots go past a certain number

I have a circuit system with two roboports next to each other, One inserter only inserting logistics bots when in use bots are over 60% of available bots. So my system will scale larger by demands.
Same exact setup on the other roboport, but with construction bots. This way the roboport will never be blocked and if the system needs more robots they will be requested away from the roboport / make space for more insertions.

I see absolutely no reason to remove bots from active duty, it is the same as bots just sitting in the port. Though saying this I would like to be abled to specify a minimum number of bots per roboport! eg. Each port should hold 16 logistics and 8 construction bots minimum, requesting a bot be delivered if below the minimum. (I have seen empty ports in busy areas and bots sat in non-busy ports before. - Maybe a distribution system, even the bots between all ports in the system ? )

[Aeternus]

Yea, a Steel Pipe version with a longer reach wouldn't be a bad idea. If at all possible, a higher max flow rate on them wouldn't be a bad idea either - just not sure if it is possible since the flow characteristics of a fluid seem defined in the fluid type, not in the transfer medium. Maybe if the pipe's internal capacity would be boosted from 100 to 200, it'd double the flow rate? Worth an experiment...

[Edit] Was a reply on a few posts ago asking for a longer pipe >.<

[justincuster]

I love the idea of an artillery train. Very cool. One thing that I would absolutely love would be a flat car with mounted turrets front and aft. Something like this: https://s-media-cache-ak0.pinimg.com/73 ... 70b40b.jpg .

[quinor]

I'd love to see quickstart with robots (basically what you've written; personal roboport + armor + fusion reactor + 50 robots) in the core game - not for "special gameplay mode" but rather normal start. After enough time you get tired of building everything by hand in the early game.

[factoriouzr]

It would be great to have a slot in roboports or another chest to be able to just release robots into the wild, and a way to call 1 logistics and 1 construction (or a configurable amount) to always land at a roboport and that these robots would still be counted as being active robots in the network.

Right now inserting robots into the roboports blocks when inserting large number of robots, especially construction robots, because if they are never needed, then they will block the roboport and you can't automatically insert more.

It would be great to be able to keep an exact amount of robots in a network. Add more when the number falls below (eg destroyed or picked up accidentally by players) and remove them when extra get in the network (eg. players just release extra ones).

The current mechanism usually blocks. No matter how many roboports you configure to insert and remove robots, the above two issues will always prevent it from working in all cases and there is no solution to this in the base game. Ie. you can't be cleaver and design some circuit system to do this because the bottleneck will always be a roboport as it's the only way to remove active robots and it's also the only way to add active robots. Unfortunately as metntioned, these roboports suffer from the 2 issues:
1) they can fill up with robots easily and not allow more to be inserted (eg filling up with construction robots because they are not needed), thus preventing adding more construction or logistics robots to the network indefinitely
2) there is no guarantee of a logistics or consturction robot landing at the desired roboports to be removed if the robots go past a certain number

I have a circuit system with two roboports next to each other, One inserter only inserting logistics bots when in use bots are over 60% of available bots. So my system will scale larger by demands.
Same exact setup on the other roboport, but with construction bots. This way the roboport will never be blocked and if the system needs more robots they will be requested away from the roboport / make space for more insertions.

I see absolutely no reason to remove bots from active duty, it is the same as bots just sitting in the port. Though saying this I would like to be abled to specify a minimum number of bots per roboport! eg. Each port should hold 16 logistics and 8 construction bots minimum, requesting a bot be delivered if below the minimum. (I have seen empty ports in busy areas and bots sat in non-busy ports before. - Maybe a distribution system, even the bots between all ports in the system ? )

In your system the bots would still clog. You can't guarantee they won't in all cases. Your condition is 60% used, so you could have the other 40% sitting in that exact roboport you are trying to insert more into.

I also don't play the way you play. I don't want to increase bots without bounds when 60% or more are in use. I want to set a fixed number of bots and make sure there are always that many in the network. If extra get released by players then I want to remove them. I want to increase the bots only when I feel my production is adequate or I need more bots (my decision based on various factors). If I do a large tree deconstruction and it uses all 3000 of my bots for 5-30 seconds, I don't want to pump in another 200 or whaterver just for the 30 seconds of overuse once in a blue moon.

[Avezo]

I think mining drill for science actually costs too much iron aswell (even if it makes sense to automate it in early game). It's 10 iron plates per second assuming constant production (including gears), which is almost full yellow belt - that's a huge amount of iron in early game when you set up this science production.

[webkilla]

Yea, a Steel Pipe version with a longer reach wouldn't be a bad idea. If at all possible, a higher max flow rate on them wouldn't be a bad idea either - just not sure if it is possible since the flow characteristics of a fluid seem defined in the fluid type, not in the transfer medium. Maybe if the pipe's internal capacity would be boosted from 100 to 200, it'd double the flow rate? Worth an experiment...

[Edit] Was a reply on a few posts ago asking for a longer pipe >.<

this

a "pipe-line pipe" could be nice

though, with the new tanker wagons for the train then that might not be nearly as necesary?

[Pyrii]

I feel like the recipe change for belts to compensate for the longer lengths was a bit blunt and not very well thought out, you've essentially doubled the iron gear cost of an essential mid/late game item. I felt like a little more thought could have been put into that.

Keep up with the bug hunt though, you'll get there eventually

[doppelEben]

Hi,

A quick comment about the blueprint based gameplay - I think random is an essential part of Factorio.

jon

I agree - a whole game mode locked to one map forever seems like a lost opportunity to make such a cool idea even cooler. Maybe there could be a default seed that everyone uses most easily, but let people adjust the seed optionally so they can see how their strategy adapts to unknown locations.

Otherwise it could be a great chance to implement the weekly or monthly race-challenge.

The default-seed of this gamemode could change every week, or every month, and the results from ppl played this mode, with this seed, in vanilla get ranked on a list viewable on the factorio.com page

win-condition could be severall different things...
- get as fast as u can an 1 km long rail-circle
- produce 200k blue chips / h
- get a rocket in space
- destroy N biters
- travel to a point X which is N km away from center (inbeetween much biters, much water etc.)
- beat the clock

unlimited possibilities