Simple Questions and Short Answers

[Silari]

Can I enable auto-sort inventory of spiders and other stuff?

Autosort is only available for a player's inventory. Here's a post explaining why: viewtopic.php?p=531122#p531122

It's possible they might add it to spidertrons but there aren't any plans to. There's a mod listed in that thread that can do it for spidertrons.

Highly unlikely to come to other inventories due to the calculation cost.

[eradicator]

Highly unlikely to come to other inventories due to the calculation cost.

There have been simple mods that sort any inventory the player opens. Imho a good compromise because the order doesn't really matter while no human is looking at it.

[Impatient]

Hey guys!

What would be the cause when the UPS drops to ~40 on fully zoomed out map view while it is steady at 60 in zoomed in map view and normal world view?

Too large map or too many chunks where something happens in or what exactly? Do I need to kill all the biters to up the UPS or am I at the hardware limit anyways?

Attached is a screeny from fully zoomed out map view.

Thanks!


Edit: I added screenies of the game stats @40UPS and @60UPS. Including them might be more helpful than just a map screenshot.

Fully zoomed out map ups drop.jpg (220.93 KiB) Viewed 7169 times

stats@60UPS

game stats at 60ups.jpg (322.49 KiB) Viewed 7167 times

stats@40UPS

game stats at 40ups-fully zoomed out.jpg (259.2 KiB) Viewed 7167 times

[wobbycarly]

I'm far from an expert at analysing those stats, but it looks to me like your electricity updates are larger than expected - are all those small networks independent? I believe separate electricity is bad for UPS.

But the main culprit appears to be the "Render Preparation", which makes sense when zooming far out on a huge base. Sorry, I don't have anything to help.

[BicycleEater]

I am also far from an expert, but my guess would be that Factorio attempts to render everything in the map view - normally not a problem, but here, since the map is so zoomed out, and there are so many entities, attempting to render everything involves either visiting every entity, or at least painting every tile in the whole map - which is way more than the number of pixels, resulting in the whole screen needing drawing several times over.
The visit every entity may explain the "Render preparation" being 12ms slower than normal.
The paint every pixel several times may explain the "Render" being 5.5ms slower than normal. The render may well be in parallel, so may not matter.
Just from the "Render preparation", you get a difference of 12ms per frame. Since in normal running the game spends 4.5ms sleeping normally, this explains the change from 16.6ms/frame (60fps) to 25ms/frame (40fps), as 25ms-16.6ms+4.5ms ~ 12 ms (as the sleep time is just the game doing nothing to make the frame rate work).

I don't know exactly why, but I would agree that the "Render preparation" is the culprit - and I don't think there is much you can do about that.
I would advise taking a backup of your game first (just in case), then try a couple of things:
Maybe kill loads of enemies and destroy loads of trees and see if it gets better... this might not work though, as it may only be re-rendering entities which are visible due to radars, so as a test, maybe destroy all your radars and see if it gets better (obviously then reverting to the backup, as radars are useful).

I don't know if either of those would help, but its the best I can come up with.

[mmmPI]

Same here, no expert, seeing the electricty network numbers as high as the entity update is a bit weird, as usually the electricity network require less time to be processed but the numbers being the same between the 2 screen that doesn't seem to be the cause of the slowdown.

The "update" part is roughly the same at 9 and 10 or so ms. So it doesn''t seem to be the factory itself, which makes sens right, as it doesn't change

the "render" and "render preparation" thingy , they go from 1.4 and 2.1 ms to 6.9 and 12.4ms. That's clearly what is taking more time to process each tick.

i'm not exactly sure how everything sums up and which are intermediate totals but frame cycle should stay under 16.6 ms if you want the 60 ups, at 25 ms needed to process a tick like in the second screenshot you have 40 ups.

So i too would say the cause of the ups dropping when zoomed out compared as when zoomed in, is the zoom since it increase the time needed to do the render.

[BicycleEater]

the "render" and "render preparation" thingy , they go from 1.4 and 2.1 ms to 6.9 and 12.4ms. That's clearly what is taking more time to process each tick.

The "Render Preparation" actually goes from 2.1ms to 14ms - about 12ms slower, which accounts for almost the entire tick difference on its own (taking into account sleep time).
I have some programming experience, so as a complete guess (based on what I might do), the "Render Preparation" is probably gathering the data needed to do the render. This is part of the normal "game loop" as it needs to be done at a point where all the entities are in a stable state (you couldn't do it in the middle of moving everything for example) so the game can't do anything else at the same time. This is normally very quick as it just gets all the entities on screen, and asks them what they are doing - and if there is any map which you can't see, it doesn't need to do anything for that area (as it can't affect what you see), other than load what was done before (this might be expensive depending on how it was done).

Then the "Render" is simply the graphics system drawing everything - this can be done in parallel, as it just involves pasting in any sprites which were loaded previously. This is also normally very quick, as it just needs to put a few pre-determined sprites (fixed images) in place, however it being slower won't make the game run any slower unless it takes long enough to intrude into the next tick, which hasn't happened here.

When you have the map zoomed out so much, it might have to visit every visible entity (at minimum every entity covered by radar) in order to work out what colour to paint it, and where it is. This isn't very efficient, and could be optimised easily (for example, most of these entities are either trees or buildings, which don't move or change at all between ticks, so could be left in place). I don't know if such optimisations are in the game, or how they might work, but it seems unlikely that this is very optimal, considering that the game slows down so much (these optimisations might also be somewhat subtle, as they need to notice when an entity dies or something dramatic happens).

If you look at the "sprite" count, when not in map view it is at 77, when in map view it is at 50004 - this is what I'm talking about. The game having to work out 50004 sprites every tick isn't going to help performance. This basically means that in map view it has to deal with 50000 individual entities every frame (on the basis that 1 sprite comes from 1 entity, which is probably true at that level of detail).

[eradicator]

I don't know if such optimisations are in the game

The map representation of each chunks is cached, there should be no "visiting of every entity every tick" - if there was that number would likely be orders of maginute larger than 50k. This can easily be seen when you kite a swarm of biters, outrun them and their red dots remain on any tiles not covered by radar until those chunks are rescanned.

[BicycleEater]

I don't know if such optimisations are in the game

The map representation of each chunks is cached, there should be no "visiting of every entity every tick" - if there was that number would likely be orders of maginute larger than 50k. This can easily be seen when you kite a swarm of biters, outrun them and their red dots remain on any tiles not covered by radar until those chunks are rescanned.

I knew that there was some caching (otherwise the game couldn't render the 'fog of war' areas, where you don't have any radar coverage - the question is whether the game does any caching for areas where you do have radar coverage - it is true that I would expect there to be more than 50k buildings etc.
Either way, the game is certainly spending 14ms/tick preparing its render - which I can only imagine is gathering information on what to render. This exists on map view and not on the game view - and doesn't happen when zoomed in - so I can only guess that this is checking for any changes which need to be portrayed. It is possible the game is keeping everything cached, and then running over every entity to update the cache, but that would effectively take just as long (still needs to visit every entity).

[eradicator]

the question is whether the game does any caching for areas where you do have radar coverage

I would be suprised if it doesn't.

Either way, the game is certainly spending 14ms/tick preparing its render - which I can only imagine is gathering information on what to render. This exists on map view and not on the game view - and doesn't happen when zoomed in

Enabling certain map overlays has quite drastic effects for me:

All overlays disabled = 2ms total
Electric Networks +1ms
Recipe Icons +1.5ms
Pollution +0.5ms (Even thought I have pollution disabled in map settings)

As recipe icons was originally a debug option it's not too suprising that it's not maximally optimized - none of the debug overlays are.

[mmmPI]

The "Render Preparation" actually goes from 2.1ms to 14ms - about 12ms slower, which accounts for almost the entire tick difference on its own (taking into account sleep time).
I have some programming experience, so as a complete guess (based on what I might do), the "Render Preparation" is probably gathering the data needed to do the render. This is part of the normal "game loop" as it needs to be done at a point where all the entities are in a stable state (you couldn't do it in the middle of moving everything for example) so the game can't do anything else at the same time. This is normally very quick as it just gets all the entities on screen, and asks them what they are doing - and if there is any map which you can't see, it doesn't need to do anything for that area (as it can't affect what you see), other than load what was done before (this might be expensive depending on how it was done).

Then the "Render" is simply the graphics system drawing everything - this can be done in parallel, as it just involves pasting in any sprites which were loaded previously. This is also normally very quick, as it just needs to put a few pre-determined sprites (fixed images) in place, however it being slower won't make the game run any slower unless it takes long enough to intrude into the next tick, which hasn't happened here.

yes i have mixed up value with "game render preparation":12.4ms, ( the line just above the "render preparation").

Your explanation makes sense to me, the "render" takes a bit longer when there more things to draw, but unless it takes more than 16.6ms by itself there may not be ups drop as it can be done in parralel (here value is at wort 6.937 ms so there's margin). Therefore it should not be summed up with the other values representing things than can happen only one after another, which would be the "render preparation" , (which takes even longer when zoomed out and is the main culprit here), "electric network", "entity update" and so on.

If the "render" and "render preparation" and "game update" time were summed up, it would exceed by far the value of 25.508 ms for the frame cycle.
but if you omit the "render" considering it's done in parallel, now you are a bit short of time to explain the 25.508 ms if you only add the other 2 thing.

I mean it's just a game of trying the numbers but there's many of them .

What slows the game in this case would be making the list of what's to be drawn, and not the "render" as i wrongly said as this would mean the drawing itself.

[BicycleEater]

Enabling certain map overlays has quite drastic effects for me:

All overlays disabled = 2ms total
Electric Networks +1ms
Recipe Icons +1.5ms
Pollution +0.5ms (Even thought I have pollution disabled in map settings)

As recipe icons was originally a debug option it's not too surprising that it's not maximally optimized - none of the debug overlays are.

That might be it - looking at the image given by the poster they have electrical overlays on, which might be causing the problem. It never occurred to me to check, but that might be the cause. Either that or the recipe icons, but probably one of those.
My main reason for suspecting whether the caching was done for areas where radar coverage is present was that I didn't think that there are 50k of anything much on screen and I couldn't see how the game would spend so long doing render preparation, but now you bring up overlays, that might explain it. I was figuring that the game might well not be optimised for such large maps in some interesting visit-every-entity way, mostly because there were performance problems being caused, but if the game is instead merely attempting to recalculate all the electrical network lines, all the recipe icons, all the Roboport areas, or all the turret ranges, then this might explain the time taken. I doubt the problem is electrical network lines (at least not entirely) as they might well not be sprite-based, but I know that Roboport range, turret range, and recipe icons are sprite-based.


To Impatient:
Maybe try turning off overlays and see if that helps.

[KAA]

Hi there!
Two questions:
1) Is it some kind of mod - moduled substations? I can't do it in vanilla but I imported such BP and wonder what is it?

2021-07-11 17_19_10-Factorio 1.1.35.png (1.27 MiB) Viewed 6920 times

2) Is there any options (I assume, savegame file editing) to adjust biters / nests parameters on an existing map?

I have a large base that I don't want to build from scratch on a new map. But on the current one, there are just too many of biter nests to expand - takes huge amount of time to clean up.

[Amarula]

2) Is there any options (I assume, savegame file editing) to adjust biters / nests parameters on an existing map?

Take a look at the console commands, you can remove pollution/biters/nests, go to peaceful mode, lots of options... https://wiki.factorio.com/Console#Enemy ... on_scripts

[KAA]

2) Is there any options (I assume, savegame file editing) to adjust biters / nests parameters on an existing map?

Take a look at the console commands, you can remove pollution/biters/nests, go to peaceful mode, lots of options... https://wiki.factorio.com/Console#Enemy ... on_scripts

Oh, this is great stuff, thanks! It disables achievement, but oh, ok.
The only thig is... It would be really perfect to not remove biters completely but to lower their nests density.
I'm not sure, what combination of those console parameters would do this. Any advices?

[disentius]

You can use a mod from Bilka for that:
https://mods.factorio.com/mod/ChangeMapSettings

Save game, install, change settings, save game, remove mod.
If it is the only one your achievements should still be there.

[NotRexButCaesar]

Hi there!
Two questions:
1) Is it some kind of mod - moduled substations? I can't do it in vanilla but I imported such BP and wonder what is it?

It is not a mod. I have gotten this before accidentally when editing blueprint strings using https://factorio.tmin10.ru/

It may also have been created through a bug.

[KAA]

Hi there!
Two questions:
1) Is it some kind of mod - moduled substations? I can't do it in vanilla but I imported such BP and wonder what is it?

It is not a mod. I have gotten this before accidentally when editing blueprint strings using https://factorio.tmin10.ru/

It may also have been created through a bug.

WOW)))) yes, it looks like it could be the result of the editing mistake ) Thanks! It doesn't do anything wrong though.

[KAA]

You can use a mod from Bilka for that:
https://mods.factorio.com/mod/ChangeMapSettings

Save game, install, change settings, save game, remove mod.
If it is the only one your achievements should still be there.

thanks a lot! I'll try!

[ssilk]

Is there a simple way to find out, which other recipes do use the same ingredients?
Let’s say you have belts of steel, wheels and iron: what recipes can be done with that?
Advanced question: what recipes are only one ingredient away? E.g. need steel, stone and iron. Or steel, wheels, iron and circuits?

Background: I can’t remember all the recipes in my head, especially modded ones. When playing with a main-bus you pick up 3 or 4 ingredients and build one thing but you have eventually stuff left to build more other things. Maybe just one more item is missing…