Factorio Forums

hoho wrote:

Neemys wrote:Every CPU time used by decoration generation will be less CPU time for other thing, think about megabase, maybe a quarter second is nothing for a little base, but for those megabase where CPU is already a bottleneck, it's not wise to add more generation.

True. It's the good-old question of CPU vs memory.

I wonder if adding the option to completely remove decorations from map (both generation and rendering) would be considered as a too radical feature.

They will reduce the size in memory for those decoration, it should be enough I think

FalcoGer wrote:Also what's wrong with the title? It's just weird.

The title is an analogy. Humans can physically digest paper, but it's pointless, since we get no nutrition from it.
Likewise, the devs are able to spend lots of time optimizing for more and more players, but it's superfluous for what is fundamentally a single-player game.

Personally I have so far played with a maximum of three players at once, and I don't foresee myself doing much more than that, although clearly not everyone shares my playstyle.
The massively multiplayer video that Arumba did was hilarious, though.

Could you create each ground clutter patch as a whole entity, where one or more patches can exist on a chunk, and cross chunks like buildings. Then you just save a random seed for that entity? Then when you render the entities, if you don't have the sprite in memory for it, you generate it on the fly (using it's own code rather than chunk generation code). If ground clutter entities go a number of ticks without being rendered, their sprite is removed from memory. Chunk generation can be set to add a few entities per chunk of variable size, but they cover more space.

Considering the amount of processing that belts and inverters have to do searching, and many other far more time consuming things, I can't imagine that it would even be a noticeable impact on CPU. Given the number of trees on the map, it should take less storage space than that.

The devs have shown they are quite capable of extreme optimisation, I'm sure they know what they're doing.

Neemys wrote:They will reduce the size in memory for those decoration, it should be enough I think

Personally I would like to see an option to switch off decorations at Map generation level.

Those of us who favour playing large maps with widely spaced resources and heavy use of train systems, or those interested in building mega factories would welcome this, I'm sure.

I don't think we should be having to use the Undecorate mod to make our big maps playable on our PCs.

When all is said and done decorations are merely eye candy.

But they do keep the game feeling more natural and immersive. Imagine if you started a map and there was nothing but concrete everywhere, it wouldn't be quite as nice.

Deadly-Bagel wrote:But they do keep the game feeling more natural and immersive. Imagine if you started a map and there was nothing but concrete everywhere, it wouldn't be quite as nice.

Well being as most oif us ending up concreting it all anyway - that would save a lot of time

Am I the only one who thinks those huge concrete areas look really ugly? Why do you do that?

Concrete makes walking 40% faster, when you combine that with the bonus from exoskeletons it makes traversing a large factory much faster.

And concreting your base is one thing, a concrete world is another.

Zeblote wrote:Am I the only one who thinks those huge concrete areas look really ugly? Why do you do that?

Also the concrete tiles help in placement of assemblers as you can see the grid.

Very helpful when placing 100 smelter blueprints in an exact line.

BTW my previous comment was made with tongue firmly in cheek

Thank you for all the FFFs, As another said, they are a highlight in the week, and I always visit, even if I haven't played for a while.

Thank you for being so transparent, and taking in user feedback. I think you got the great review on steam because you listen to gamers, underpromise, and overdeliver; unlike other games that to little playtesting, don't get feedback, overpromise, and underdeliver.

Thank you for optimizing. It makes a huge difference on my 7 year old laptop (that currently has a small collection of CPU and mobo heat sinks on top). I've never had any performance issues, and only a couple bugs crashes this whole time. I have many simple games in my library that seem like they should be low resource, but yet perform very badly.

Decorations idea:
What if you add them at the new game screen, so you edit them to be few/normal/lots (perhaps also none?) in the same way you set the parameters for coal, iron, copper, etc. And/or what if in the graphics options you can just turn the decorations off, like clouds and smoke? Perhaps the game can still keep the type and location in the save file (for if you turn them back on), but if decorations are turned off, the game won't load them to CPU/RAM/Video card?

Thanks again!

They would be a special type of an object that is not saved in the map, but generated on the fly when the player walks around. They would be saved per chunk in a very compressed format so it only takes 3 bytes of memory per decorative...

Out of curiosity, what data would those 3 bytes contain?

Scourge wrote:

They would be a special type of an object that is not saved in the map, but generated on the fly when the player walks around. They would be saved per chunk in a very compressed format so it only takes 3 bytes of memory per decorative...

Out of curiosity, what data would those 3 bytes contain?

We changed to 4 bytes:
x (1 byte, 5 bits for tile, 3 bits for the rest)
y (1 byte)
decorative id (1 byte)
count (1 byte)

With the count added, we could save small chunks (I estimate 5-10) of decoratives as one.

Thank you very much!

All an all, it's really looking great. I'm excited for liquid tank cars because we all know from experience how awkward it is to ship barrels instead.

I really like the design of the pump system as shown in the fff but the one thing that seems a little bit awkward to me is the way that the flexible tubing that passes through the joint is positioned. It almost seems to bend (particularly the bottom bend) at 90 degrees and then again at 90 degrees at the top, despite there not being a reason for them to bend like that (say, if the tubing was physically attached to the arm at that point).

The second image already indicates that the tubing is both stretchable and collapsible, so I think that it would make more sense if these corner bits were more subtly curved instead, especially since, if these things are going to be pumping high volumes of fluids, the pipes themselves would become very rigid and resistant to kinking at 90 degrees like that. Think about a fire hose and how they react under high PSI (like you'd have with a pump!)

Coincidentally I also found this while I was double-checking to make sure I was stating things correctly and it talks a fairly decent amount about the effects of angles and kinks in piping. http://www.fireengineering.com/articles ... ystem.html

I know it's semantics but it's a little thing that stood out to me upon second glance.

Yes, it would look more natural if the pipe was to make more or less a straight line towards the nozzle.

Also do we have any more of an ETA on 0.15? Not looking for anything solid, last I read (somewhere, can't find it again) you guys were thinking November I think.

Why 3 standing tanks that need to be filled separately?
Most railways in Europe and US use a single horizontal tank for a reason. It's easier to manufacture, offers most volume for it's size, since tanks have a slight bent they can be emptied by simply opening a valve at the bottom.

Cause to have 3 different liquids in it?

That would require 3 different loading pumps instead of one that moves between all 3 tanks as the images suggest.

You might have a deeper look at the orig image. I understand it so, that you can connect up to 6 pumps, 3 per side. And the pump uses that animation that fits to the tank position.