As the title says there are floating branches and leaves (not removing itself) after a fire spreaded across multiple trees. I'm not sure if affected chunks unloaded and loaded again while the trees where burning.

I found a work around that seems to work well enough without having to resort to additional forge support.

Installed 1.12.2-0.9.1d and it's worse than before - floating things everywhere (before there was maybe 1 floating branch per 3 trees) :

What does this look like after a while has passed? A minecraft day after the fire has run its course for example? (just curiosity, would check myself but my employer won't allow MC at work for some weird reason)

Just logged back onto the server (chunks might have get unloaded in the meantime) and it's definitely much better:

Still a few floaters here and there, like these two blocks:

At the moment there's some weirdness about data not getting sent to the client during fires. In nearly 100% of the times the server actually destroyed the block but the client doesn't know. Logging off and then back in to the server reveals what actually happened.

I'm probably saying something stupid, but can't a "burning" state be added to the trees; if some part of it catches fire, it enters that state and checks if it is still connected to a root block, if not, it breaks.

I feel like it could be laggy, tho.

Fixed. The trackingRange of the falling tree entity was set to 32 blocks. What would happen is that the entity that destroys the blocks client side never appeared if the player was 32 blocks away from the break event. This has been extended to no longer be an issue.

Fire is a problem and kinda beyond my control. Forge provides no event for blocks that are set to air by a fire block. The result is that the tree networks become corrupted from having nodes(branch blocks) destroyed improperly.

I've known that I could substitute the BlockFire class with a modded one which would require a core mod. I'm not making Dynamic Trees a core mod.
I actually already have a custom fire block in the mod that runs a custom onBlockBurned event. It's a bit buggy since I try to replace fireblocks on the fly when it's appropriate. Of course I could replace all fireblocks as they are created but I have no doubt that it would cause compatibility issues with mods and code that checks if block == Blocks.FIRE. Also other mods that alter fire will suddenly be incompatible.
Making a PR to forge directly would be the way to solve it. The problem is that someone had made a PR that solved this problem a couple years back and it just sat there waiting to be merged. The requester updated it time and time again for each forge and Minecraft version until they got sick of it and just gave up.
So yeah. Probably not going to get fixed.

Hashtag JustForgeThings

That doesn't sound good. Is there really no event (maybe something you wouldn't expect, like some physics update event)? If not the only way I could think about fixing this would be to exchange the vanilla BlockFire class with a modded version (basically creating your own event). If you want to go that route it might require a core mod and/or ASM (mods like faster furnance might give a hinter how to exchange vanilla blocks) and you might want to make it configurable cause IIRC it's incompatible with i.e. LightLoader.

@V10lator If a modded BlockFire class would get made, then why make a coremod? Straight up PR it to the forge repo, as I can see this being useful for more then just Dynamic Trees.

Aside from that I feel like this is something that belongs to forge and is out of scope for this project. But maybe @ferreusveritas disagrees.

I actually already have a custom fire block in the mod that runs a custom onBlockBurned event. It's a bit buggy since I try to replace fireblocks on the fly when it's appropriate.

That won't work as i.e. there are cases where a fire block sets a neighbour block to air without setting it to fire first. What about an option to replace fire blocks when they are created? That would give the modpackers / endusers the choice for high compatibility or good fire detection.

I'll consider it. I don't like the idea of how unimplemented things in forge force me to rewrite more and more things that only cause more compatibility issues. I'd much prefer if it was done in a smarter way in forge.