Draco18s

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()

You can still get the current value in the way that D7 said when drawing the hud.

No. Because you're bypassing the block-break system in PlayerInteraction.java

Yes. Do whatever it is you're doing on the server thread. If you can't, then no, you need packets.

try {EntityPlayer p = Minecraft.getMinecraft().player; You're doing everything on the client. The server then synchronizes everything and overwrites your changes.

Show more of your code. There are several reasons why this might fail, but in order to determine which one of those it is, we need to know where this code is.