Friday Facts #189 - Specifying the 1.0

[MeduSalem]

[...] I honestly feel like someone is pushing the 1.0 just to get it out of the door and forget about everything.

But that is exactly what 1.0 is about. Putting an end to the otherwise endless feature creep, fix/balance what is already there and call it a day.

And that's what they have been trying to do for the past 2 years already and everytime they thought that they were a step closer something else got in the way and development has been dragged out because of it.

I understand that they want to keep a deadline for once... and they also earned their break too because the game is quite awesome already the way it is.

But from what has been said they plan on continuing to support Factorio even after 1.0 anyways... maybe with Addons/DLCs or whatever.

[Avezo]

Iron gearwheels requirements in later recipes are insane! 40 gearwheels per second is full blue belt with 4 fully upgraded stack inserters needed! Really please consider introducing STEEL gearwheels in later recipes, only to reduce sheer amount of 0.5s craft items required, even if raw iron ore costs stays the same.

[vanatteveldt]

Iron gearwheels requirements in later recipes are insane! 40 gearwheels per second is full blue belt with 4 fully upgraded stack inserters needed! Really please consider introducing STEEL gearwheels in later recipes, only to reduce sheer amount of 0.5s craft items required, even if raw iron ore costs stays the same.

This is actually a good idea, although the throughout is an interesting change as well

[GyroByte]

[...] I honestly feel like someone is pushing the 1.0 just to get it out of the door and forget about everything.

But that is exactly what 1.0 is about. Putting an end to the otherwise endless feature creep, fix/balance what is already there and call it a day.

And that's what they have been trying to do for the past 2 years already and everytime they thought that they were a step closer something else got in the way and development has been dragged out because of it.

I understand that they want to keep a deadline for once... and they also earned their break too because the game is quite awesome already the way it is.

But from what has been said they plan on continuing to support Factorio even after 1.0 anyways... maybe with Addons/DLCs or whatever.

I didn't say that they have to do it now. I just don't want to see the idea thrown away.

[Engimage]

I have been so happy all this time enjoying Factorio.

But today you have said two really sad things.
First - you have deleted all cards for new features. This is a really sad story. I hope you gonna implement stationary artillery as well as artillery train then at least.

And it would not really be that sad if you did not say you have to exact plans for post 1.0
I have yet to meet such an awesome dev team. And I really hope that you remain and continue your Factorio work further be it DLC or Factorio 2.0.

And if you do still have plans on extending Factorio further I can definitely say I do support your decision to stop adding new features to 1.0 as it already feels like a pretty solid product. Ofcourse you gotta introduce a nice introductory campaign or two and make some balancing around.

[jjconroy]

Make the Uranium-235 production similar to how productivity modules function. Such as for every 1000(?) uranium ore you get 1 Uranium-235 and 1000 Uranium-238. To me it feels like the randomness of the centrifuge does not fit in with the rest of the game.

[Artman40]

Iron gearwheels requirements in later recipes are insane! 40 gearwheels per second is full blue belt with 4 fully upgraded stack inserters needed! Really please consider introducing STEEL gearwheels in later recipes, only to reduce sheer amount of 0.5s craft items required, even if raw iron ore costs stays the same.

I don't know. I actually like how a few recipes require a lot of components to make but crafting speed is small. That's one way to make uses of stack inserters when other recipes would require only fast inserters.

[factoriouzr]

How can I flag a station as a supply stop if it's missing resources based on filter inserters connected to the logistics network at the outpost. I have the inserters unloading from the train to passive providers if a quantity of an item is less then a value I set on the inserter. Can I reuse this limit? I would hate to have to redefine the limits again.

Also is there a way to set a constant combinator for eg. to how many of each good I want and have the train stop enabled based on that, and also have the filter inserters respect those amounts too? Ie. right now I have 2 stack filter inserters unloading 12 unique items into 12 passive providers per wagon. Is there an easier way to do this that's less configuring and micro managing?

I think the best way would be to have 12 deciders around a roboport that are linked in to it, and if any one of the deciders reads less than that quantity, it outputs some signal, and then the stop would be connected and set to enabled if there is at least 1 instance of that signal, so that any one of them would trigger it. That would be a little bit of work to set up, but you could save the whole thing as a blueprint to be reused. You could set a constant combinator that outputs a signal that all 12 deciders compare against for an easily changeable limit. You can also wire that same signal over to the inserters as well, would take a decent amount of wiring, but as before you can blueprint it as well. As for the unique items, that probably is the best way (to have 12 inserters), unless they implement item filters for chests.

There is an issue even with the base implementation of this. If I set up two train stops as you describe, now the train is on it's way to my station and the condition changes and the stop becomes disabled, the train immediately stops and tries to go back to the first stop. The issue is that it might stop on a one way track or in an intersection. When it's not double headed, it won't find a path. I have to try this, but I might be able to get this to work if I add a roundabout somewhere in my rail network. Haven't built the network yet under 0.15 game.

Ah, hadn't run into that yet, guess my network isn't big enough, not sure if there is a good way around that one, other than just making sure there is plenty of space for trains to turn around and get back on the right track by going forward.

I just ran into an issue with the disabling stops solution. If all the stops aside from the main loading stop are disabled and the train is waiting at the main loading station, when it tries to leave to go to another stop, it will keep flashing "no path" forever until the outpost requires something. It took me a while to figure out that there was nothing wrong with my train tacks and lights and it's just that all the stops are disabled.

This is really bad and annoying. The good thing is the train seems to work fine, but that constant no path flashing is really annoying. Is this a known bug, is there a way to do the conditions to avoid this?

[TroZ]

Can Roboports be modified to output the number of repair packs when they output the number of robots? I'd like to have an inserter only fill each roboport with 25 repair packs instead of wasting materials completely filling the inventory or each roboport.

[IronCartographer]

The expensive / death world science recipes were hit hard by the change (due to the higher gear/circuit content of miners vs. assemblers) and I'd definitely like to echo concern about that.

The belt distance changes are good as they are (people can either build a new base or plan to make 8-wide belt groups from the start; the four-width are an artifact of the old standard and this will inspire more creativity). However, express underground might be better at 70 gears instead of 80--source: this reddit comment.

Underground pipe being able to go underneath two reactors would be cool as mentioned by Rhamphoryncus.

For 0.16 AKA 1.0, artillery train + rocket turret mechanics would be an awesome combination.

Vehicle equipment suggestion: Radar module, so we can watch artillery trains without having radar coverage of the entire track, and have greater vision from our vehicles in general!

[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

[factoriouzr]

It would be great to have better attack reporting and tracking. A way to see the last 10 or so attacks and cycle through them would be good

[bobingabout]

I cant wait for the arty train.

Agreed. Very-very waiting for artillery trains!

I don't know what this artillery train you speak of is, when the grid system was added to vehicles in 0.14 I added a plasma artillery turret item that can be equipped on trains and tanks.

It's a shame that fluid wagons can't have a grid assigned.

[IronCartographer]

It would be great to have better attack reporting and tracking. A way to see the last 10 or so attacks and cycle through them would be good

That would be a good inclusion in the UI overhaul.


Had another thought about the science changes: I agree with people saying that the Assembler 2 would be better than the Assembler 1 for the Production packs, as Tier 1 is out of place by that point in the tech tree.

What if Assembler 2's were used, but the recipe produced 3 packs per craft instead of 2? It would be fitting for the Production pack to give the most, and allow greater flexibility on its specific recipe.

[Qrt_La55en]

I love the idea of a stable 1.0 build this year.

But the longer underground belts are not long enough. PLEASE make them like the mod, so it fits in the main bus.

[MeduSalem]

I didn't say that they have to do it now. I just don't want to see the idea thrown away.

Well I don't think that they are throwing away ideas. I think they just put them all in a pandora's box with a label on top that says "Don't open until 1.0 is finished".

[wwdragon]

New map is awsome.

On the downside, the tank based flamethrower kinda sucks.
It currently has only 9 range, while the handheld flamer has 15.
Given that it is vehicle mounted, it should have equal or even greater range, then the handheld version... just like the smg does.

It should also function the same as the handheld.

[Keyalha]

I never in my life automated mining drills its wasteful! And while blue had a gap I dont think choosing mining drills which are pretty much dead weight at that point are a good addition. At least the components before had a widespread use while minging drills at that point in the quantities you need em for research would be dead weight.

[vanatteveldt]

On the downside, the tank based flamethrower kinda sucks.
It currently has only 9 range, while the handheld flamer has 15.
Given that it is vehicle mounted, it should have equal or even greater range, then the handheld version... just like the smg does.

It should also function the same as the handheld.

See viewtopic.php?f=5&t=45409. Apparently, they didn't really intent for it to function as a flamethrower, more as a general AoE weapon.

(which is, indeed, a shame. Burning stuff rocks )

[AcolyteOfRocket]

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.