- 'cause it's very likely that you will next use this blueprint, and with the same orientation of the origin.

I'd still favour this concept - you should also need food to survive the whole time, and reducing pollution should be another goal. Medkits instead of the fish and a less instant health regeneration would be more realistic too. But I understand that the team doesn't want now to build factorio from t...

It makes the overview much uglier and the game not better. How should it make the overview uglier ??? You've got/see ONE chest instead of four in the inventory/recipe list and you can't accidently craft the wrong type. In the landscape, a requester chest would still be blue, 'cause it's still the s...

Deadly-Bagel wrote:For that I usually have circuit wait conditions so that the train leaves when the buffer chests are empty.

Likewise when my unloading buffer chests are not empty I have my oil train hang at the station, no point in it running around while it's full.

Seems as if you don't play factorio 0.13 ? O.o

The point(e) is, that you don't have a very satisfying solution for trains, in principle it's just better to use robots for everything and globally - and transportation belts instead of trains. Of course you're using normally extra chests resp. inserters. But this decreases the loading speed. The di...

Should be implemented. It doesn't disturb modders either. They are more tortured by loading the game when they are starting and quitting factorio again and again.

should be also 1 and 2 seconds, especially for the "time of inactivity".

At least when dealing with a cargo wagon, filter inserters should take the item of their filter list, that has the lowest count in the destination container, so that they are balancing loading and unloading. There is no way yet to load/unload with maximum speed that won't end up in clogging every ch...

Instead of the provider chests, storage chest and requester chest, there should be only one item: "logistic chest" for instance. When interacting, you should be able to change/choose its operation mode. Default might be passive provider chest. Internally you still may use the old entities,...

- No workers. This would require an additional AI - that would be useless. "Walls" could emerge in some distance of the strongholds - at the edge of the mentioned slime (which could be also just a logical(invisible) tile, but it is very handy to get the wall just around a base and not stup...

Maybe you can make the output window in windowed mode without "decorations"... (this could just be done from the application itself) Normally fullscreen mode is much better - higher graphic performance mainly. The only reason to use the windowed mode are issues like program crashes just oc...

The right behaviour would be that if you increase your requests over the trash limit, the trash limit should be automatically increased to the same value, if set. If you set the trash limit below your request amount, the request amount should be set to the same value resp. removed if 0.

the entity concept should be changed to a flag-based system - and all entity-types should have prototypes. I.e. you should be able to easily add e.g. electricity consumption to any new or existing entity without writing an OnTick() subroutine. Flags are something like: consumesElectricity, hasInput...

Steam locomotives require much water... But I'm not very favouring this... Better would be tank wagons and bulk cargo wagons with special, fast loading/unloading buildings. - The one might be used to fuel locomotives with light oil... Perhaps a new goal of factorio might become further to switch to...

Like it. Could be done with evoluting spawners; higher evolved spawners get a turtle shell... There might grow spikes acting like walls and slowly spreading slime creating a kind of "alien concrete"... A trigger could simply be copper ore or crude oil deposits - those are poisonous in real...

Adil wrote:Would be nice. Would require ground up rewrite.

Going in a similar direction... But all to do would be "just" to exchange everywhere e.g. "if (type="electric-pole")" with "if (distributesElectricity())". Never underestimate such changes of course.

the entity concept should be changed to a flag-based system - and all entity-types should have prototypes. I.e. you should be able to easily add e.g. electricity consumption to any new or existing entity without writing an OnTick() subroutine. Flags are something like: consumesElectricity, hasInputI...

Well, robots are a bit OP, but it's rather useful if you could make "rebuilding" and "copying" this way a bit easier. 'course it would be also fine to mark trees to chop and get close for, instead of chopping them nearly by hand.

Researches should be a bit queueable, i.e. you should be able to demand at least the next research after the current - no need to queue more than 4 technologies though. Would be also nice if you automatically queue the required technologies first for that you put on the list like when crafting...

The player should place buildings like construction robots if in range and available. Mainly to use the blueprint's mechanic before you've got mobile roboports and so on. Blueprinting shouldn't be researched though.