Draco18s

Look at wither skulls

Pretty much all of those are pre-init. Registering blocks, items, entities, and all renderers must occur in pre-init. Recipes can be done anywhen, as can events.

Can you show the whole class those two lines belong to?

Radius, by the way, is entirely based on the power. http://minecraft.gamepedia.com/Explosion#Effect

Or to be more specific: The server might not even know what a keyboard is.

1.7.10 is 2 years old, no help will be supplied on this forum. As soon as diebiesen07 finds this thread, it will be locked.

Override canConntectTo

Reflection only incurs the overhead for getting the field. Save a reference to it and reuse it. The invoke and get/set stuff the JVM optimizes pretty damn well.

You're going to need to hardcode those names in some manner: the strings must exist in the code. At best you can concatenate the metadata value with the block's general name and then localize it. e.g. "minecraft.blockstone_1" and "minecraft.blockstone_2" Which would be your previous post of converting the metadata from an integer to a string (just concatenate it onto the end of the result of getUnlocalizedName). Or better yet, override getUnlocalizedName to do that for you.

You shouldn't be using Access Transformers anyway. Use Reflection instead.

All variants will have exactly the same name unless you, personally, did something to change that. Did you?

It's deprecated because it's slated for removal. Not deprecated because it doesn't function.

Yes. And you know what you can do? Block#getMetaFromState(IBlockState) Gasp. Shock. Awe.

1.7.10 is not supported here. That said, why are you using the stack's item's unlocalized name to insure that you're setting the correct stack's NBT? There is only one possibility: the item that the player is holding is the item the player is holding. One of the things you need to do, though, is provide a zero-argument constructor to your IMessage class (how else would the server create one?) second, don't put the IMessageHandler inside the IMessage class. Create two sparate class files: it's possible you've goofed something up in doing it this way. Third, you probably should send more generic messages than trying to send the NBT data. This is rife for letting the client dictate rules rather than client asking the server "can I do this thing?" and the server handling the rules.

Also don't use GameRegistry.registerBlock, it's deprecated for a reason.

block.getBlockState().getValidStates();

Negligible. One entry that isn't used costs ~64 bytes worth of ram, plus the size of the string (one byte per character).

Nope. You could add useless entries, but there's no comment delineator.

You can't use client side code in common code. You must move that stuff to your client proxy. Also, you must use ModelLoader.setCustomModelResourceLocation https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/client/ClientProxy.java

Read the javadoc when you hover your mouse over the method.

http://lmgtfy.com/?q=distance+between+points

itemRender(magGlass,0,"ItemMagGlass.json"); HEAVY SIGH just use Item#getRegistryName(). It comes pre prefixed with your mod ID. You also don't need the ".json" the resource location class handles that for you already.

If there is, I'm not aware of it. The right-click method has always given me a little bit of trouble keeping things synced (dates back to the first time I started using it), so the only way to be absolutely sure is to use packets.

The particles on an actual entity, like a player originate at the bottom middle of the feet on something like a player using the posX, Y, and Z that I mentioned before. I can statically add to the previous comments, like doing poxY + 0.5F ( to move it up a bit) and posX + 1.0F (to shift it over), but those are static. When a player or skeleton turns around, the particles stay in the same static place. I wanted to see if there is a way to rotate that particle with where the entity (in this case, skeletons) look to keep it centered in the forehead. This post boils down to, "yes, I want them to originate at an offset, and that offset rotates."

Ok, if it has if(!world.isRemote), then it should only run on the server and do nothing on the client at all, even if the method this is contained in was client-side-only (in which case, nothing would happen on the server either, because it would be unaware and the if-statement prevents the client from doing anything at all).