TheMasterGabriel

You are a rare occurrence, as lots of people just try once, can't figure it out, and come back here in frustration. Thanks. As for that phrase, you don't need it. The Decorate event is not a cancelable event, so checking for receivedCanceled doesn't do anything.

You are playing on a recent version right? Duel wielding, no? As for client/server, this.

Oh, if you are doing something like that, then yes do what @diesieben07 suggested. Mind you should also check for invalid registry names and metadatas as well, if the file can be edited externally, just as an added measure.

That would probably hog resources, as you might unload/reload chunks several times. If they didn't unload, that would probably be worse, as your computer would be keeping multiple chunks loaded for 1 block in a completely different area. A solution might be to, if a world operation cascades into another chunk, stop and queue it for when that chunk loads. That way you wouldn't run into cascading chunk gen/loading, but rather have operations waiting to take place. I'm not sure about the feasibility of that, as I can already think of some instances where that wouldn't be ideal (like if you TE needs to check blockstates rather than set them), but I'm just throwing ideas out there for what could be a really useful PR.

When you set your item/block's registry names, make sure to add the modid as well. Not doing so will default the block to vanilla's json location (minecraft:block_banana), which you do not want. In your case, it would be 'examplemod:block_banana'. Forge usually flags mis-registered names as containing a dangerous prefix, so not sure why it didn't in your case.

What exactly do you mean by world gen functions? Like trees and stuff, or the physical terrain?

The easiest thing, in my opinion, to do is save the block state in a reasonable way, which would be serialized NBT data. Save the blockstates via NBTUtil#writeBlockState and write the NBT data to a file (I haven't looked into this whatsoever, but I can't image it would too difficult). Then when you want to compare them, for whatever reason you are doing, read the NBT data from file, deserialize it via NBTUtil.readBlockState, and compare them. Why are you doing this, anyway? Are you sure there isn't a better way achieving the functionality you desire?

You can also use this tool by @TheGreyGhost

DecorateBiomeEvent.Decorate gets called for all vanilla chunk decoration. You can listen to the event and cancel it if the EventType is TREE. Doing so will prevent all vanilla trees from spawning.

It would be helpful if you posted all your relevant code so we can see exactly what you're doing.

Use ModelLoader#setCustomModelResourceLocation, not the vanilla way.

It's also a good idea to, whenever generating stuff in the world, offset the gen position by 8 on the X/Z axes. If you don't, you could run into cascading chunk gen problems.

If could even look into Registries and Forge's RegistryBuilder, although it is probably not needed for your case. Something for future endeavours, perhaps.

Even if you could, however, it would probably cause chaos in the model system, as you could theoretically add a block property to a block after the model loads, which MC would not know what do with when it tries to render said block. So, I think you're restricted in terms of options: - Make the IProperty accessible via an API and have other mods use and implement it themselves, which you would need to check for whenever you wanted to do something with the block. (This doesn't help in editing vanilla blocks) - Abandon dynamic properties in place of something else - Manually add substitutions for all the vanilla blocks you want to change, via the GameRegistry#addSubstitutionAlias

If you were to implement something like that, you would need to ensure that the TE's world access is restricted to the chunk it is in. If you were to allow it to access block positions arbitrarily, then a modder could really easily overflow into an unloaded chunk, which would undoubtedly cause tons of problems. Edit: Also, did you try looking at ChunkEvent.Load? I didn't look into the load order that extensively, so you might run into the same problem. If not, however, you can probably use it, along with a list of TEs to be ticked, to get something that would work similar to your TE#onLoaded.