A lot has changed in last version and I definitely didn't catch all of the bugs, please report bugs you find here.

Enabling option "Modify chest stack size" causes the mod to fail to load with error:

Failed to load mod "WideChests": WideChests/data-updates.lua:11: attempt to index field '?' (a nil value)

This can be temporarily worked around by editing data-updates.lua and changing data.raw["item"][MergingChests.MergableChestId].stack_size to data.raw["item"]["steel-chest"].stack_size

Thanks for the report, will wait a day or two before releasing the fix.

Why is there no migration script for at least default settings?
Creating a migration script for default settings is not hard, just annoying copy-paste work.

{
  "entity":
  [
    ["wide-chest-2", "wide-steel-chest-2"],
    ["wide-chest-3", "wide-steel-chest-3"],
    ["wide-chest-4", "wide-steel-chest-4"],

    ["high-chest-2", "high-steel-chest-2"],
    ["high-chest-3", "high-steel-chest-3"],
    ["high-chest-4", "high-steel-chest-4"],    
  ]
}

For default settings maybe but I try to be fair to everyone. And lot of people modify their settings.

Unless you built telemetry into your mod you have no way of knowing how many players change their settings.
I'm fairly certain most players are lazy and keep default settings as they also do with other software that has telemetry data to back up this claim.

Fair to everyone means screw everyone.
In my case it means rebuilding over 200 train stations and loosing all materials. Other players will be equally unhappy as I have been redirecting LTN players to your mod for UPS friendly station designs for years.

You are right, I shouldn't screw the save up for majority of people using this mod and supporting migration of up to default setting limits is a nice treshold. I'll add the 3.0.0 migration json which works with default settings. Hopefully people with lot of merged chests on their map stayed on version 2.2.2 of the mod.

If someone will want the migration json for their specific settings they will have to create it themself and swap it in the mod.

If a player is loading a game where it can't be migrated because the settings for the previous version changed, can you display a message stating what would need to be changed in the new settings for it to load properly?

I have no way of knowing if you actually had a chest which wasn't specified in migration json placed in the save. But basically when you open a save and game reports which entities were removed you need to add to migration json for every entity that was reported:

• "wide-chest-X" to "wide-steel-chest-X"
• "high-chest-X" to "high-steel-chest-X"
• "warehouse-XxY" to "steel-warehouse-XxY"
• "trashdump-XxY" to "steel-trashdump-XxY"

Where X and Y are the chest dimentions.

If I see the problem, quit without saving, and change the defaults to match what I used before (say, max width of 64), will it be able to convert next time I load the game?

If you get the migration problem error than you have at least one chest with size larger than 42 on the map. Reseting settings to default won't help you because this chests won't be loaded by the mod with the default setting. Can you send here a screenshot of the migration?

I updated to 18, and updated to the latest version of the mod, and started a new game. While my settings seemed to be the same (In particular chests up to 200 wide...) I can only make chests up to 42 wide, even after changing the setting to 201 to try to fix it.

Since a lot of people had trouble with their game long loading time and consumed incredible amount of memory because of their high settings I've encorced maximum limits to be 42/42/1600 (default) and created a new mod which removes this hard limit. Install it and you will be able to merge chests according to you setting again.

I just updated to 0.18 and the latest version of this mod... All my wide chests disappeared, from 6x1 to 62x1 to 5x5. Should all of them disappear just because some are >42 wide?

I see that you've enforced a limit of 42 in the std mod but it's still possible to increase this in the settings. Were you planning to remove the setting altogether?

When merging 62 chests, I get two side-by-side chests: one 42 and one 20. I think that it would be better to do nothing as the separation is not immediately obvious. I actually feel lucky that I noticed it when I did since, having set the maximum to 64 in the settings, it appeared to have done what I expected.

-- Brian

PS: I use chests 62 wide because it fits with the <CCCC<CCCC< trains of Brian's Trains: https://factorioprints.com/view/-LaIPNgh8f16V8EwXXpW

I installed the "unlimited" mod and it didn't change anything. All my merged chests were removed upon loading.
Screenshot: https://drive.google.com/open?id=1sfZQ_LhDCn4AYwgaVrpCwGdLKGzr9pIC

Ohhh... Could it happen because my chests are "iron" instead of "steel"? I have selected that in the settings, though, both before and now.

I didived the mod into 3 mods because people were having problem with not anticipating how much memory would be used and their game taking foreeeeeeeeeeeever to load. I agree that settings window is confusing because the game does something different that it shows in settings but I hadn't figure out a better way so I've at least modified the mod setting tooltip giving a hint on what to do.

Your problem is caused by not using default mod setting (selecting iron-chest as mergable chest). The migration json was designed for default mod setting. In your example you will have to replace every "steel" word with "iron" in the migration json (or you could change the setting back to "steel" and all chest with size up to 42 would be migrated to steel chests). Also you will have to add additional lines (replace "iron" with "steel" if you will switch to steel chests):
["high-chest-62", "high-iron-chest-62"],
["wide-chest-62", "wide-iron-chest-62"],

I'll give that a try, thanks.

Out of curiosity, would it be a big impediment to include migration entries for larger chests so long as the total area stays under the default? That shouldn't use more memory in the game, right? (Do people actually use 40x40 to get 1600? I set my area limit to 100 -- there's only 1000 stacks anyway.)

That would be about 1MB of migration json in a mod that has about 45kB + images. Also when I would add this there would always be some other player which would like something slightly larger. I think supporting migration of default mod setting is good enough.

That big? Yeah, not good. What about just the Nx1 and 1xN chests? Even if it went up to N=100 that would only be 116 new entries, or... assuming 40B per entry... 5K?

I'm technical enough to break open a .zip, edit it, and rebuild it but most people probably aren't willing to do that. This would cover the most common cases.

Anyway, thanks for the .zip tip. I'll give it a try on Friday when I'm back home. This mod really simplifies my train setup since I don't have to build balancers everywhere.

Yes but that would come to question where to make hard limit to 1xN migration should be.

I think most of people playing factorio are able to modify the zip. And those who can't can either learn or rebuild chests which were removed during migration. It definitely would be tedious but not that bad.

rebuilding chests probably is not the biggest problem, but losing the contents of chests that are removed is :-(
luckily, i only started a new map with new settings, and didn't need any migration :-)

but here is an idea (not important for me or for anybody who already migrated "the hard way"): could the mod (an "intermediate version"?) undo the merging of chests so that all merged chests and their contents survives, and after upgrading to the new version the existing single chests would have to be merged again ? still quite some work to merge them again when you have lots of merged chests, but at least no work to split them up (and not accidentally skip over some of them) and no loss of any contents.

@bcwhite: it's always hard to find a limit, eg i mostly use 1xN and also 2xN to be able to have double rows of long inserters and/or to match the width of train wagons, thus 1xN would not be good enough for me. i also use 3xN to be able to use three filter inserters between two long chests, and 4xN and 8xN (as powers of 2), and 2xN, 4xN, 6xN to fit 2x2 machines (eg burners) and 3xN, 6xN, 9xN to fit other 3x3 machines, and 6xN, 13xN, 20xN, to fit trains, etc etc ...

ps: always when starting a new map and setting up mod settings, i have to look it up and test again, what i need to whitelist, eg whether 1xN also includes Nx1, and how to best setup square chests since NxN is not square, but anythingXanything. maybe the whitelist could allow for listing something like NxM, and then NxN would mean "all squares" ?

Splitting all merged chests before migration didn't even occur to me as an option for migration. Which is a pity, because it seems to be the best solution. In ideal world I'd create mod which would check on which version of WideChests it is. Split the chests and save their position in global state, if on 2.2.2 version. And Merged stored positions after migrated to 3.x.x version. You would just have to install the mod and revert manually to 2.2.2 before you first load the save. But I doubt that there is still someone waiting for the migration now :( .

Yes, the whitelist logic is not very well designed. When I first implemented it I wanted to add possibility to specify an aritmethic expression (like "1x7*N-1)" to enable any length for train loading/unloading) but it would be super complicated and overengineered. Your request about having another special character for specifying second dimention as another variable would also be overengineered for 99.9% of people using this and also it would most likely break the settings for them.

i just got back to the discussions because of the bug in the latest update ... :-) :-(

.1. yes, migrations can be difficult, and doing them differently after most people already have done them and continued playing probably is impossible and might only be useful for those people who (eg after 1.0 is released) try to upgrade some very old maps to the newest factorio version to look at their old "crap" they have done years ago :-)

.2. also yes, specifying a whitelist for people with different playstyles would be "tricky" and probably not needed by many. I use several sizes but they all are quite small in one direction (at most eg "1xN Nx1 2xN Nx2 3xN Nx3 4xN Nx4") and then a long list of squares since that gives the option for big and huge chests without needing to enable too many different chests, and squares also look nice ("ocd-friendly" :-) and can be used to easily cover a large area in the center of a chunk with a really big square and with assemblers or smelters all around that square and the ability to exchange their intermediate items without lots of belts and routing problems (yes, quite cheaty but after i designed a "perfect" solution once it is boring to blueprint it over and over and i prefer these squares instead :-)

maybe a simple addition to the current whitelist could help that probably requires only few changes: if a single number or a single "N" is specified in the whitelist, treating that <somenumber> as square with <somenumber>x<samenumber>, and treating that single "N" as "any square" (shortcut for "1x1 2x2 3x3 ... <max>x<max>", especially useful for large values of max, like "N" (with max=100) replacing a 600 char long whitelist for 100 different chests) ?

Problem with that suggestion would that that default setting for whitelist is "NxN" and everybody who didn't touch that would after the update have only square chests. I can't migrate people mod setting values (at least as far as I know).

single numbers and single "N" currently are no valid sizes and shouldn't appear in whitelists. why would a proper whitelist suddenly add squares ?

my idea (the last paragraph) was to not change anything about the current whitelists which have only these four elements "<value>x<value>", "<value>xN", "Nx<value>", "NxN", and only additionally allow "<somevalue>" (without any "x" in it) to stand for a square as if "<somevalue>x<samevalue>" would have been given (please read carefully: some/same :-) and "N" (also without any "x" in it) to stand for any square with width=height.

Ah right, I get you now. I'll add it to mine list of future features.

Hello, i have problem i set in options from steel to iron chests, and merged chest make max 42 wide or 42 height, doesnt matter if i have in options 140 or 120 max distance when i play in 17:79 if i good remember game dont have problems with chest 140 long can u help me? i didnt make any modifications to script etc just clear downloaded mod and 140, now 120 chest distance option

Use https://mods.factorio.com/mod/WideChestsUnlimited