Warehouse capacity rebalancing

[dgw]

A recent post on the Factorio forums got me thinking again about warehouse capacities.

I don't get the purpose of the mod. Why wouldn't I just make three rows of six steel/provider chests instead of a warehouse? It's more storage by 64 slots. Am I missing some important feature?

— DarkZalgo

Some time ago (long before getting involved, around when I just found the mod) I did the math to figure out which warehouses were actually more space-efficient than the equivalent area filled with steel chests. In my Factorio career, steel chests have always been 48 slots. I don't believe they've ever changed capacity (the only changelog note on Factorio's wiki is that steel chests became connectable to the circuit network in 0.13). The math then showed that only the Storage warehouse/storehouse is actually more efficient, and that hasn't changed.

For reference, the current chest/storehouse/warehouse space comparison goes like this:

	Tile Area	Storage Slots	Slots/Tile
Steel Chest	1 (1 × 1)	48	48.000
Basic/Logistic Storehouse	9 (3 × 3)	150	16.666…
Storage Storehouse	9 (3 × 3)	300	33.333…
Basic/Logistic Warehouse	36 (6 × 6)	800	22.222…
Storage Warehouse	36 (6 × 6)	2000	55.555…

Both @Anoyomouse and I (@dgw) think rebalancing the warehouse capacities is due, but we differ on details. (I'm going to write "warehouses" to refer to both warehouses and storehouses below for brevity.)

@Anoyomouse reasons that warehouses should remain slightly less efficient than chests because of the "warehouse logic" you gain by building big warehouses.

@dgw reasons that warehouses should store more in the same area than steel chests because warehouses are probably taller than chests. Even if they're about the same height, they should still gain a space advantage because they leave out the chest walls in between the inner tiles.

Whatever the final numbers are, the item recipes will need rebalancing at the same time to keep them in line with the entity capacities. This is probably best done in conjunction with #19 as well, which also brings up rebalancing the recipes.

[Anoyomouse]

Oh, I remember now

When i started warehousing, long time ago, they were based around sizes of a 5x5 footprint, and then changed it up to a 6x6, so possibly that's where the extra whole row of chests come in. (quick edit, that's still only 32 slots per tile for a 5x5 - steel chests would give you 1200 slots)

Also, the whole scrollbar thing in inventories getting added because i was trying to make a chest with 2000 slots.

We also need to keep in mind that the more slots are in the warehouses the slower Factorio gets when using inserters (basically they have to search the entire inventory looking for empty slots), so take that calculation times 2000, and you start to see the problem (we've had people on the forums experiencing slow downs with over 50 storage warehouses - that's way not a lot)

Maybe we should look at rebalancing to wooden chests instead of steel chests because of the less storage space?

Anyway, we definitely need to revisit this

[dgw]

The performance argument also applies to bots, I presume. Searching an inventory for the desired item and removing it must be the same operation whether it's an inserter or a drone initiating it. The logistic network tracks free spaces separately from the checks an inserter must use, silly me. I'm not too keen on making balancing decisions based on performance shortcomings in the game, though. Obviously the ideal inventory search code would run at O(1), or at most O(log n), rather than O(n) or worse. It's too bad mods can't do anything to help that—but at least the performance curve isn't geometric, right? 😁

Rebalancing to wooden chests doesn't feel right because you have to feed in at least one steel chest in the form of logistic containers for the logistic warehouse/storehouse types, plus the steel and iron plates you need to build the basic versions (and added iron to build the logistic variants too). I get the feeling this issue might snowball into a recipe rebalance, too, and there are some good reasons to do that. For example, wooden chests aren't fully automatable in vanilla because wood more or less has to be gathered manually (unlike ores), so I'm starting to lean toward removing those from the crafting recipes. There's also the ingredient counts to think about, since we have one variant (storage) that can't be built in anything less than an AM3. More detailed thoughts on the recipes from me in a separate issue, when I collect them.

My first instinct, honestly, is to tweak the sizes back down as an excuse to keep a lid on the slot counts. Problem is, that would mean removing the 1:1 (or 2:1) size correlation between warehouses (or storehouses) and cargo wagons, and that's a really nice feature of having 6x6 / 3x3 entities that we probably shouldn't change without a very good reason.

I'd really like to poke at the inventory code to see what data structures Factorio uses internally and thus figure out whether there's any hope of improved performance in the future, but sadly I'm not Bilka and I don't have source code access. I suspect it's an unsorted array, meaning O(n) is the best complexity we can expect, but I also don't want to just use that assumption without proof.

That was a much faster search than I expected: Rseding91 on chest performance (and the hope for further performance improvements is pretty much nil)

[Anoyomouse]

Quote from Rseding91:

Chests are so well optimized that literally the only time I've seen them show up as a slow spot when profiling saves in my 3+ years of working on Factorio is when someone was using 2000 slot modded chests with 20+ inserters putting into and out of 50+ chests at once just to show it was slow.

Well, in my experience since warehouses it's not uncommon to have 50+ chests full of your crap items ... :P

The original concept was that the warehouses would break the stack limit and you could for example only have 200 slots, but each slot could contain like 2 or 4 times more items than a standard stack (think of storage drawers mod from Minecraft), but in huge warehouses.

Without LUA entities, or control over the inventory system from scripting (back in 0.13), the easier implementation was just hugs chests. Now with 0.16 (and ever increasing) i haven't really been playing Factorio enough to warrant this revisit, so we're stuck with huge chests.

So, think here, if you have 50+ storage warehouses full of inserters you'll get a noticeable slowdown, if every chest is 2000 slots, you're going to see that slowdown faster ...

Isn't it worth losing some slots to the convenience of having a chest that's accessible from (6 * 4) 24 sides instead of just the 4?

[SgtSnipey]

I asked several months back about if you guys intended on adding Larger buildings down the road, You said you might revisit it down the road so could this be the time to look at it again? It might help you address some of your individual issues of changes.

[dgw]

Larger buildings would require new graphics. While @Nova-Kast is (I think) working on updated graphics for the 0.17 mod release, I don't think we've discussed changing entity sizes at all. We might bring it up.

Personally, I think the 3x3 and 6x6 sizes are pretty perfect, because of how well they match up with base-game entities—train wagons (6 tiles long), assembling machines (3x3), etc. Especially the train loading/unloading use case, where you can place rows of 6x6 warehouses between pairs of rails and have the inserters all line up nicely on both sides.

I'd have to look into the potential pitfalls of making a larger, non-square warehouse building. (Mods like Merging Chests already exist, so it's probably doable.) A lot of IRL warehouses are rectangular, but not square, so that could add a nice variety.

[dgw]

FFF 269 today announced Factorio 0.17 is planned to release in January 2019. That's a good target for getting this done.

[dgw]

Latest word from FFF 282 is that 0.17 will come out around the end of this month (February 2019). If anyone thought that studios other than Valve were immune from the effects of Valve Time… well, this is a lesson! 😆

[dgw]

Worked on this as part of #59.