Draco18s

Show your ModEntities class. Also, your common proxy should not be the same. For two reasons: 1, you can't call super from the base class, 2, you shouldn't be registering models in it.

Caused by: java.io.FileNotFoundException: bcaetherfood:models/item/blueberry_leaf_tea.json Caused by: java.io.FileNotFoundException: bcaetherfood:models/item/blue_jellypop.json Caused by: java.io.FileNotFoundException: bcaetherfood:models/item/kirrid_broth.json Caused by: java.io.FileNotFoundException: bcaetherfood:models/item/carrion_petal.json

It doesn't matter when you register an event handler. As for the annotation, that's only true for static event handler methods.

Do you know Java? You don't call super in the super class, you call it in the subclass. i.e. the client proxy.

Registry events specifically fire between preInit and Init, so you would have to register your event handler during preInit. Registering Things The recommended way to register things is through the RegistryEvents. These events are fired right after preinitialization http://mcforge.readthedocs.io/en/latest/concepts/registries/#registering-things The @ObjectHolder annotation is what handles that. Specifically. If the @ObjectHolder points to an item that is not part of your mod (e.g. another mod's item) it will be filled without you having to create a JVM-class-load-based dependency on that other mod (i.e. get its source code into your dev environment).

No, because of the need for both a common side and a client side (how would I register the item models only on the client when all the methods are static?)

http://bfy.tw/DqFx

Oh, sure. Absolutely. You could even register it as a static class and bypass the static -> instance redirection methods. The first one is static so I can reference it as EasyRegistry.registerItem, that method then calls Hardlib.proxy._registerItem

I have them set up that way because of what the EasyRegistry is supposed to do: register stuff in a way that doesn't require I, the modder, to have to do much work in my main class: its flexible, its powerful, it makes distinctions. The interface-and-separate-classes makes more sense for a traditional proxy system because anything that would be in a "common" proxy should be in your main mod class.

The annotation on the class is for static method event handler. Otherwise you have to register an instance manually.

Yes. Create the class and register it as an event handler. Job done.

Blocks work the same, except: You use the RegistryEvent.Register<Block> event. You have to create an ItemBlock instance of your block and register it during the Item registration event if you want the block to appear in the player's inventory at all. Models need to be registered during the ModelRegistryEvent and you call ModelLoader.setCustomModelResourceLocation(...) there. This is client-side-only. Proxies are how to distinguish between the physical client and physical server (the client, running single player, has an integrated logical server). You need two classes, a ClientProxy and a ServerProxy that both can be assigned to the same field in your main class, annotated with @SidedProxy It is recommended that you use an IProxy interface as the common type.

1) Not currently. However, this works: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/EasyRegistry.java#L210-L222 2) Not sure what you mean, but feel free to take a look at some of my criterion https://github.com/Draco18s/ReasonableRealism/tree/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement

The mcmod.info file isn't used for this, your @Mod annotation is. dependencies = "required-after:backslash[$version]" So you'd put 3.0.0, for $version. Include the ,

Color c = new Color(96, 149, 234, 1); GlStateManager.color(c.getRed(), c.getGreen(), c.getBlue(), c.getAlpha()); Um...why are you creating color objects at all? GlStateManager.color(96, 149, 234, 1); ? Also, I'm pretty sure 1 alpha is basically invisible.

That does not do what you think it does.

I was pointing out how to fire the event, not providing the entire solution

Whiiiich is what I suggested...

Event event = new BlockEvent.HarvestDropsEvent(...); MinecraftForge.EVENT_BUS.fire(event); event.getDrops()

The client takes input, converts that to motion, and sends position updates to the server. Yes.

BlockBreakHandler is not a Forge or vanilla class. We need details.

Sigh. public static final PropertyDirection PROPERTYFACING = BlockHorizontal.FACING; Magic, you're done here. The property already exists, utilize it.

This is due to the fact that the client does not inform the server about it's position change every tick, but rather once every couple of ticks.

canUpdate()