This can cause issues with fast-replacing, and dump the excess stacks on the ground.

There's an old cliché about this, which I'll paraphrase: "Then don't fast-replace storage buildings."

If you'll open an issue on GitHub for excluding the storage versions from fast-replace, I'll consider it for the next release.

This was done by design from the beginning, as you want to store more in a storage warehouse, it sucks that it does dump stacks on the ground if you accidentally replace them tho (this is known to crash games by dumping the world on the floor)

I would like to keep that "feature" simply because making it smaller feels bad, and making the others bigger feels wrong, it'll also significantly impact performance for in-game bases

@anoyomouse Yay/nay on making the storage buildings their own category that isn't fast-replaceable with other types?

It seems like an easy way to prevent giant chest explosions, until I think about the other direction. It'd be impossible to replace another type of ware-/storehouse with storage too. That upgrade path is very useful.

Yeah, it blocks the useful normal warehouse -> storage, or any warehouse -> storage

Maybe need to ask the devs if they have a upgrade only path?

I mean, fill a steel chest and fast replace with a wooden chest, explosion right? (Not the same scale as a warehouse, but that's sheer volume)

That, while true, is 32 stacks. This one is 200 stacks different. I guess still not as egregious as Angel's Warehouses with a 350 (768->418) stack difference that I found out the hard way. You could always increase the storage of the others to the capacity of the logistics storage.

I think the best solution is the same as base-game chests: Don't fast-replace the wrong one. 🙃

We're coming up on a graphics overhaul for the next release. Making the storage variants the same size as the others has come up before, and the option chosen was shrinking the storage ones. However, the relative complexity of making sure that items in the old, larger warehouses don't get lost wasn't worth it to me.

Making all warehouses 2000 slots instead is not my favorite approach. It messes with the per-tile item density, and could have a significant performance impact. Factorio is not optimized for large inventories…

Well, I didn't know that was the wrong one at the time. I now know to check the inventory sizes ahead of time, so I don't do that again.

Besides, I don't notice any significant frame drop looking at a 2000-slot inventory. Darkstar Utilities 50000-slot chests, however, is a different story.

"You never forget your first [chest explosion]." — one of the Factorio devs, probably

Performance on your system doesn't correlate to anyone else's experience—for all I know, you have a Core i9-10980HK or something else ridiculous. We know that larger inventories make the game slower, and warehouses can each have up to 24 inserters linked to them in vanilla, to say nothing of modded inserters. Inserters interacting with the inventory is what causes the most slowdowns.

And just as a personal preference, I really like the 50 stacks/tile density you get with 1800-slot warehouses. It's a nice number. Actually, looking at these numbers again has reminded me that storehouses have the same item density as warehouses, which doesn't make sense. But now I'm just getting sidetracked.

Maybe there will be a reevaluation of inventory sizes in a future update, but please don't hold your breath for storage buildings to match the other types. Anoyomouse and I are both quite fond of the idea that the storage buildings have a ton of stuff ripped out of the inside to make them hold more stuff at the expense of fancier logistic features. 😁

If you're willing to go the scripting route: I think you can simply block the fast-replace in the "wrong" direction by having an on_selected_entity_changed event handler that temporarily sets minable=false on the selected building. If you wanted to get fancy you could even make it dependant on storage content so that fast-replace still works if the storage is sufficently empty.

That covers only one case—and on_selected_entity_changed can happen a lot e.g. if the player is riding a train through some dense part of the factory. The event doesn't support filtering, and there are other ways that storage warehouses could get fast-replaced, like upgrade planners.

I still say users should just be careful. We get like one complaint about this a year, maybe; running a script handler every time the player's cursor touches a new entity is not worth the performance impact..

[mis-clicked, accidentally quoted myself instead of editing]

It happens at maximum once per player per tick. Most of the time much less, and most of that it'd just be if not bla[entity_name] then return end. I just wrote it down while the thought was still fresh in my mind. Using it or not is ofc your decision ;).

An event that fires every tick IS a lot. If it was possible to block the on_pre_build event, for example, that would ONLY fire if the player is trying to place an item—usually no more than once or twice per second (30-60 ticks average gap in between firings), at most. Bigger issues include that it's not possible for an event handler to tell Factorio that it shouldn't allow an action to complete ("won't fix" from https://forums.factorio.com/48225), and the maintenance overhead of ALL the ways a warehouse could be fast-replaced (e.g. by a construction robot).

Love the idea! But right now it's more of a wishlist thing, like the ability to upgrade storage capacities through research (see https://github.com/Warehousing/Warehousing/issues/77 on GitHub).

Well. Frequency wise "every tick" isn't a low frequency (not the worst either). And the cpu impact depends more on what the handler actually does. As in this case it's a single name check the impact would be low. And "every tick" is the unlikely maximum frequency. The average would probably be more like 2 per second. But I didn't really come here to argue about frequency nor am I saying this is the greatest solution ever. It's just a possible hack that could solve the problem. If the frequency is all you worry about it might be possible to use a linked_control custom input event instead. As far as I remember those fire before the built/put event so it should be possible to "cancel" them. The drawback of that would be that the user sees a "green" ghost instead of a "red" one even if the placement is not allowed. And in the end you could always make the whole thing optional via mod-setting for people who worry about performance.

(@github: LuaInventory does not exist in the world, so inserters/bots can not interact with them.)

This was done by design from the beginning ...

This should be considered as an flaw in that design. As everybody said, the issue with replacing the yellow one for any other colour is really annoying.
At first you'll will not notice this difference and when one wants to change the logic at a (mega)base, 50(200) slots goes to the ground.
Scale the slots of the yellow ones down to match the others might cause even more grief with older save, so it seem logical to change every colour and both sizes same to match the yellow sizes - 500 and 2000

Don't fast-replace the wrong one.

That's not even advice - seriously ;)

Btw, while modding something completely different of my own I happend to also measure the on_selection_changed impact. If the selection changes once per tick it costs about 0.030ms on my potato to filter for entity name. For comparison an empty on_tick handler takes 0.020ms here.