Open joex92 opened 3 years ago
Looks like it already overflows the backing long array. I'm not sure why it happens already with this size schematic, as it should be nowhere near the maximum size yet. Or wait... I think this might have been the index handling bug I fixed a while back in 1.12.2, but that fix is not yet in 1.13.2+.
So for now you can work around the issue by using for example 4 (or even 9 or 16) different sub-regions in the selection, that will cut down the size of the backing array, as each sub-region is saved separately. Also if possible you could try to cut down the size even more by using less tall boxes for the base terrain, and if there are tall castles/buildings/etc then capture just those over the base box with their own separate sub-region boxes, to avoid huge volumes of just empty space in the main boxes. That will both cut down the file size and the in-memory size of the schematic, and also help a bunch with the performance when you go and load the schematic later, as those massive empty areas don't have to be copied to the schematic world and tried to be rendered.
oh ok, I get it... so while the "index handling bug" is fixed, use separate subregions for big schematics, right? That would be no problem, although this is weird, because before creating that schematic, I was saving many subregions before and one of them was wider, I believe, but not as tall as this one, and didn't get any errors nor crashes... maybe because it wasn't as tall as this one I suppose... anyways, thanks...
I believe the bug is related to the total volume of the sub-region, not to any one dimension of it. But I can't remember the exact details of it anymore.
And using multiple as small as possible sub-regions is always recommended (for moderate to large scale schematics at least) due to the reasons I explained, not just to work around this bug. Of course it does not make any kind of real noticeable difference in smaller schematics that are only like some 10-30 blocks in total dimensions, and in very small schematics using a dozen sub-regions that are like 1-4 blocks each is most likely counter-productive already. But even in such cases, if it's for example a technical contraption with multiple different logical parts, it might make sense to use sub-regions, as it allows you to turn on/off parts (any of the sub-regions) of the placement, or move or rotate them relative to everything else.
I get your point, and it's logical, there is no point in creating a schematic with mostly air blocks, but on the other hand making many subregions are a bit tedious... I'll still follow your recommendation but how about this:
air blocks
are being saved as individual blocks, right? wouldn't be better to ignore those? (I'm just speculating, idk if you already thought about that)anyways, thanks... next time I'll create smaller subregions...
Subdividing an area seems like a good feature, but I think I'll do it as a manually triggered feature, so that you can click a button and it will subdivide the selected sub-region box, probably giving you a small popup to select how to subdivide it, or something like that.
The schematic format Litematica uses basically has an array of blocks, so each position within the area gets saved to that array, you can't leave out any positions. The vanilla structure block format on the other hand saves a list of blocks, and each entry contains the block type and the position, so in that format you could leave out air blocks. But on the other hand that format is WAAAY more verbose and space-inefficient per position. Because the array in Litematica uses a palette-based bit-packed format, where each block position uses an amount of bits per entry that depends on the total number of unique block states within that array/sub-region. Whereas the vanilla format stores I think 4 int tags inside a compound tag for each position... (all contained within a list tag)
But I might also add more optional "sub-formats" in the future, maybe a sparse custom format of some kind, and maybe also an RLE based format of some kind. But after that array handling bug fix arrives in 1.13.2+ versions, the current format will take you pretty far as well (in regards to the maximum area size), although the memory requirement for a maximum size sub-region would be around (2^31 - 1) * 8 = 16 GB. I believe the maximum dimensions of that sub-region (unless I made a mistake), assuming the region contains ALL the current existing block states in 1.16 (17 112 states), is 5982 x 256 x 5982.
But also one thing to keep in mind is that Litematica is not meant as a world download type of mod, as the schematic is always saved in one file and has to be loaded into memory all at once. There is a separate World Downloader mod for use cases where you want to just download everything in the world (within the client's loaded area) into a local copy: https://github.com/Pokechu22/WorldDownloader/releases
oh ok I get it... I just wanted to save the spawn place, it's easier for me to be able to place a schematic than having a secondary world with what I need... that other mod, is it for Fabric as well?
Now, on the sub-region feature, I have some ideas:
Z
|#########
|# #
|# > # so if I'm here inside a region pointing at X+ and right click on any block in that line...
|# #
|#########
|_________ X
Z |######### |# # |######### the region will be divided there... |# # |######### |_____ X
Z
|#########
|# V # And if then I point towards Z- after creating that subdivision, while holding the "action key" (don't remember right now how was it called, in my case I press the Alt key) and scroll that way, the subdivision will move that direction
|#########
|# #
|#########
|_____ X
Z
|#########
|# V #
|# # like this...
|#########
|#########
|_____ X
- for Y subdivision it could be a secondary tool mode where you just click on the block height where you want to create a subdivision...
- the creation and modification of subregions could also be made in the litematica menu, just like when creating a region you give both corners, this time you would give the value and axis where to create the subdivision
- so subdivisions could cross between them... finally when you decided your subdivisions, you press a key or something to create the subregions, the subregions' name could be the main region + sequential number of regions, and boom, subregions created... on top of that, before creating the subregions, you could add an option to "cap" the max and min Y height to the highest and lowest non-air block inside the subregion (could be also for X and Z axises), that way subregions won't have so many air blocks stored, this could also be of use if somehow after subdividing there are subregions with air only, in that case the subregion won't be saved/created if the option is enabled... it should be an option because sometimes, in my case, I use the air blocks space to help me to know a determined height when placing the schematic, then I enable the option to not place air blocks...
2. given the selected big area, create subregions that have not been naturally generated... I really don't know if this could be done client-side, the only way it comes to my mind mind is to give the seed to litematica, that way it can know which part were naturally generated and which part weren't... this mode would enclose each region on the 3 axises, even if it is underground... although you'll have to set also the max space between blocks to create the subregions, otherwise it will create a subregion for each block or all the subregions inside 1 region, that could also be useful... idk, I just believe that this could be a really good idea...
3. path dividing... almost the same as the first one, but instead of placing each subdivision, create the subdivisions given a path... similar to WorldEdit poly selection method, click on the vertices points of the path and create the subdivisions according to that path, so if you do a L shape path, it will divide the region in 4, because the subregions can only be box-shaped...
well, that's what I can come up... also, is it possible to be able for the regions be sphere shaped or poly-shaped? that's the only thing that I sometimes prefer using WorldEdit... but anyways, thanks for answering... I hope I could be of help...
To me this seems like an extremely complex system that probably only like maybe a dozen people would ever end up actually using. And it would probably take tens if not hundreds of hours of development time to implement and test and debug all of this. So I don't think it's worth the development time and the added complexity in the code base to add this many options on how to sub-divide things.
So I think I would just go for the simple automatic sub-division on a given sub-region, based on either how many boxes you want per axis, or what should be the maximum size of each box. And another thing that might help is optionally capping the manual tool selections to not overlap with other existing sub-regions, it could speed up the process of just manually selecting stuff and creating sub-regions that are side by side but should not overlap.
oh ok I understand... then... what about at least add an option to automatically shrink regions up to the farthest non-air block in the given axis? or to expand to the farthest non-air block in the given axis? or at least only in the Y axis... that could be something many users could be using... 🤷🏼♂️
Hmm, there are already the selectionGrow
and selectionShrink
hotkeys that do those grow/shrink actions on all axes. But there isn't current a way to lock any of the axes in the area selection boxes, only in the placement configuration you can lock the origin axes to be able to just move on one axis for example. So using that same axis locking system for the selection boxes would be easy enough I think.
I was saving a schematic on a server with this dimensions: 1024X x 1024Z x 192Y
corner1:[-512,62,-512] corner2:[511,255,511]
, pretty big, just doing a backup of the spawn (I've noticed that litematica keeps some block's rotation while WorldEdit doesn't) and got a #crash:why was it? memory issues?