If you have this layout of chests:

c
c
c

cccccccccccc

And you select them all at once.
The top group will never get merged if you don't select it individually.

This is because of architecture flaw of mod:

SortIntoGroups(player, entities, mergeHorizontaly)

function takes 'mergeHorizontaly' parameter, which is calculated like this

local width, height = MergingChests.FindBoundingBoxSize(entities)
...
local mergeHorizontaly = width > height

So it's up to bounding box to decide if vertical chests or horizontal will get merged.
Which isn't seems to be correct.

Im my opinion the correct would be if SortIntoGroups will not have this param and will return all the groups: vertical and horizontal ones, as it's expected by functions name.

However i'm not fixing this by myself because fixing it will affect three core functions of this mod.

And if I change them i don't think that would be easier for you to check and merge them into your code than to fix them by yourself after this explanation of the problem.

Let me give you counter example:

c
cc
cc

cccccccccccc

If you select all of it how does the mod suppose to know you want to merge those two top ones verticaly and the bottom one horizontaly. It would be incredible hassle to code and source code is long enough as it is. So I decided that merging will be done in direction of dominant size of bounding box of selected chests.

I'm planning to solve this problem (well more of "avoid it" since only solid blocks of selected chests will be mergable) in next version with new graphics...as soon as I find someone willing to create the sprites.

I do understand this problem. I think there should be some meaningful decision tree for this. For example to pick the biggest group, or to pick horizontal prior to vertical, or just report about ambigious situation and do nothing.

I was thinking how would I make SortIntoGroups and I thought of this:
- Make a 2-dim array "chest_map"
- foreach all the chests and fill "chest_map" with references to EntityInfo ({entity = some_entity, is_horizontal = ?, ...}) structures like this:
{} {c1} {} {}
{} {c1} {} {}
{} {} {c5} {c6}
{c2} {c3} {c4} {c4}
- then all the staff like "find continious chest" or "find the biggest chest" will be both fast and quite simple to implement
- and after picked one of the groups it can be removed, so it won't count in next attempts to merge:
{} {c1} {} {}
{} {c1} {} {}
{} {} {} {}
{c2} {c3} {} {}

Fast because access by index is quite fast and two-dim array isn't big and can be implemented as sparse array.

This is nice solution. This algorithm will be able to merge all chests regardless of their orientation. But i think that you underestimate how hard it will be to code this.

I will try it and see how it turns out.

Ok I've done the code...it's 180 lines of code so some optimalization is required. I thinking about adding wooden/iron chests merging to next update. It seems too much of a hassle since it's only "required" when using some different mod that makes steel hard to make.

Requester & Provider chests seems to be more interesting in this questions.

I'm definitely going to stay away from those.

Another problem raises with next release. I'm going to merge entire block of chests into one entity. And I would like to implement this sorting into groups. But what if chests are in this configuration:

WWWWW
CCCC
CCCC

Legend:
C - singular chest
W - one merged chest

Simple solution is allow to merge only singular chests but that would be a step back from current possibilities.

And there is a problem with circuit connections...example. Chest before merge reaches but merged chest doesn't. Game doesn't allow to make this connection even using Lua.

I see some complex solution for circuit connections but i wouldn't implement that, because of many things, but just to state it out:
You can make a small entity, called 'connection point' without collision box and put it as an overlay on courners of the chest. Than iterconnect all connection points and all chests.
Cons:
- Many entities
- It would introduce new entites.
- I don't think it worth the effort.
- It's hard to make and test.
- Interconnections between connection points and chests would likely be visible.

About rectangular merging:
I was thinking about ambigious situations like above and I think in this case you should just show a message so the player will select them one by one. I think this will make the mod more usable for a player than some strange logic for choosing chests. Anyway I dont think of any actual example when ambigious configurations could be needed. You always need to stick in an inserter between chests so you'll have a gap for inserters. On the other hand if you want to put say 3 storages of 3x3 (much more common case) there is no sane algorithm that can figure out that you want 3 entities and not 3x9, so in this case you'll need to manually select them three times.

So if you expect a user to do it manually in more common case (3 entities 3x3, staying close to each other), why would you implement some super logic for uncommon case in your post which likely won't be ever used?

I see some complex solution for circuit connections but i wouldn't implement that, because of many things, but just to state it out:
You can make a small entity, called 'connection point' without collision box and put it as an overlay on courners of the chest. Than iterconnect all connection points and all chests.
Cons:
- Many entities
- It would introduce new entites.
- I don't think it worth the effort.
- It's hard to make and test.
- Interconnections between connection points and chests would likely be visible.

About rectangular merging:
I was thinking about ambigious situations like above and I think in this case you should just show a message so the player will select them one by one. I think this will make the mod more usable for a player than some strange logic for choosing chests. Anyway I dont think of any actual example when ambigious configurations could be needed. You always need to stick in an inserter between chests so you'll have a gap for inserters. On the other hand if you want to put say 3 storages of 3x3 (much more common case) there is no sane algorithm that can figure out that you want 3 entities and not 3x9, so in this case you'll need to manually select them three times.

So if you expect a user to do it manually in more common case (3 entities 3x3, staying close to each other), why would you implement some super logic for uncommon case in your post which likely won't be ever used?

I see some complex solution for circuit connections but i wouldn't implement that, because of many things, but just to state it out:
You can make a small entity, called 'connection point' without collision box and put it as an overlay on courners of the chest. Than iterconnect all connection points and all chests.
Cons:
- Many entities
- It would introduce new entites.
- I don't think it worth the effort.
- It's hard to make and test.
- Interconnections between connection points and chests would likely be visible.

About rectangular merging:
I was thinking about ambigious situations like above and I think in this case you should just show a message so the player will select them one by one. I think this will make the mod more usable for a player than some strange logic for choosing chests. Anyway I dont think of any actual example when ambigious configurations could be needed. You always need to stick in an inserter between chests so you'll have a gap for inserters. On the other hand if you want to put say 3 storages of 3x3 (much more common case) there is no sane algorithm that can figure out that you want 3 entities and not 3x9, so in this case you'll need to manually select them three times.

So if you expect a user to do it manually in more common case (3 entities 3x3, staying close to each other), why would you implement some super logic for uncommon case in your post which likely won't be ever used?

Prolog: I'm super relived and also super pissed with my solution to blueprint circuit connection problem in 1.9.x. I've tried it before (when i was releasing 1.8) and it didn't work. I tried it now and it worked. I went through change log and didn't find any change to this behaviour so it was my fuck up a month ago or developers fixed it and didn't put it into change log (probably I just fucked up).

About circuit connections: Creating new entity for connecting wouldn't probably work since chests can be really long so multiple points would be needed. Also I'm not really sure how I would send changes in circuit network to the chest. Probably best solution is to not worry about it. At least for now since you can still place pole near chest's center and connect there. It will be a problem once chests won't be one dimentional. There is no way to connect to 10x10 merged chest since the center is too far from any potential electric pole. But that is a problem for future me, once i find an artist.

About rectangular merging: I don't know what exactly you mean.
- If you mean 1.9.x version of smarter merging rectangular areas then I don't think if there is an ambigious situation. The algorithm simply finds longest sequence of chests that can be merged (prefering first longest horizontal match it finds) and merges them.
- If you mean 2.0.x (hopefully not later) merging of rectangular array of chests into one chest then the solution is also simple. The algorithm's job is to find largest area that can be merged into one entity so 3x9 full grid of steel chests will be merged into 3x9 chest. The problem rises when there are already some merged chests in considered area. The algorithm will need to take into account that it can use "this merged chest" but only if it uses all it's tiles in one merge. It's kind of difficult to explain so I'll just have to hope that you understand. But even if you don't it doesn't matter since release of 2.0.x is nowhere in sight and I can always go back to merging only not merged steel chests which is also never ambigious.

Whew those were some long essays we've written.