Animefan8888

No problem, glad you got it working.

Did you use a custom IUnlistedProperty implementation and an ExtendedBlockState?

Yes, unless it is a vanilla registry in which ForgeRegistries.REGISTRY.

So the ultimate conclusion is that dynamic registration is not needed as one could register a single item/block for a single registry. Using metadata in 1.12 and lower and NBT/capabilities in 1.13+. And for blocks an IUnlistedProperty to store the Entry in a TE. I retract my dynamic registry approach.

Coremods are not supported on this forum, a moderator will most likely close this thread.

It is currently impossible to program as well, what I suggested allows for dynamic Block/Item Registries, based on other registries.

Then Mod B would be using the Registry wrong, because then they require the Item Registry to be ran again. Just to add their charms into the game. This isn't a flawed methodology of the system it is a flawed methodology of the user. Pre events would be used to modify future events in most cases Items and Blocks, while Post events are basically the equivalent to Item and Block events, but may also rely on Items/Blocks being registered.

The main use would be to register these entries based on Items/Blocks and Block/Item entries based on other entries, not registry A on registry B.

This is where EventPriority would take place, and if you need to react to another mod doing stuff then this should be where Loader.isModLoaded should take place and the modder would need to write custom code to interact with that mod.

A solution to this would be to fire the event twice, once before Item/Block Registration and another time after. Modders would just have to add an if statement to check the if it is Pre or Post, or make the registry event have a pre or post subevent. Though the first option would be the easiest to implement, while the second would be more efficient.

Blocks are registered first because of ItemBlocks, since they need a reference to the block. But you can instantiate your items in preInit and then your blocks can reference them, they just won't be registered.

Just use one of PlayerInteractEvent sub events to add a new rightClick for an item.

Use the debugger and find out what is null

What does the log say, it is the most useful in this situation, please post it.

Can I see the crash, kinda hard to debug without it.

I already told you the fix to this in your last post !world.isRemote, you should only spawn entities on the server.

But there are also modded blocks.

Only spawn the entity on the server, !world.isRemote Also, Or,

It is client side only code, the server need not know about the model. You will then call that client proxy method in your ModelRegistryEvent class.

This is not true, this will not work in all cases, blocks and items may have different metadata, and there are blocks that have more metadata than items, IE logs.

First off, are you trying to get the full drops of the block, or just the block itself? If the later Block#getPickBlock will return the block as an itemstack as it's respective type, IE oak to oak, spruce to spruce. You can get the raytrace result by creating a new instance from the data passed into the event. If it is the former then you should call Block#getDrops(NonNullList<ItemStack>, IBlockAccess, BlockPos, int) which will add the blocks drops to the NonNullList you pass in.

Block#getPickBlock(IBlockState, RayTraceResult, World, BlockPos, EntityPlayer)

No, unless your other right click events set cancelled to false. It seems that there is no way for this to happen with forge currently.

Have you tried setting the event to cancelled? event.setCanceled(true)

event.getSide() == Side.CLIENT Though this is assuming that your method of opening a gui is client side only.