When you subdivide your schematic by adding more selection boxes sometimes it is possible some parts still overlap.

When this happens the analyzer counts the blocks double.

(small example screenshot added)

Yes, since you know your file format better then anybody you probably know the best solution.

Tnx for your time.

Yep, each of the sub-regions is iterated and counted separately for the material list. I don't think this will ever get fixed, because it would be rather complicated to fix or even to decide what exactly should happen with overlapping regions.

In general it's simply highly discouraged to make overlapping regions because of this issue, and also the related issue of how the overlapping region will get overwritten in the schematic world by the region(s) that are placed there later that the first region. Normally it wouldn't be a big issue if they regions weren't moved in the placement and would thus contain an identical overlapping region, but if at least one of the overlapping regions was rebuilt or moved, then it would overwrite whatever is in the other regions that it's overlapping with.

So I guess to solve this, each of the overlapping regions would need to have some kind of priority assigned to decide which one should take precedence in a given overlapping region. And then all the methods that iterate sub-regions would have to sub-divide any region that overlaps with some other regions, and the overlapping parts should only be handled by the region that has the highest priority. And maybe to assign the priority simply the order of the sub-regions could be used. However currently they are stored inside a compound tag keyed by their name, which does not maintain order, and they are simply sorted alphabetically when loaded. I would need to add a way to store their priority order as well then. And the Area Editor would have a separate view/mode for re-ordering the sub-regions in the order of priority, ie. which region should overwrite any lower regions if overlapping.

Okay so now after thinking about it, maybe it will get fixed at some point if I do the above mentioned things.

Ok thanks for the update,

I thought you could just check for duplicate coords in the active (shown) selections of said schematic (thinking simple, i know :p)

I try to avoid cross overs, I just noticed it and thought i mentioned it in just in case.

How would you check for duplicate coordinates? That would mean you would have to either keep like a Set<BlockPos> of ALL the positions in any placed placements, or you would have to compare the coordinates of each block when being placed, to ALL the sub-region bounding boxes of all other sub-regions (than the current region) that are active. The first one could take tens of megabytes of extra memory with large schematics, and the second could get super slow with many sub-regions loaded and active.

Edit: Actually the first case would be even worse, you would have to keep the Set per sub-region and again compare each position to all the sets for all the other regions except the current one. In which case it would just be a worse implementation of the second alternative, just comparing the position to the bounding boxes.

I think the best way to do it is to compare the regions, and if any overlap, then subdivide those regions into smaller regions and the overlapping boxes get their data from the region with the highest priority.

like i said, i was thinking the simple way ;)

I was thinking since you draw the schematic in the world in ghost format coords are already being used? i thought you could just check if a ghost block was already in that place. and then just remember only that one to not count double.

but apperantly not that easy according to your explanation.

tnx for explaining.
i will try to avoid overlappings and make more sub selections instead if needed.

Well yes when adding stuff to the schematic world, you could check if there is already a block there. But that would still give you no information about overlapping regions in case some of those blocks are air, and also it might then be order sensitive/locational depending on the coordinate iteration order, and the placement manager does not guarantee any handling order for the per-chunk boxes it generates from the sub-regions that overlap a given chunk. I think trying to do it via the schematic world has block status would be even way more complicated than just sub-dividing the sub-region boxes in the beginning.

And also if you generate a material list directly for a schematic (via the Load Schematics menu, and not opening it for a placement) then the schematic world is not used at all, but the block data from the schematic is counted directly.