Thanos' chunk trimming can be destructive to trees

[cyyynthia]

I doubt it's something that can be fixed easily, but I felt like I should at least report it considering I've seen it mentioned nowhere.

I've seen a lot of trees disfigured on Aternos while playing on a server with friends (especially when playing with biome mods which adds very large trees with organic shapes), which wasn't something I experienced on solo maps or on other servers. I made the hypothesis the optimization feature was the culprit, and after a bit of testing I confirmed this hypothesis.

Due to how Minecraft's generation works, blindly deleting a chunk can mess with certain parts of the generation, most notably trees. When they span across chunks, it doesn't actually matter for the game because neighboring chunks are already being generated, so it can just write to them and call it a day. However, if a chunk containing a tree was to be deleted, it would not be generated at the exact same spot again and the leaves that grew in the neighbor chunk would remain floating. Similarly, if a chunk containing leaves from another chunk's tree is removed, the tree will permanently lose those leaves.

One approach I imagine could help prevent this is making sure neighboring chunks aren't in a state where they may have generated things in the current chunk; but I'm pretty sure this would have quite a big impact on the effectiveness of the optimization.

[cyyynthia]

Here is a minimal reproduction map, generated on Minecraft 1.20.4 (vanilla), that hasn't been Thanos'd. The map has been generated by waiting for the generation to finish after spawning, running from spawn in a straight line for approx. 40 chunks, wait for generation to settle, and then save the world. To make the reproduction smaller I removed unnecessary region files; the reproduction chunks aren't near the boundaries anyway.

It happens to be a surprisingly good reproduction as it has both problems happening very closely to one another 😅

• The tree at 279 100 128 is an example of a tree that loses part of its leaves
  • Sometimes, a second tree is generated next to it; sometimes there's no tree it depends on the state of the random number generator I guess
• The leaves at 204 89 126 are an example of leaves that lost the tree they're from

thanos_repro_map.zip

[KurtThiemann]

I've definitely noticed this before and can look into it some more, but it is very much possible that this is not a fixable issue.
Hacks like checking if there are any leave blocks at the border to a chunk that isn't also deleted might work, but that would not really be a reliable solution and would slow down thanos to a point where it doesn't actually make sense to use it anymore.
I got some hope that this might not be a general issue, but maybe only has something to do with partially generated chunks (proto-chunks)? The issue would probably be far more common if every single tree on a chunk border would break whenever thanos deletes a chunk.

I'll take a look at your example map tomorrow or Monday. What view distance setting do you use in your Minecraft client?

[cyyynthia]

I used 12 chunks for the render distance.

And yeah I think the unfortunate truth is that it's something that can't be fixed without either tanking the performance of the tool, or being overly conservative and not delete enough chunks for the tool to have a meaningful impact 😔

The cases I've pointed out both occur with fully generated chunks (both the chunk from where the tree is, and the chunk being removed by Thanos)

[KurtThiemann]

So I looked a bit into it and think I know what happens.
If Minecraft generates a chunk that has structures that go inside another chunk, but that chunk has not been generated yet, a proto-chunk is created and information about the blocks that should be there is saved to the proto-chunk's block_tick list.

Once the chunk is actually needed, it is generated and the blocks from block_ticks are placed. If the chunk is deleted, there of course won't be a proto-chunk with a block_ticks list there, it will just be gone. Minecraft therefore doesn't place any additional blocks when the chunk is regenerated.
This is a bit unfortunate, since it means the only two options would be to either not delete any chunks that may intersect trees from other chunks, or try to generate new block_tick information when a chunk is deleted. Both of those options aren't really viable.

Checking whether there are leaves at the edge of a chunk might be (kind of) possible without actually parsing all block data by comparing the MOTION_BLOCKING and MOTION_BLOCKING_NO_LEAVES height maps, but there are other structures that are also affected by the same issue (like large mushrooms) that can't be detected this way.

We'll discuss this issue internally, but I think the most likely outcome will be that we'll add a note to the readme and our help center article and close this as wontfix. Thanos is optional in Aternos, so it can be disabled by users who'd like to avoid these artifacts in trees.

[cyyynthia]

That's a very understandable, albeit sad, outcome. A mention in the help center is still a good thing, so at least there's an explanation for those quirks. I guess the only "proper" fix would be to perform this at the game logic level rather than externally, to collect/use extra metadata allowing to handle this seamlessly; but given how flexible Aternos is with server software that runs I doubt that's any easier...

Thanks for looking into it anyway!

[KurtThiemann]

I added a note to the README and our help center articles.
Thanks for bringing this issue to our attention!

[ILYAGVC]

I have a solution.
If a tree (or any other entity) exists in two chunks, when one of the chunks is deleted, the remnants of the entity should be removed from the remaining chunks as well.

[JulianVennen]

Trees are not entities, they're just a bunch of blocks. There's no way for thanos to determine what's supposed to be the rest of the tree

[ILYAGVC]

Trees are not entities, they're just a bunch of blocks. There's no way for thanos to determine what's supposed to be the rest of the tree

I found an optimal and suitable solution, and it works.
I’ll be back after further testing!

[Helcostr]

There's no way for thanos to determine what's supposed to be the rest of the tree

Because there are tons of Modded minecraft mods that auto break leaves when no logs exist to keep the tree leaves alive, I don't think there is "no way"... just more convoluted...

[KurtThiemann]

It would technically be possible to remove the rest of a tree in a bordering chunk, but that would not fix the problem, it would simply make it less obvious. The core issue is that if the logs of a tree are in a chunk that is kept, but some of its leaves are in a chunk that is removed, the part of the tree that was removed is not created again when the chunk is generated again.
Removing the whole tree would make it less obvious, because you wouldn't see a broken tree, but it would still mean that there is a tree missing that should still be there.

A theoretical fix would be possible where whenever a chunk is deleted that borders a chunk that is not, all leaves that are somehow connected to a chunk border in that direction are recorded and added to a proto chunk that is created at that location. There are however, some issues with that approach:

• The issue does not only affect trees, but any small feature that is generated across chunk borders. Detecting leaves is pretty easy, but how would you detect if a block of sandstone is part of a desert well feature or just part of the ground.
• Modded (leave) blocks would not work, since there would have to be a hardcoded list in Thanos with all blocks that count as leaves
• Thanos would have to parse and write chunk block data, which would make it massively slower, and require updates for almost every new Minecraft update
• Thanos could no longer process chunks independently in parallel, because now the result for each chunk would directly depend on its neighbors

I don't think all of these tradeoffs would be worth it for what essentially is a small cosmetic fix. However, feel free to create an implementation in a fork.

[Helcostr]

Yep, I came across this same conclusion: which is why i focused on trees first, and thinking about thanos either as a plugin or a highly performant operation (using db caching and all).

Even with this horrible outlook, Thanos would still process in parallel, because Thanos isn't a chunk generator, but a chunk deletor: if I am not mistaken based on your analysis of previous chunk generation here are the following steps:

1. Check (or cache) chunk last access
2. Delete chunk via analysis.
3. Structures identified are saved in proto-chunks (prepared for minecraft's regeneration: this mean the chunk file will still probably exist, but at a smaller form only containing the proto-chunk information).
4. Proto-chunks neighboring another proto chunk can probably be deleted (once the structure generation has determined the structure is gone).

So we are processing the structures in paraellel, not chunks. But we still have a form of parallel processing.

HOWEVER

I think the actual true solution is to just use a different compression algoritm (LMZA is my dumb favorite, so please enlighten me if this is not a good idea) that would be space efficient at the cost of operational time: which basically is not the scope of Thanos, but rather a different plugin entierly.

Basically cold storage strategies.

And if we are adamant about deleting chunks, then storing a cache of structures during runtime is probably the smarter play, so that way the cleanup can cleanly identify structures (especially since structures are based on fixed generation, and do not expand or grow).

So Thanos is a pretty good tool, but being generalist comes with a cosmetic cost that might need to be rectified with more niche solutions.