Choonster

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.

Have you got item models with those names in src/main/resources/assets/zylroth/models/item?

You installed a 1.7.10 mod on 1.8.8. Mods only work with specific versions of Minecraft.

You're using the same item model for every metadata value (the item's unlocalised name without the item. prefix).

PC worlds are 30,000 x 30,000. If your world is 256 x 256, something is very wrong. Screenshots and log files may help diagnose the problem. Use Gist to post logs.

Do you actually know Java? A solid understanding of Java is required to create mods. Pass the arguments of onBlockHarvested to the random class as method arguments, then do the same from the random class to the random event.

What I said before still applies: you have the world, position, blockstate and player as arguments of onBlockHarvested ; so pass whichever of these you need to the random class and then pass them to the random event.

You're using a 1.6.4 mod on 1.8.8. Mods only work with specific versions of Minecraft.

Then you already have the World the block was in, the BlockPos it was located at, the IBlockState and the EntityPlayer who harvested it as arguments of the onBlockHarvested method. Pass the required values to the code that handles the random events.

The OP has a second thread here, which Jabelar and myself have responded to.

You should be registering your blocks and items in preInit, then adding recipes in init. Don't register and add recipes in the same phase.

Your Eclipse crash report shows that you're running 1.8 rather than 1.8.8. ITickable was only added in 1.8.8. I'm not sure how you've managed to compile and run against different Minecraft versions.

You never create an instance of ItemMoneyWand , so its code is never used. Your onItemUse and onItemRightClick methods have the wrong signature, so they don't override the super methods with those names. Use the @Override annotation to ensure that your methods actually override the corresponding super methods - if it gives you an error, you haven't overridden a super method. Your IDE should have an option to automatically generate an override method, I suggest you use it. I wouldn't recommend overriding onUpdate unless you actually need to do something every tick. You should initialise the ItemStack 's NBT tag when it's actually needed - in onItemUse and onItemRightClick . Your onUpdate and onItemUse methods both create an ItemStack of MoneyModItems.itemMoneyDust , but neither of them use it. Your onItemRightClick method tries to add an ItemStack of MoneyModItems.itemMoneyDust to the player's inventory, but it doesn't check if the item was actually added; so it won't drop on the ground if the player's inventory was full like Buckets, Glass Bottles, etc. do. I told you how to do this in your previous thread.

I won't write your code for you. Learn Java properly before trying to make a mod. thenewboston has a series of Java tutorials . Vswe has tutorials on Java and modding here.

Full server and client logs (logs/fml-[client/server]-latest.log) may help diagnose the problem. Upload them to Gist or Pastebin and link them here.

You can deobfuscate mods using bearded-octo-nemesis. You can also download MCP mappings from the MCPBot website and manually look up SRG names (e.g. func_77637_a ) in the CSV files. If the SRG name doesn't have an MCP name, set up a 1.7.10 workspace and look at the method in your IDE. You may be able to figure out what its new name is by comparing the old and new versions of the class. func_111206_d is setTextureName (which no longer exists in 1.8 as it has been replaced with the model system) and func_77637_a is setCreativeTab .