Choonster

Vanilla already has a ChunkPos class, you can get a Chunk 's ChunkPos with Chunk#getPos . You probably don't want to hold the data for every chunk of every dimension in memory at once, so you should load and save your data with the chunk and remove a chunk's data from the Map when it unloads. You can do this by handling ChunkDataEvent.Load to read data from the chunk's NBT into a per-dimension [code]Map<ChunkPos, YourDataClass> [/code] (stored in your capability) and then handling ChunkDataEvent.Save to write data from the Map into the chunk's NBT. You'll also want to handle ChunkEvent.Unload to remove the entry for the unloaded chunk from the Map .

Any command that's executed on the server should be registered with FMLServerStartingEvent . This is fired for both the integrated and dedicated servers.

Get the player's World from the Entity#world field, check that World#isRemote is false (i.e. you're on the logical server), then get the server with World#getMinecraftServer . You can check if a server is dedicated or integrated using MinecraftServer#isDedicatedServer . Since IntegratedServer is a client-only class, you'll need to create a method in your proxy to get the value of IntegratedServer#isGamePaused . Return false from the server proxy and only reference IntegratedServer from the client proxy.

The IntegratedServer#isGamePaused field will also tell you this, but you'll need to access it via reflection. This can only be accessed from the logical server on the physical client. You can read more about sides here.

1.11 does require resource file names to be lowercase (en_us.lang), but Forge will add mod resources to the resource pack list using the LegacyV2Adapter class if they don't have a pack.mcmeta file or they have one that specifies pack_format as 2 (see FMLClientHandler#addModAsResource). LegacyV2Adapter will load mixed case (en_US.lang) lang files, but will still require all other file names to be lowercase. In summary: If you have a pack.mcmeta file with pack_format 3, use lowercase lang file names; otherwise use mixed case lang file names. The assets folder belongs in src/main/resources (so it's copied to the compiled JAR), not in src/main/java (it's not source code that needs to be compiled).

Exactly what I needed. Thanks! I have it working as I wanted now. However, do I need to handle the help text for each subcommand? I can't seem to access it otherwise. /help mymod gets the help text from the CommandTreeBase...but I can't seem to find the texts for the subcommands. I could just add a help argument branch for each subcommand... edit: I am generating the help text by simply having public void execute(MinecraftServer server, ICommandSender sender, String[] args) throws CommandException { if (args.length == 1 && args[0].equals("help")) { sender.addChatMessage(new TextComponentString(getCommandUsage(sender))); } } in my subcommand execution. Seems to be working fine, although perhaps there is a better way. For my mod's command, I added a help sub-command that extends CommandHelp , stores the instance of the base command and overrides CommandHelp#getCommandMap and CommandHelp#getSortedPossibleCommands to return values from the base command. CommandTreeBase provides a getCommandMap method, but you have to implement getSortedPossibleCommands yourself ( CommandHelp calls ICommandManager#getPossibleCommands and sorts the result). You can see the base command here and the help sub-command here. Unfortunately this prints the vanilla header (which says /help instead of /testmod3 help ), but you'd need to re-implement CommandHelp#execute yourself to get around this.

Extend CommandTreeBase to create a command with sub-commands. Use CommandTreeBase#addSubcommand to add a sub-command.

Minecraft#isGamePaused will tell you if the game is paused. This can only be called on the client side.

Those are the correct methods to override, yes. What makes you think there isn't a TileEntity ? Are your hasTileEntity and createTileEntity methods being called?

There's no method in Block called createNewTileEntity , so you can't override it. Delete this method and return a new instance of your TileEntity from the Block#createTileEntity override instead. Overriding a method to do nothing but call the super method is completely pointless.

Don't extend BlockContainer or implement ITileEntityProvider . Override Block#hasTileEntity(IBlockState) and Block#createTileEntity . Your IDE should be able to generate override methods for you.

Make sure you're launching Minecraft in Debug mode rather than Run mode.

Most Forge mods are universal, i.e. they work on both the client and server. Mods that are client-only or server-only should say so on their forum thread/download page.

Yes, look at block/cube or block/cube_all , these both define texture names without specifying a path for them.

Add the item(s) to the player's inventory, then return the ItemStack argument instead of creating and returning a new ItemStack .

Forge's blockstates format does allow fully-specified variants, i.e. variants that specify a value for multiple properties. These can still define textures like other variants. You can see an example of this here. All the variants are fully-specified and one defines a unique texture.

I think, however, that WAILA relies on NEI, and there is not a WAILA equivalent for JEI. Waila converted NEI to an optional dependency towards the end of 1.7.10 (here) and then removed entirely in 1.8.8 (here). Unfortunately Waila isn't really being actively developed any more, but there are two main alternatives: Hwyla (GitHub), a fork of Waila that's being actively developed by TehNut The One Probe (GitHub), a completely separate mod developed by McJty

You need to use Forge's blockstates format to specify textures in the blockstates file, you're using the vanilla format. There's also not much point in extending a model with elements (e.g. minecraft:block/half_slab ) if your model has its own elements, the parent's elements will be overwritten. Using Forge's blockstates format or a vanilla model that specifies all of the textures should resolve the "Unable to resolve texture due to upward reference" errors.

There are two parts to this: Storing whether a player has received the item Giving the item to a player when they log in To store per-player data, you can either use the EntityPlayer.PERSISTED_NBT_TAG sub-compound of Entity#getEntityData or the Capability System. The entity NBT should only be used to store simple data like a flag that's only set once; for anything more complex or frequently accessed you should use capabilities instead. To do something when a player logs in, use PlayerEvent.PlayerLoggedInEvent . I have an example of this using entity NBT here. ItemSoup does this by overriding Item#onItemUseFinish to call the super method and then return an ItemStack of Items.BOWL , replacing the original ItemStack in the player's inventory. If you need to give the player multiple items or your food stacks, simply add the items to their inventory from this method instead of returning a new ItemStack .

There's a list of modding tutorials for 1.9.x/1.10.x here, some of which have been updated to 1.11. 1.11 is still fairly similar to 1.10.2, but the main change is that ItemStack s can no longer be null (the default value is now the empty ItemStack , see ItemStack#isEmpty ) and most fields of ItemStack that were public are now private with public getters/setters. Because ItemStack s can no longer be null , anywhere that used a List<ItemStack> or ItemStack[] should now use a NonNullList<ItemStack> . Edit: I forgot that this site doesn't use Markdown.

Create a base model that defines the shape and the texture names for each face and then create models that extend this and specify the texture location for each texture name as appropriate. This is how basic blocks models work: block/cube_all defines the shape and the texture names ( all ) and you create a model that extends it and specifies the texture location for each texture name (e.g. "#all" = "modid:blocks/foo" ).

There's a list of modding tutorials for 1.9.x/1.10.x here, some of which have been updated to 1.11. 1.11 is still fairly similar to 1.10.2, but the main change is that ItemStack s can no longer be null (the default value is now the empty ItemStack , see ItemStack#isEmpty ) and most fields of ItemStack that were public are now private with public getters/setters. Because ItemStack s can no longer be null , anywhere that used a List<ItemStack> or ItemStack[] should now use a NonNullList<ItemStack> . Edit: I forgot that this site doesn't use Markdown.

You need to use Properties.AnimationProperty and IModelState . Forge has an example of this here.

When are you registering the model for the Item ? ModelLoader methods must be called in response to ModelRegistryEvent (if you're registering your Block s and Item s with RegistryEvent.Register ) or in preInit (if you're registering your Block s and Item s in preInit). If you call ModelLoader.setCustomModelResourceLocation in init or later, it will do nothing and your item will be rendered as the missing model.

Use the non-deprecated overload: Block#hasTileEntity(IBlockState) Don't change the TileEntityTestChest class, only remove the pointless TileEntityTestChest method in the test_chest class. I noticed that TileEntityTestChest implements IItemHandler , don't do this. The whole point of the capability system is that you don't implement all the interfaces on your TileEntity , Entity or Item ; you override the ICapabilityProvider methods implemented by the base classes and use existing implementations of the capability interfaces when possible (e.g. ItemStackHandler for IItemHandler ).