Can you make this mod capable of working with logistic chests? The sprite for them would be the main issue I think but you could just stamp 1 chest per node but they would have the selection box of a merged chest or IDK, you could cut the normal sprite into 3 pieces: left side, right side, center, replicate the center on the other chests and the sides on the first and last chest, just some ideas, I would love to see this working with logistic chests btw. Requester chests could just lose all the requests they had before you merge, wouldn't be an issue, or just sum them up untill 12 requests.

It can help make max length of chests infinite. :) and what about merging assemblers? Gahddamn, it's genius!

This mod was never intended for logistic chests, it was just large storage mod. You can probably simulate your needed behaviour using logistic chests next to merged chest and clever use of filter inserters with circuit conditions.

I don't really know how you imagine it would look. I definetly won't make merged chest sprite just buch of chests next to each other with bounding box spanning over multiple of them.

And if you mean generating sprites during runtime: I think game still needs to load all sprites during startup. I will most definetly not make sprites for all possibilities of merging all 4 types of logistic chests with steel chests of max length 42. :D That is a LOOOOOOT of possibilities.

And infinite chests: unless a single entity can have use multiple sprites somehow stitched together I don't think it will be possible.

I mean something like this for sprites:

-- requester chest
local layer_left = {
priority = "extra-high",
filename = "base/graphics/entity/logistic-chest/logistic-chest-requester.png",
width = 2,
height = 32,
shift = util.by_pixel(-1, 0) -- here you fine tune the sprite by nudging it left(-) or right (+) (x, y)
}

local layer_right = {
priority = "extra-high",
filename = "base/graphics/entity/logistic-chest/logistic-chest-requester.png",
width = 2,
height = 32,
shift = util.by_pixel(30, 0) -- here you fine tune the sprite by nudging it left(-) or right (+) (x, y)
}

-- the middle layer will be the remaining picture of the chest now that you cut both sides
local layer_middle = {
priority = "extra-high",
filename = "base/graphics/entity/logistic-chest/logistic-chest-requester.png",
width = 28,
height = 32,
shift = util.by_pixel(2, 0) -- here you fine tune the sprite by nudging it left(-) or right (+) (x, y)
-- we nudge it 2 pixels to the right so we won't copy the 2 pixels from the left side of the item
}

-- then on your merged logistic chest file
structure = {
layers = {
layer_left,
-- now we will replicate the middle layer for the "i" number of chests, I don't know your variable here so I'm assuming chest_count as the variable
for i = 0, (chest_count -1), do
layer_middle
end,
layer_right
}
}
-- since every entity is a 32x32 sprite, if you have like 4 connected chests it would be 32x4 sprites on the direction of your connection, what I wrote above could be the initial idea for the horizontal chest sprite since we're only messing with the width property not height.
For the middle layer we're just stamping multiple times the 1 chest middle layer sprite on the final 1x4 chest.
I know that the code probably won't work but its some idea to start with so you won't need to recreate every single sprite picture by hand just to stamp on the items, you can do it on runtime by copying the pixels of the already loaded sprite ingame.

Are you talking about creating sprite everytime chest is merged? Or create sprite when game is loading and then use them?

If you mean first one: that probabyl won't work since game needs all sprites when loading the game. If you mean second option then it would be much easier to generate another masive sprite containing all lengths/heights in some other program (which I already have). But I really don't know if I want to add this to the mod.

Why do you want this feature? If you give me good reason I will consider it. But if it is just so you can have massive logistic chest it probably won't be good reason to implement another logic for seperating selected chests into groups depending on their types and then merging them.