Lag when bulk inserting/removing from enlarged sorted inventory [0.17.66]

[youtakun]

There are custom scenarios that increase the inventory to well over 1000 slots using modified research. When over ~600 slots* are filled and "Always keep the main player's inventory sorted" is enabled, bots inserting or removing stuff from your inventory cause severe UPS slowdown. Locally I manage to go down to 14.9UPS but on a public server from Comfy Factorio it goes down to 6UPS. When inventory sorting is disabled (very annoying with such a large inventory) the slowdown disappears completely.

(* Depending on what else is in your inventory, it can vary between 300 and 600.)

Steps to reproduce (vanilla savegame attached):

• Start a new world
• Put down a bunch of powered roboports containing 1500 (30 stacks) logistic robots. Suggested cheats:
  /c game.player.cheat_mode = 1
  /c game.player.surface.always_day = true
  /c game.player.force.research_all_technologies()
• Also put down at least 42 Logistic storage chests
• Increase inventory size (emulate research done in scenario)
  /c game.player.character_inventory_slots_bonus = 2000
• Increase worker robot storage size and speed, to make the slowdown effect more obvious (the scenario also increases these but I don't know by how much)
  /c game.player.force.worker_robots_speed_modifier = 10
  /c game.player.force.worker_robots_storage_bonus = 10
• Fill inventory completely
  /c game.player.insert({name="iron-plate", count=200000})
• Auto-trash all iron plates.

factorio-Inveotory-peek.png (503.33 KiB) Viewed 3348 times

Inventory sorted

factorio-sort-on.jpg (1.8 MiB) Viewed 3348 times

Inventory not sorted

factorio-sort-off.jpg (1.76 MiB) Viewed 3348 times

[posila]

Thanks for the report.
Performance issues caused by configuring things to have 2 orders of magnitude larger size/count than normal game are not considered bugs.

[eradicator]

If sorting all the time is too expensive you can simply force the game to sort every few seconds or so. Ofc you have to force everyone to disable the automatic sorting because as far as i know there's no way to disabled it in script (and i'm not sure how likely it is to ever be).

Code: Select all

/c
local min_delay = 120
script.on_event(defines.events.on_tick,function(e)
	local x = e.tick % (#game.players + min_delay)
	if (x < #game.players) and game.players[x+1].connected then
		game.players[x+1].get_main_inventory().sort_and_merge()
		end
	end)

[youtakun]

Thanks for the report.
Performance issues caused by configuring things to have 2 orders of magnitude larger size/count than normal game are not considered bugs.

If two orders of magnitude is 'not a bug', then what is the official limit?

For this scenario (choppy) it's essential to have a large inventory, because instead of mining for ores, ores drop from trees. Except for bot 'destructing', which does not drop ore. So 'mining' ores by chopping trees has to be done by players. The further from spawn, the richer the ores in the trees. Trees at 10km out drop 1000 ore and when you're able to reach that far, you can already chop 4 trees per second. In late-game where research costs tons of space potions, you need a large inventory otherwise you have to walk back to robot range after chopping every other tree.

[posila]

If two orders of magnitude is 'not a bug', then what is the official limit?

I suppose the answer is - whatever number of slots doesn't cause slowdown on a computer on which the game currently runs.
And I think as long as the inventory GUI doesn't have scrollbars, it has somewhat reasonable size. (I am pretty sure someone will find a loophole in this one)

[eradicator]

Sounds mostly like a design flaw in the scenario. If you want the player to manually handle ten-thousands of items you should increase the stack sizes or something instead of forcing the player to manage an annoyingly oversized inventory. Just make trees drop "raw ore" or "compressed ore" or w/e and add some extra furnace recipes that smelt 1 compressed ore into 1000 plates that takes 1000 times as long.

[youtakun]

You cannot increase stack size with a scenario because you can only change things that you can change runtime. Changing or adding items must be done load-time, thus require a mod[1]. This is intentionally not a mod because modded servers are less popular[citation needed].

[eradicator]

Well. You can chose yourself which foot you shoot yourself in. I was merely doing theorecrafting about possible solutions for your problem. Either accept the lag, or accept that you need to package the scenario into a mod, or make the sorting less freuqnent, or stop caring about popularity, or think of something better, or... ;).

[BlueTemplar]

Modded servers were less popular in 0.16, because there was no mod sync.
With 0.17, once this "common knowledge" fades out, I'd expect modded servers to actually become more popular...

[mmmPI]

You cannot increase stack size with a scenario because you can only change things that you can change runtime. Changing or adding items must be done load-time, thus require a mod. This is intentionally not a mod because modded servers are less popular[citation needed].

Modded servers are "less" popular because you need to reload the game in order to join one, or if you load with mod, you need to reload when joining vanilla game.[personnal opinion]

Sounds mostly like a design flaw in the scenario

Seems the case, or maybe a user further modified a scenario.

Few month ago I played some Comfy map on version 0.16, in diggy ( and not choppy but is similar ) you drop random ore from rocks, and the map is covered with rocks that you dig, to make room for buiding. The further you go the more ore will be dropped by rocks. I don't remember an increased inventory size but at the time it was possible to make the "spill" that occurs when you cancel crafting queue, or when removing high tier armor with full inventory, directly on belts. ( and same for the ores that drop from a rock when you have full inventory ).

In my solo play i would use a lane of train in which i was dumping my ores, and when full it was scheduled to drop all the ores at a sorter/buffer station.

But in multiplayer when you have 10 players on the same map, this is not adapted, players were just building long line of belts towards the beginning of the bus that was a sorter/buffer. And you had some "digging room" where you would see 2 -3 players or more, some shooting at the biters that spawn from rocks, some mining rocks( also some shooting at rocks in later stages ), and some covering the room with belts to direct all ore that spilled on the floor onto those those long lane of belts without manual intervention.

Thus you wanted to have limited inventory. Since when it was full, the ore looted directly on the belts ( or on the floor), and were sent to the main bus ( so you could mine 100K ore in a raw if you were patient or very far ). I remember also that at some point the behavior of the material "spilling" on the floor was changed so that it would ignore belts and just drops on the floor. ( which maybe broke the covering the floor with belts setup and led to the increase inventory size ?)

For the later stages of the game, i would advise OP to make separate robotport network, some being temporary mining setups, designed to utilize auto-trash, and short distance between mining and storage chest, once no trees/ rock are in the area, you remove most of the robot network , and you will be left with materials in storage chest that you can load into trains. This also allow to have storage of useless material not clogging the main area ( for some reason i had way too much copper and not enough iron so in diggy this translated into several rooms full of copper ore in storage chest that a train would pick-up from time to time as if it was a mining outpost ).

Maybe i'm wrong but this seems similar to what happen when you have a gigantic warehouse, instead of several smaller for example, except you can't reserve slots in inventory, so i wouldn't do the research that allow for hyper big inventory, (or use command to unresearch them ) the various algorithms that exists to sorts lists are very optimized by different professionnal fields [citation needed], and despite that are still considered a very difficult problem with far from perfect solutions, which in the case of thousands (potentially millions) of robots asking refresh with high frequency, i would guess is a particularly difficult case of a difficult problem already

[BlueTemplar]

I remember also that at some point the behavior of the material "spilling" on the floor was changed so that it would ignore belts and just drops on the floor. ( which maybe broke the covering the floor with belts setup and led to the increase inventory size ?)

Sounds like the fix introduced in 0.17 to prevent "polluting" belts with spilled items ?
I remember that in Diggy in 0.16 stone (&coal) spills from dug rocks were causing significant slowdowns...

[eradicator]

The type of scenario generally reminds me greatly of minecraft where you're also mostly manually mine your ores. And there are a great many mods that solve this problem in minecraft, in both "technology" and "magic" flavours. I think the most common concepts were either an "unload station" where you stand on some sort of pad and it sucks the junk out of your inventory into an adjacent chest (easily combinable with storing the ore as virtual lua items and not in the actual inventory, thus excluding them from having to be sorted), or a chest that directly mirrors a players inventory, so that (filter-)inserters can constantly take from the player inventory (magically) regardless of where the actual player is. An approach similar to the "Robot Mining" mods where you just leave it to the bots to pick up the shit on the ground would work too (especially if the modder is aware that item-on-ground can have arbitrary stack sizes not limited by the stack_size of the item).

TL;DR: Even limited to "no mod" there are too many possible solutions to write down.

[BlueTemplar]

I thought that the items on the ground couldn't be stacked ??

[eradicator]

I thought that the items on the ground couldn't be stacked ??

The base game never uses it, but it can be done via script.

@OP: Btw, are you the author of the scenario (or modification thereof)?

[youtakun]

I'm not, but I asked the author to come here.

@mmmPI: I, for one, don't like 'popular' and heavy game-modifying mods like Bob's, so I select 'no mods' in the server browser. If this server has a 'trivial' mod to just change stack size, I wouldn't even find the server.

[mmmPI]

I think the most common concepts were either an "unload station" where you stand on some sort of pad and it sucks the junk out of your inventory into an adjacent chest

This in diggy i had an equivalent, with some coins you get after you mine lots of rock you can buy teleporter, it's a tile that allow a player to teleport to another teleporter, once you have at least 2 you can place 1 in the middle of a small a separate network with with many many requester chest that loads onto belts and storage chest. The other teleporter you bring with you and you place it in big room ( or big forest) and you teleport each time your inventory is full, with auto-trash on.

This is very fast, but only adapted to "mid-game", if you mine very rich rocks (or trees) because you are far from spawn, then you would need a trip every 20 second it gets boring, compared to just storing materials and getting them little by little later. ( In this case you need that "unload station" near every forest or big room of rocks.)

Sounds like the fix introduced in 0.17 to prevent "polluting" belts with spilled items ?
I remember that in Diggy in 0.16 stone (&coal) spills from dug rocks were causing significant slowdowns...

I thought that the items on the ground couldn't be stacked ??

For those, i think it was this fix you mention to prevent polluting belts, i don't know if it had an impact on the scenario, i don't remember playing one since 0.17, and in solo you wouldn't really use the method.

I have seen a post i can't find anymore, where someone showed you can stack item on a belt that is stopped using combinators, if you use the hotkey to drop an item and mouse over the stopped belt.
Edit : viewtopic.php?f=58&t=73508


When you have one big room, you start to cover the floor with belts that all load onto the same long lane which is sorted later. When you mine rocks item used to spill on belt, not stacking, just taking the normal space in 1 tile. When there was no room on the floor it would drop in a square pattern around the drop point( like when canceling queue). Usually 50% of it is away from spawn, 50% is where you come from and loot onto belts directly. Then you wait like 10 sec, and the belts are empty again, especiallly if the team that make science and ammo and stuff is consuming material, some player would just buffer the plate to drain the belts.

The more room you uncover, means you can mine more and more in a row, if you arrive in a room that's 50% covered with belts, you can mine let say 4 rocks then your inventory is full, and the next 30 rocks will spill on the belts,when they are full take a little time to add new belts in uncovered land, and repeat when ressources drain.

The problem is that if you go too fast, some ressources spills on the "wrong" side, not on the full belts, it looks for the closest spot, which sometimes end up in location that you didn't plan to expand, leaving tons of ressources on the floor everywhere. ( which in solo i used commands to remove sometimes).

The mod diggy had also slowdowns in my games due to the rocks being obstacle for biters, and map being covered with rocks. ( but this isn't a problem that is multiplied by number of players and came from my hardware ).

You could also nuke the middle of the room, and after the (1)5 second freeze, you would have the map covered with ore

[youtakun]

This is not diggy where spills are limited to a confined area.

When you keep chopping trees with a full inventory the spills pile up quickly and you get a new source of slowness: When you spill inside a spill of already dozens of meters radius, the algorithm that finds empty spots to spill on will lag the game. And it gets in between the trees, hard to clean up. A carpet of belts doesn't fit* and Cleanup bots are *very* slow compared to auto-trash and chest transfer. Yes, even at worker robot speed 14.

I hope the scenario-writers will implement some of the good ideas I've seen in this thread.

(*side note: the tempo at which one person can mine with a moveable bot unload station fills up 16 blue belts)

factorio-spill.jpg (2.2 MiB) Viewed 3134 times

factorio-16filled.jpg (1.63 MiB) Viewed 3124 times

[mmmPI]

This is not diggy where spills are limited to a confined area.
When you keep chopping trees with a full inventory the spills pile up quickly and you get a new source of slowness: When you spill inside a spill of already dozens of meters radius, the algorithm that finds empty spots to spill on will lag the game. And it gets in between the trees, hard to clean up.

That's what i tried to describe with this

The problem is that if you go too fast, some ressources spills on the "wrong" side, not on the full belts, it looks for the closest spot, which sometimes end up in location that you didn't plan to expand, leaving tons of ressources on the floor everywhere. ( which in solo i used commands to remove sometimes).

The ressources in between trees are those ressources that spill in the "wrong" place".

In the picture and with your numbers I understand the problem you see using a belt flooring, the throughput would be too low for the belts to ever drain ressources or , two person mining would need to be connected with a 16 lane bus too a place where ressources are stockpiled and sorted.

( The square shape of the spill on spills wouldn't be much of a problem in case of lower throuput and/or more confined area , since the ressources would always find the closest place to drop on the floor being the same belts almost where you just mined.)

Given the throuput you have reached in this game i would definitely consider that late game.

This is similar to train usage as i see it, i would explain it this way:

Your factory consume 8 belts of material, you can mine 16 belts if you reach this distance. This means you can build 50% of time and 50% of time you should mine or the buffer will run dry.

You will need at some point to do woodcutting 30 minutes in a row, because it will takes you 2 minutes to travel at a place where you can get this 16belts of material.
You can't do 5 minutes mining 5 minutes building forever, because the bigger your factory, the further away you need to go ( or the more person mining you need).
5 minutes mining 5 minutes building would result into wasting your building time by travelling to, and travelling back from the mining spot/forest.

Solutions:

1) Reduce need to come back to main base: have it automated as much as possible, use robots to replenish defense and copy paste easily tileable design, and so your character is free to mine longer period, or from further area, only get back when buffer are enough to let you build what you have planned ( 20 min buffer for making another green circuit factory with beacon this time ?) ( 30 minutes too add a new train in the mall for that new product you unlock? ) ( 10 minutes to add some more steam engine/nuclear ? ) and so on, if you can use blue print from afar it's always better

2) This goes for preparing next "forest" , or in my case " room" , this means let say you estimate your buffer at 25 minutes, you can take 15 to 20 minutes to keep it safe, to lay down tracks and load/unload station from the beginning of the main bus ( or anydropoff location ) to the new forest. Preparing this means that when it is finished you are in the forest, in a small roboport network that cover the forest, with 5000 logibots.

You have 200's storage chest in a square and 12 requester chest per ressources that load directly on wagon for example. And then you mine with auto trash on.


3)You can mine as much as you want you are in situation 1) and your buffer are the 200's storage chest, the robots will put the material in storage in the requester , and send to the base only the theorical 8 belts of material, and not the whole 16 you can mine. The difference will stay idle in storage chest.

When you are done with the forest, you only leave 500 robots instead of 5000 for example, just so that then can on the long run empty the storage chest into the requester.

You can even check this way how much ressources each of the outpost has left, by using the hotkey to monitor logistic network

Doing this methods doesn't require huge inventory, as you can expect robots to form a continuous line acting as a floating belts between the mining character and the chests, if the line gets too long, just consider it as a "new forest" with its own station of tracks, isolated network and stuff.

I would then unresearch the inventory size with command like cheats , the robots should be fast enough to prevent materials from clogging inventory. ( on short distance you can unload full inventory in less than 2 second. ) The material would in this case never fall on the floor since you'd always have room.

Does that seems like it would solve problems ?

[EDIT: seems similar too your 2nd picture, but with trains instead of belt, bonus: you already have trains setup to use with real miners on the ressources patch that are generated under the trees ]

i'd need to try it for myself in choppy, but i feel like i would add a mod that lets you plant seed automatically, like blueprintable-seed, and recursive blueprint so that i would only chop the same few forest that i grow very far away and always use the same rails