Would it be possible to run a last pass on chunk generation to remove any tree bits left over from meteorite generation, ideally including ones partially hit? Instead would it be possible to move the generation to before trees populate? Even if the removal was visible, like you could see the blocks break as you got near, it would be an improvement to the broken tree fragments that remain at many meteorites.

another option would be changing it to a set of biomes which could then give you (i'm guessing) much much more control over when and how it generates, like having the trees be affected differently as you get further from the crater; no trees, then fallen down trees, then trees with no leaves, and then normal trees. it would require making at least a few different biomes however, which could be more work than you want, i don't know.

a semi-related feature suggestion is that you could have two or three types of craters, recent and old (or a third variant, ancient), old having all its trees regrown and some more weathering (ancient being ideally so weathered you don't notice it at first), but the three types having different loot, so you need to find a rarer more recent meteorite to get the diamond tier press (or other high tier items/presses, maybe netherite shrug) or even gating the mid tier press. or have old be most common and ancient and recent both similarly rarer and gating different items each. and i'd guess that you could have the biomes pick the type of crater (not whether it's a forest or plains or whatever) in a deterministic pseudorandom way so you only have one biome type instead of needing to change the individual biome likelihood (and let other mods that control terrain gen override it), though maybe that would be more headache than it's worth.

since it is an upwards sliced alorithm, an upward facing depth search for solid blocks would not be sooo expensive here at all!
just add in another case into the height condition to do one more block search and if a solid block is encountered, do an depth search upwards to remove all connected blocks which are inside the crater radius (x,y) ... using a depth search would skip most of the air blocks but i am not sure if this would be more effective than simply looping upwards

the only thing i need is access to my PC this evening and maybe a hint on how to setup the dev environment for current minecraft, then i could take a swing on a PR

as far as i know, the meteorite spawn is done post chunk generation, so the second solution would most probably not work or requires a whole new concept

the only thing the meteorite spawn does, is removing blocks and adding the meteorite blocks (and a tiny bit more in desert biomes)

a new biome would also have the issue, that it won't blend ito the surrounding biome

yeah it would require a snowy variant, a hilly variant, a mountainous variant, mesa, plains, etc, for all the major types of biomes, subbiomes and ones it matters less (flower forest etc)

thing is, i only rarely have issues with "bits of trees" in vanilla biomes, maybe a bit more often in jungles, so there is some room for improvement, but do you have a few screenshots on how bad it is on your side?

i unfortunately do not have much of any java modding experience, i think i followed a tutorial for 1.12.2 a couple years ago but never did much with that, and i haven't worked with java in a year maybe two, but i would be interested in helping if i wouldn't just be slowing things down to get me into it as a newbie. though i could help with testing or texture art if that was needed

one sec

out of my head i would add a depth first neighbour check when a block gets deleted with a downward bias, if there is something tagged wood, follow recursively neighbour blocks with downward orientation (followed by sideways until an absolute coordinate limit is reached) to look for ground connection and remove the whole chain of blocks with the same trigger active when it is floating

this would shave off a tree that is very wide until it reaches a "grounded" block of the tree without leaving major bits left

one could also incorporate algorithms from other "harvesting" mods to achive this maybe faster ... but have in mind, this will all take a bich chunk out of the world generation time

modded biome, this is a case where you'd probably have a compat mod that would add versions of the meteorite biomes because otherwise the trees wouldn't match up, a good reason why it might be not worth it to do it via biomes

and this is a case where it might not work at all, with mods that completely override the terrain generation, though maybe there would be workarounds

there's another picture that keeps failing on upload, and another crater that had some floating leaves decay before i could get a pic

yeah a scan for nearby blocks, either depth or breadth first could really eliminate the issue completely

might need to have some tweaking to make sure it doesn't take down an entire forest (slow and probably have really ugly flat cutoffs when it eventually stopped)

maybe take down more trees than needed, even if they were only slightly touched, and then possibly regrow new trees based on the biome (im guessing each biome registers the trees it generates in some way you could look up) or add in fallen logs using the wood types that generate there

just flying over the code i see it is a structure spawn now

so the code that's clearing blocks is mojang's or forge's, not ae2's, right?

nono i just was correcting my first comment, in the way older code, the crater generator was very "expensive" because it was removing stuff upwards all the way, but this seems to limit it's range quite hard ... i am a bit stoked i did not encounter more floating trees above meteorites like you do

i thought you were speaking of floating branches on the sides of the crater not above .... i am trying to get a grip on the geometrics on the code (it looks like it is going all the way up but i am just guessing until i can understand it)

ah ok. yeah in the years i've played with ae2, it's always been a thing to some extent. sometimes it'll just be a tree that's half gone, other times there's a ton of floating junk, unless there weren't trees to begin with, like plains, tho sometimes it does manage to do a good job. even in areas with large dense trees

i think the issue is in this part but i don't have a build setup to test around and i am generally bad at mathmatical algorithms :P so i need to see/debug how it works to get an understanding

yeah it looks like the else for the if/else inside that if on 173 is doing the clearing. it would likely be too much cpu hit to search for neighboring blocks on each pass through that else statement, but if you had an efficient way to only run a check for nearby blocks on the outer hemisphere, it would be significantly fewer checks required. another option would be to check a thin cyllinder of blocks tilted based on the terrain slope (which might not work on some locations due to saddle points or mountain corners), and then check each block for wood, and delete upwards for each, checking neighbors as you go

only doing the cylinder delete wouldn't work, because it wouldn't handle non-tree terrain above it, but maybe that followed by a slightly smaller existing delete (im not quite sure of the shape, i assumed it was a sphere above but i can't tell enough to be certain without spending too much time on that lol) would be faster than doing the check for neighboring wood on each or on just the outer blocks

from what i grasped so far the issue lies in the limiting of the height based on the radius, as the process of removing blocks is upwards in a sliced fashion.

removing the the condition for the height when past the lower half of the sphere would make it a cylindrical remove of blocks instead of spherical but i can not say anything about the expense of time to run up to ymax .. the old code made it an expanding cone with an angle and i guess that is why it was so expensive in the firt place but it was way more "realistic" ... maybe making the crater sphere way larger with an y offset could remedy the floating trees and make it look a bit better

yeah i'm sure it would take some trial and error to get an efficient method that also didn't leave floating bits

got the build setup so far but i seem to be missing the forge jar

Could not find forge.jar (net.minecraftforge:forge:1.16.5-36.0.15_mapped_snapshot_20201028-1.16.3_at_2d92e11e8a32d447337a315df680d80f83d52de5)

i thought this will be downloaded automatically with gradle?!

This is an artifact cause by the tree generation itself. Basically they can generate at any point in an already generated chunk.

There isn't really a way to fix it without constantly checking each chunk again and then trying to remove newly generated trees or forcing something like a recursive chunk generation, which will spit out errors to the log and everyone will start complaining about it because they don't understand it but anything written to the log indicates the world is ending.

Basically someone has to convince mojang or forge to fix their recursive approach for trees and no longer have it affect adjacent chunks.