Choonster

There's an invalid character on line 1 of config/MoCreatures/MoCSettings.cfg. Either delete the character or delete the file completely and allow it to be regenerated.

You've cut off part of the crash report. Post the full thing.

Binnie's Mods don't work with Forestry 4.x yet. Either disable Binnie's Mods or revert to Forestry 3.x.

No, but you can use the vanilla lever's blockstates file as an example, just split the model and the rotation: define the model as either a default (single model) or based on the appropriate property (multiple models like the lever) and then define the rotation based on the facing property.

You don't have CoFHCore installed.

Have you tried looking at BlockLever ? It uses its own enum to describe the possible facings and sets the facing from Block#onBlockPlaced when it's placed.

You're only registering your items in ClientProxy , which means they're not registered on the dedicated server. Keep all block, item, entity, etc. registration code in methods called from your @Mod class so the code is run on both sides. Blocks, items, entities, etc. should be registered in preInit, recipes and ore dictionary entries should be added in init. Keep all model and renderer registration code in methods called from ClientProxy so the code is only run on the client side.

It should be okay to save the EnergyStorage in the root compound tag or a nested compound tag. It's not a slot, it doesn't need a slot number.

Iterate through Potion.potionTypes until you find a Potion that returns the specified name from Potion#getName . You'll probably want to do this once at startup rather than every time you apply the effect.

Thog has a 1.8.8 fork of NEI here, but I have no idea what state it's in.

For 1.8 and earlier, you can install the deobfuscated versions of CodeChickenLib and CodeChickenCore to deobfuscate other mods at runtime; allowing you to use regular obfuscated mods in the development environment. Unfortunately ChickenBones hasn't ported them to 1.8.8 yet.

Block#isAir is a method added by Forge. Presumably it takes parameters so mods can base the result on some property of the location (e.g. blockstate/metadata, TileEntity value, per-world or per-level values).

Looking at the vanilla compass rendering code, it looks like most of your current code should still work with a few minor changes. Just use the TextureAtlasSprite 's ResourceLocation as the texture of your item model. You'll want to look at RenderItemFrame#renderItem to see how the vanilla compass is rendered in item frames and use it as the basis of your RenderItemInFrameEvent handler.

This happened because LandDefender couldn't establish a connection to its local SQLite DB for some reason. Unfortunately it suppresses the exception that explains what went wrong and prints "Exception in establishing database connection" to the console when this happens (which doesn't tell anyone anything useful). It looks like the author fixed a similar issue in 0.2.1, you may want to report this again (and also tell the author to use FML's logging system and log the exception when something goes wrong).

You're writing every ItemStack to the same compound tag, so each slot is overwriting the previous one. You need to write a list tag containing a compound tag for each slot's ItemStack . Include the slot number in each compound tag, skip any slots with a null ItemStack . Look at how TileEntityChest saves and loads its contents.

It looks like you're still calling EntityRegistry.registerGlobalEntityID , don't do this. This method registers the entity class with the name you provide (i.e. horror ), but if you only call EntityRegistry.registerModEntity instead it will prefix the name with your mod ID (i.e. jm.horror ).

I've been trying something similar to that, however it just crashes my minecraft whenever I toggle my mod. @SubscribeEvent public void onPlayerTick(TickEvent.PlayerTickEvent e) { if (AutoClickerKeyBind.isOn == true) { //FMLClientHandler.instance().getClient().playerController.attackEntity(thePlayer, objectMouseOver.entityHit); mc.getMinecraft().playerController.attackEntity(mc.thePlayer, mc.objectMouseOver.entityHit); } } In future, post crash reports if your code is crashing. Knowing what the error is makes it much easier to find the solution. In this case, TickEvent.PlayerTickEvent is fired on both the client and server threads. You should check world.isRemote to make sure you're only attacking from the client thread. The event is also fired twice per tick, so check the event's phase field and only attack in one phase.

Do not use EntityRegistry.registerGlobalEntityID . It's completely unnecessary and will break things if you run out of global IDs (255 is the max and vanilla already uses a lot). If you use the overload of EntityRegistry.registerModEntity with the two additional int parameters, it will call EntityRegistry.registerEgg for you (using the two int s as the background and foreground colours of the egg). It looks like you're never actually calling the methods of EntityRegisterHorror from your main class. Side note: you don't need a separate registration class for each entity type. Are you sure the entity isn't being summoned or is it just not being rendered? Put a breakpoint in the EntityHorror constructor and run Minecraft in debug mode.

Not all mobs use the new AI task system in 1.7.10, some still use the old AI system. If you want to handle these mobs, you may need to manually execute their AI tasks from LivingUpdateEvent .

I explain how to simulate a right click client-side here (block that uses this, actual right click simulation). GameSettings#keyBindAttack is the left click (attack) key binding.

FMLNetworkEvent.ClientConnectedToServerEvent is fired on the client side when you connect to a server (integrated or dedicated). When this fires, you can use Minecraft.getMinecraft().getCurrentServerData() to get a ServerData object describing the current server (including its IP/domain). I explain more about this event and the ServerData class here.

Don't use metadata values yourself (the whole point of the blockstate system is to abstract away metadata), get the default state of a block ( Block#getDefaultState ) and then set each property to the desired value (chain IBlockState#withProperty calls). Your Block#getStateFromMeta implementation can be simplified: comparison operators like == already return boolean values, you don't need to use a ternary expression here. Consider using the != (not equal), > (greater than) or ! (not) operators here.

public YourBlockClass() // Constructor of YourBlockClass { super(Material.rock); setDefaultState(blockState.getBaseState().withProperty(SOME_PROPERTY, someDefaultValue).withProperty(OTHER_PROPERTY, otherDefaultValue)); }

That should work, but I have a few minor nitpicks: Name your variables properly. type isn't a type of any kind, it's the value of the LIT property so call it something like lit or isLit . Use raw primitive types (boolean ) rather than boxed primitive types ( Boolean ) when possible. Generic type arguments require boxed types, but Java will automatically box and unbox primitives as needed. See this page for more details on boxing. There's no need for the parentheses around the returned values, you can have any amount of whitespace between return and the expression. You can convert the if statement to a ternary expression.

Block#onBlockActivated is called on both the client and server (like most methods). You can't store mutable data in fields of your Block or Item classes, these are singletons so only one instance of the class exists per block/item type. Any changes you make will be shared between all occurrences of the block/item. You need to use the block's IBlockState to store the activated state: Create your properties (using the IProperty implementations) and store them as public static final fields Override Block#createBlockState to return a new instance of BlockState , using this and the properties as constructor arguments Override Block#getStateFromMeta and Block#getMetaFromState to convert between the IBlockState and metadata Use blockState.getBaseState() to get the base state, then chain IBlockState#withProperty calls to set each property's value before passing the result to Block#setDefaultState in the constructor to set the default state You can use IBlockState#getValue to get the value of a property and World#setBlockState to change the state at the specified position.