Choonster

WorldSavedData is loaded on demand and should be available as soon as the World has been constructed, but TileEntity#readFromNBT is called before the TileEntity exists in any World .

Yes, it's called by Chunk#setBlockIDWithMetadata , which is called by World#setBlock . This is used to place blocks in the world by everything except the initial terrain generation ( BiomeGenBase#genTerrainBlocks ), which deals with raw Block and metadata arrays that later become an actual Chunk . No, the TileEntity is only created after Block#onBlockAdded is called. If you use per-dimension WorldSavedData , you can store the positions of each block instead of the TileEntity objects.

No. That's a static method that takes three arguments and does absolutely nothing. You need to call the getX , getY and getZ methods on the BlockPos you get from the MovingObjectPosition . Calling methods is a very basic concept in Java. If the ray trace doesn't hit anything, the returned MovingObjectPosition will be null . If it hits an entity instead of a block, the BlockPos will be null . This means that you need to check that the MovingObjectPositon isn't null and that it hit a block (the MovingObjectPosition#typeOfHit field is MovingObjectPosition.MovingObjectType.BLOCK ) before you try to get the BlockPos from it.

getBlockPos returning null wouldn't cause an error on that line. The error is happening because the value you're calling getBlockPos on ( objectMouseOver ) is null .

You can probably take a similar approach to the one I recommended in this thread.

Do you understand why that's causing an error and how you can solve this? That's definitely not right. I didn't tell you to copy-paste the methods and fields into your own class, I told you to call the existing methods.

This is a NullPointerException , which I explained in a previous post. How about you read that and figure out for yourself what's causing the error? We can't do all of your debugging for you.

That's one of the methods you need to call, yes.

On the server side, every EntityPlayer is an instance of EntityPlayerMP (or a subclass of it).

Vec3i has getX , getY and getZ methods that return the x, y and z coordinates respectively. These are getter methods, a very common pattern in Java. There's not much we can do to help you if you can't understand us and don't know Java.

I can't spoon feed you every piece of information. At some point, you're going to have to learn Java properly if you want to make a mod.

You need to extract the individual x/y/z coordinates from the BlockPos . How about you look at BlockPos and its parent class to see how that can be done?

ForgeHooks.rayTraceEyes returns a MovingObjectPosition . I explained how to get the block position from the MovingObjectPosition in the same post I told you to use ForgeHooks.rayTraceEyes .

ModItems.items is a collection of all of my mod's Item instances. Using Java 8's Stream API, I create a stream from that collection, filter out the items that have already had a model registered and then call registerItemModel(Item) for each remaining item. This registers the default model for the item, i.e. the inventory variant of the model with the item's registry name. The various overloads of ModModelManager#registerItemModel all boil down to registering the model with ModelBakery.registerItemVariants (so Minecraft loads it), creating an ItemMeshDefinition that returns a single constant ModelResourceLocation and registering it for an Item with ModelLoader.setCustomMeshDefinition (so Minecraft uses it for that Item ). This uses a single model for every metadata value of the Item . The various overloads of ModModelManager#registerItemModelForMeta all boil down to registering a ModelResourceLocation for a specific metadata value of the Item with ModelLoader.setCustomModelResourceLocation . This automatically calls ModelBakery.registerItemVariants . You don't have to, you can use regular item models in the same way (use multiple model paths with the inventory variant instead of a single model path with multiple variants). Forge added the option to use blockstates files for items a while back, so I wanted to try out the new feature.

If you look at the MovingObjectPosition class in your IDE, you'll see that it doesn't have blockX / Y / Z fields. The position of the block that was hit is stored in the blockPos field as a BlockPos object which contains the individual coordinates. Entity#rayTrace is a client-only method, using it in common code like Item#onItemRightClick will crash the dedicated server. Use ForgeHooks.rayTraceEyes to ray-trace a custom distance, always ignoring liquids or use Item#getMovingObjectPositionFromPlayer to ray-trace the block reach distance (default is 5.0), optionally ignoring liquids. Like regular entities, weather effects should only be spawned on the server (when World#isRemote is false ). Don't bump your thread, especially if it's still on the first page. People will respond when they have something to say, bumping will only annoy them.

A NullPointerException means that you tried to call a method or access a field of a null value. If you look at Item#getDamage (line 939), the only value that's having a method called or a field accessed is the stack argument. Item#getDamage is being called with null as its argument from LMLimoniteSword#onItemRightClick (line 26).

You're trying to set a field of this.rightarm before you assign it a value, so it's still null . This causes the NullPointerException . To be honest, your code is a mess; it looks like it was generated by MCreator or a similar program: You have a bunch of random methods all over the place, some of which are doing absolutely nothing. You don't have a clear separation between common and client-only code. You're using global entity IDs and manually adding spawn eggs. Just use the overload of EntityRegistry.registerModEntity with the two additional int arguments and an egg will be added using those as the background/foreground colours. Global IDs aren't needed and will only cause problems.

Override Item#getModel to return the ModelResourceLocation of the appropriate model based on the remaining use time (using the same logic as the vanilla bow). You can see an example of this here (model registration is here and here). Edit: Fix link tag.

There's no crash in that log, it simply ends while the world is loading.

The Entity#ticksExisted field is the number of ticks the entity has existed for. In your override of Entity#onEntityUpdate check if this is greater than or equal to 600 (30 seconds * 20 ticks/second = 600 ticks) and if it is, damage the entity using Entity#attackEntityFrom .

Something is null on line 220 of the P.ModelPHead class (in the constructor). We're not telepathic, so we can't really tell you much more without seeing your code.

Call the super method from your override of Entity#onEntityUpdate . This sets a lot of important values like the prevPosX / Y / Z fields, which are used for various rendering purposes.

Be more specific. What doesn't like what? What's the error message and what part of the code is it for? If @Override gives you a compilation error, the method doesn't override a super method.

Item#onItemRightClick doesn't have that signature, so you've created a new method that's never called instead of overriding the method that Minecraft calls. Always add the @Override annotation to override methods so you get a compilation error if it doesn't actually override a super method. I suggest using your IDE to auto-generate override methods, this way the override method will always have the correct signature and the @Override annotation.

It took a while to get around to it, but I finally sat down and fixed your issues. I've submitted a pull request with my changes.