Choonster

Your createBlockState method must return a BlockState with all of the block's properties. Yours only includes the FACING property, not the OPEN property. If you're extending BlockDirectional , you should use the BlockDirectional.FACING property instead of creating your own. If you need your own facing property, don't extend BlockDirectional .

One option is to actually create the entity without spawning it in the world, then kill it using a custom DamageSource that stores the position of the spawner (or the spawner itself). Subscribe to LivingDropsEvent and check the DamageSource : if it's from your spawner, cancel the event and add the loot to the spawner (or do whatever it is that the spawner does with the loot).

I just implemented this myself, it was a bit tricky to figure out. You can't just connect to the new server immediately, you need to disconnect from the current server first and then connect to the new server. When the player clicks the button, store the ServerData of the pending connection somewhere and disconnect them from the server. Look at GuiIngameMenu#actionPerformed (case 1, the Disconnect/Save and Quit button) to see how to disconnect from the current server. When the player disconnects from the server ( FMLNetworkEvent.ClientDisconnectionFromServerEvent ), schedule a task on the main thread using Minecraft#addScheduledTask (this event is fired on a Netty thread, so you must schedule a task on the main thread before you can safely interact with normal Minecraft classes). In this task, check if there's pending connection. If there is, call FMLClientHandler#setupServerList followed by FMLClientHandler#connectToServer (pass a new instance of GuiMainMenu as the first argument) to connect to the new server. You can see my implementation (a client command) here. If you're not targeting Java 8, use an anonymous class instead of a lambda for the scheduled task and Guava's Optional instead of Java's Optional .

Create a class that extends ItemBlock and overrides Item#addInformation . Register your Block using a GameRegistry#registerBlock overload that takes a Class<? extends ItemBlock> argument and pass your class to it.

If there's no compound tag at the specified key, NBTTagCompound#getCompoundTag will return a new one; but this new tag won't be added to the parent tag's map so you need to do this manually. I've written a basic example of this for 1.8.9 here. It should be mostly the same in earlier versions.

For a method reference to be used as an interface, the method must have the same signature as the interface's method. IRenderFactory#createRenderFor takes a single RenderManager argument and returns a Render , your method must do the same. Constructors implicitly return an instance of their class, so you just need to match the arguments. You don't need to create your own renderManager field, Render#renderManager already exists with protected access.

That should work. If you look at the player's NBT data after login at runtime or in the save, is your key present? Post your new code on Gist or Pastebin with syntax highlighting and link it here.

Have you installed CodeChickenCore?

The parentheses weren't part of the code. Just pass the method reference itself as the IRenderFactory argument, you don't need to explicitly cast to or specify that it's an IRenderFactory . registerEntityRenderingHandler(EntityNewMob.class, RenderNewMob::new);

If you're targeting Java 6/7, just create an anonymous class that implements IRenderFactory and overrides createRenderFor to return a new instance of the your Render class. If you're targeting Java 8, you can use a method reference to pass your Render class's constructor ( RenderMyEntity::new ) as an IRenderFactory instead.

BlockDynamicLiquid#isBlocked controls whether or not a liquid can flow into an adjacent block. Liquids won't replace a block if it's a door, a standing sign, a ladder, sugar canes, uses Material.portal or a Material that returns true from Material#blocksMovement . In this case, you just need to use a Material that returns true from Material#blocksMovement . This can either be an existing one or your own.

Once you've chosen a position to generate your ore at, you can use World#getBiomeGenForCoords to check the biome at that position. If it's the right biome, generate your ore; otherwise do nothing.

Did you try calling FMLClientHandler#connectToServer with a new ServerData object?

So would it be : Block checkID = world.setBlockState(new BlockPos(i, j, k), IBlockState.getBlock, checkID); I simply cant figure it out. IBlockState#getBlock means that getBlock is an instance method of IBlockState . Call it on an instance of IBlockState to get its Block . Use World#getBlockState to get the IBlockState at the specified position. You can think of an IBlockState as a combination of a Block and its metadata value. Use GameRegistry.registerWorldGenerator to register an IWorldGenerator .

Vanilla ores (and most Overworld mod ores) only generate in Stone, so you can use a different terrain block by overriding BiomeGenBase#genTerrainBlocks . You could also override BiomeGenBase#createBiomeDecorator to return a BiomeDecorator that overrides BiomeDecorator#generateOres to not generate any vanilla ores. This won't affect mod ores, though.

The compound tag returned by Entity#getEntityData is persisted through saves, but it's not copied when the player respawns ( EntityPlayer#clonePlayer ). Only the data in the EntityPlayer.PERSISTED_NBT_TAG sub-compound of Entity#getEntityData is copied over when the player respawns.

Call the super method from EntitySpectral#onLivingUpdate . If you override a method (especially one that updates stuff), you'll usually want to call the super method. You have a lot of overridden methods not calling their super methods.

One of your ingredients is either null or not a Block / Item / ItemStack . Put a breakpoint on line 225 of CraftingManager (where the HashMap of ingredients is populated) with a condition of itemStack1 == null and see what the value p_92103_2_[i + 1] is.

You're writing the NBT correctly, but this.entity will be null on the client, so you can't call Entity#deserializeNBT on it. You need to use EntityList.createEntityFromNBT instead, which creates the entity and then reads it from NBT. I just realised that Entity#writeToNBT doesn't save the entity's string ID, which is needed to recreate it from NBT. Use Entity#serializeNBT instead, which does save the ID.

An IBlockState will never be equal to an int . Use IBlockState#getBlock to get the Block represented by an IBlockState . There's no method called World#setDefaultState . World#setBlockState is the method you want.

I suspect that either Content.kingdom_key or Content.heart are null at the time of this method being called. Use the debugger to step through this method and figure out what's null . Make sure you initialise all of your items in preInit, then add recipes in init.

You should probably call the super methods in your overrides of Entity#readEntityFromNBT and Entity#writeEntityToNBT , but I don't think that's the cause of the issue here. I suspect the issue is that the server has a reference to the original entity when the spectral entity is first spawned and when it's read from NBT, but the client doesn't know anything about it. If you want to sync data from the server to the client when an entity is spawned in the world, you can implement IEntityAdditionalSpawnData in your Entity class. I suggest you use this to send the NBT serialised entity from the server to the client, then deserialise it back into an entity on the client side.

The crash report is the same as before, so it probably wasn't OptiFine screwing things up. I'm not too sure what's causing the error, you should probably report it to the author of ISM.

You should be able to use EntityList#createEntityFromNBT to create an Entity from a compound tag that was previously written to by Entity#writeToNBT . The Entity#isDead field isn't persisted. It's also public, so you can just set it to false when the entity is first reanimated.

The config directory will be in whatever directory Minecraft runs in, the same directory containing the mods directory. This may not be .minecraft. I don't fully understand what you're saying. What's not possible and why is it not possible?