Friday Facts #189 - Specifying the 1.0

Regular reports on Factorio development.
vanatteveldt
Filter Inserter
Filter Inserter
Posts: 923
Joined: Wed Nov 25, 2015 11:44 am
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by vanatteveldt » Sun May 07, 2017 10:53 am

AcolyteOfRocket wrote:
factoriouzr wrote: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
Inserter
Inserter
Posts: 40
Joined: Sat Jan 21, 2017 8:19 pm
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by mathturtle » Sun May 07, 2017 11:38 am

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
Fast Inserter
Fast Inserter
Posts: 122
Joined: Sat Jul 09, 2016 11:43 am
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by FasterJump » Sun May 07, 2017 12:53 pm

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.
Last edited by FasterJump on Mon May 08, 2017 12:29 am, edited 3 times in total.

AndrewIRL
Fast Inserter
Fast Inserter
Posts: 218
Joined: Fri Mar 24, 2017 2:17 pm
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by AndrewIRL » Sun May 07, 2017 3:01 pm

mathturtle wrote: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
Long Handed Inserter
Long Handed Inserter
Posts: 91
Joined: Sun Jun 28, 2015 12:16 am
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by wwdragon » Sun May 07, 2017 4:10 pm

Car, Tank and Train not listing their resistances anymore.

So how do we see what those resistances are?

equitime77
Long Handed Inserter
Long Handed Inserter
Posts: 54
Joined: Mon Mar 28, 2016 11:07 am
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by equitime77 » Sun May 07, 2017 7:09 pm

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?

User avatar
Nova
Filter Inserter
Filter Inserter
Posts: 942
Joined: Mon Mar 04, 2013 12:13 am
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by Nova » Sun May 07, 2017 9:18 pm

AndrewIRL wrote: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.
Greetings, Nova.
Factorio is one of the greatest games I ever played, with one of the best developers I ever heard of. Image

Albrat
Inserter
Inserter
Posts: 34
Joined: Tue Feb 17, 2015 2:35 pm
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by Albrat » Sun May 07, 2017 9:57 pm

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
Inserter
Inserter
Posts: 29
Joined: Sat Jul 02, 2016 3:15 pm
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by bripi » Mon May 08, 2017 1:28 am

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_
Inserter
Inserter
Posts: 23
Joined: Wed Aug 17, 2016 7:50 pm
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by _Peter_ » Mon May 08, 2017 5:13 am

hyspeed wrote: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
Filter Inserter
Filter Inserter
Posts: 923
Joined: Wed Nov 25, 2015 11:44 am
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by vanatteveldt » Mon May 08, 2017 7:29 am

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
Inserter
Inserter
Posts: 34
Joined: Tue Feb 17, 2015 2:35 pm
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by Albrat » Mon May 08, 2017 7:49 am

factoriouzr wrote: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
Filter Inserter
Filter Inserter
Posts: 834
Joined: Wed Mar 29, 2017 2:10 am
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by Aeternus » Mon May 08, 2017 7:56 am

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
Inserter
Inserter
Posts: 21
Joined: Sun Apr 30, 2017 11:13 am
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by justincuster » Mon May 08, 2017 10:17 am

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 .
- Justin -

quinor
Filter Inserter
Filter Inserter
Posts: 391
Joined: Thu Mar 07, 2013 3:07 pm
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by quinor » Mon May 08, 2017 12:03 pm

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
Filter Inserter
Filter Inserter
Posts: 632
Joined: Sat Jun 06, 2015 2:23 am
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by factoriouzr » Mon May 08, 2017 12:09 pm

Albrat wrote:
factoriouzr wrote: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
Filter Inserter
Filter Inserter
Posts: 450
Joined: Fri Apr 01, 2016 3:53 pm
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by Avezo » Mon May 08, 2017 1:55 pm

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
Inserter
Inserter
Posts: 43
Joined: Sun May 11, 2014 4:17 pm
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by webkilla » Mon May 08, 2017 2:26 pm

Aeternus wrote: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?

User avatar
Pyrii
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sat Jul 02, 2016 5:21 pm
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by Pyrii » Mon May 08, 2017 2:39 pm

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
Long Handed Inserter
Long Handed Inserter
Posts: 95
Joined: Thu Oct 27, 2016 6:21 am
Contact:

Re: Friday Facts #189 - Specifying the 1.0

Post by doppelEben » Mon May 08, 2017 8:30 pm

LuxSublima wrote:
hyspeed wrote: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

Post Reply

Return to “News”

Who is online

Users browsing this forum: No registered users