GotoLink

Simply make sure you are only MinecraftServer#registerTickables on server side. Besides, you have @EventHandler annotations in your proxy class. They should be restricted to your @Mod class. And please don't use EntityRegistry.findGlobalUniqueEntityId() You do not need a global entity id.

Are you trying to call it on client side ? You shouldn't. Also fix this: @Override public void update() { List<EntityPlayer> players = Minecraft.getMinecraft().theWorld.playerEntities;

Not if you rely on the "generated" item model. That depends on the texture itself, where each pixel is made into a cube. Which would be pain to make into fixed json model. But if your item model is already fixed, then yes, you can do the same architecture of json files as the blocks do.

It does this because the constructor is missing. Explicit constructors need to be defined by the child class. See Java constructor rules.

The question is about 1.8, which only got minor versions following it. Thus minor code change which shouldn't affect any mod. (Method/Field renaming is MCP noise, which ForgeGradle covers up) Though if some code changes prevent the mod from working, you could always surround the version specific code with MinecraftForge.MC_VERSION check.

I would recommend [1.8,) As version range, since 1.8.0 isn't rigorously 1.8.

CanHarvest is whether the block drop itself. All blocks are breakable by any item, except bedrock. If you return false here, the default "innefficient speed" value is assumed. GetStrVsBlock is the speed of breaking. Return 0 would make the item not break.

You are not registering the item instance you used in the recipe. Having the same name isn't going to magically link the instances. Here the items used in recipes are of Item type, while the items added in registry are of ItemModSword type. Solve the inconsistency.

If you have client values, read and used by the clients... They should stay on client side. Never into the world data, which is server property, including item NBT. Write the client stuff on the client config file. Now if the server use values, the defaults should be from the server configuration. Because there may be no client connected. If the client need to know about those values, the server would send them through packet at appropriate time. Let say there is a value such that both sides care about. Server config contains "X" as default, sends it over to client. ->X | X (both sides) Client config applies a "client modifier=A" on it: ->X | X*A (use it for its own purposes) User makes a modification "+" in GUI. ->X | X*A+A (temporary client side evaluated expression, based on client config) Client send "+" packet, (contains GUI id and other stuff for identifying source) server receives "+" packet and applies its change. -> X + 1 | X*A+A Server may need to send back an update (could be same packet as first time), just in case... -> X + 1 | X + 1 Which client config still apply client modifier on before use -> X + 1 | (X+1)*A etc. In summary: "A" is never sent over the network. It is kept by the client side data (in config file, probably). "X" is sent by the server to the client. It is kept by the server data (in world save, probably), send by packet to client. "+" is an operation known to both sides (or only server, in which case update packet is mandatory everytime). It is not data, and is thus not saved by either. Client to server packet will ask server to perform "+" operation on its value, based on mutual agreement of the code needed in the packet to identify as "+" operation, such as channel name. "*" is a client side operation. Server doesn't care nor understand.

If you have 3 block instances, you don't need to have this PART property registered at any point. #getMetaFromState need to reflect #getStateFromMeta Note you use EnumRailDirection states. There are 10 of those, and you probably don't want all of them. Checkout those you don't need, like in BlockRailPowered.

Please understand that the event is posted for each element type, with different rendering state. If you cancel the event with element type == ALL, NOTHING is rendered. You can cancel any number of them, but you need to choose ONE element type to render ONCE. See GuiInGameForge to check the rendering states.

That is an interface. What the hell were you thinking ? Just stop using #All methods,and # All fields config. You should specify what you want to change, each field, each method; and understand what is going to happen.

Problem here: IBlockState disblockstate = world.getBlockState(blockpos); world.setBlockState(blockpos, disblockstate); Those lines change nothing.

Hum, that forge jar is called "custom.jar". I find it suspicious. Though this error can be due to mods not being thread safe in their packets handling.

-Break statement missing -Actual generation lines missing -Swapped dimension id between End/Nether

Only use DecorateBiomeEvent.Post ?

Add them as libraries to your module. FML will load them.

You see the log that says "missing texture xx" ? Post it.

All noiseGen# and noise# fields are null.

The boolean in #func_149851_a( is equal to "world.isRemote". When true, (client side), the other functions won't get called. Basically a convenience feature if you want to add particles or whatever. See Block#canSustainPlant(IBlockAccess...): #getPlantType(World...) is also checked when #canPlaceBlockOn(Block) returns false. You might want to override one of those two.

I'd say build a local Forge version, eventually remove the part for maven deploy from your "build.gradle" file. Then install your Forge version manually, by placing into .minecraft/libraries/net/minecraftforge/... If you edited the version number, you'll have to edit or create a profile into the .minecraft/versions/ folder. If you really want to make an installer too, then you'd need a remote repository for your build.

new ItemBow() You are creating a new item instance. The game doesn't know what it is after reload. Thus the info gets discarded. Use "Items.bow".

@Override public int getColor(ItemStack item) { return 9846527; } That is a fixed number. Did you look at ItemArmor ?

Known issue. https://github.com/MinecraftForge/FML/issues/548 I'd blame Mojang or wait for 1.8.1.

You have load of errors in your client logs. Two critical from Resonant engine, and UniversalElectricity. I think you are lucky this can load a world at all. You could also try without MultiMC launcher.