Choonster

IPerspectiveAwareModel is an extension of IBakedModel that can be replaced with another model and/or have a Matrix4f transformation applied to it depending on where it's being rendered (i.e. the ItemCameraTransforms.TransformType). Most of Forge's IPerspectiveAwareModel implementations use IPerspectiveAwareModel.MapWrapper.handlePerspective in their implementation of IPerspectiveAwareModel#handlePerspective.

The server's banned-players.json file is corrupt, either fix it or delete it.

BlockPos#offset returns a new BlockPos offset in the direction of an EnumFacing by a specified amount (or 1). There is no method called BlockPos#getOffset. Use IBlockState#getValue to get the value of a property. Forge's documentation has an introduction to block states here.

Did you mean BlockPos#offset?

TileEntity#getField can't return null. World#getTileEntity is returning null. This is why World#getTileEntity is annotated with @Nullable, you need to account for it returning null. Your IDE should warn you about calling a method on a @Nullable value without checking for null.

I think the answer is probably "don't". Use Forge's Update Checker to let players know when there's an update available and let them download it themselves.

ModSaplingBlock and ModSapling2Block both reference ProvidesPotionEffect, which doesn't appear to exist anymore. The methods that do this aren't called from anywhere. The game crashes with a NullPointerException thrown from inc.a13xis.legacy.dendrology.TheMod#fallBackExsists because the fallback field is null. The mod isn't running from a JAR and ../build/resources/main doesn't exist because Gradle hasn't built the mod and IDEA doesn't output to that directory, so fallback is never assigned a non-null value. You should use Optional.absent() as the initial value of the field. Your fallback LangMap completely ignores the client's locale and always translates to en_US. I suggest deleting it completely and fixing any issues you have with the vanilla translation system. After fixing that, all models and localisations were working apart from three issues: Errors were being logged for the missing models of the double slab Items. There's no need to register Item forms of your double slab Blocks. Every stairs Item except stairs0 was being rendered as the missing model, depsite not logging any errors. The issue was caused by using the variant enum's ordinal as the metadata argument of ModelLoader.setCustomModelResourceLocation; stairs Items are always metadata 0. Stairs Items were displaying as 2D textures in the inventory. This was fixed by removing the unnecessary display block from the item models. You can't reference client-only classes (e.g. net.minecraft.client.resources.I18n, ModelLoader or ModelResourceLocation) from common code (e.g. your @Mod class), otherwise you'll crash the dedicated server. You can only do this in client-only classes referenced from your client proxy or in client-only methods. SaplingParcel isn't going to work on the dedicated server because you've implemented the item spawning in your client proxy, which is only loaded on the physical client. Items must be spawned on the logical server, but there's no way to send an ItemStack display name in a chat message from the server to the client unless you translate on the server and ignore the client's locale. To solve this, you need to send a custom packet containing the ItemStack from the server to the client and then display the chat message in the packet's handler. I have an example of this for 1.11.2 here.

You didn't update build.gradle, but I'll try to work around this. I highly recommend using a proper Git client (e.g. the CLI, IDEA or GitKraken) instead of manually uploading files on the GitHub website. This will make it much easier to commit exactly the right changes and prevent you from creating commits with no changes.

It will probably work, but I wouldn't recommend it. Each method should be self-contained and not rely on other methods being called before or after it. If the matches method saves the index, the other methods will only work if they're called after it.

I didn't realise RecipeFireworks did that. I suppose it works, but having implicit side effects tends to make code less robust and harder to follow. You copy the stack variable in getRemainingItems before putting it in the array, but the original value is never stored or used anywhere else.

Your IRecipe shouldn't be storing any state between methods, each method should only do exactly what's required of it without any side-effects: matches should find the staff in the crafting grid, make sure it's valid and that there aren't any other items. getCraftingResult should find the staff in the crafting grid and return the output item with the appropriate NBT or return null if it didn't find the staff. getRemainingItems should find the staff in the crafting grid and set that slot of the output array to the uncharged staff. You completely ignore the output stack passed to the constructor by overwriting it in matches. I suggest taking any items used by the recipe as constructor arguments, storing them in final fields and then using them in the appropriate methods. There's no need to explicitly fill an array with null, null is the default value of all reference types. There's no need to copy an ItemStack that's just been created and won't be stored anywhere.

The 1.9 and master branches of dendrology-legacy-mod are still targeting 1.8.9. dendrology-legacy-mod depends on the KoreSample project, but you don't have a settings.gradle file to include the project and the repository doesn't contain the project. If you're going to depend on the KoreSample project, add the KoreSample repository as a Git submodule and include it with a settings.gradle file. Why did you create your own repositories from scratch instead of forking the original ones?

I feel like you probably understood what I told you, but what you said doesn't make a lot of sense. In your ClientConnectedToServerEvent handler, you need to call IThreadListener#addScheduledTask with an implementation of Runnable that actually performs the desired task. This can be a regular class, an anonymous class, a lambda or a method reference. Forge's documentation explains how to get the IThreadListener for each side here.

Yes. If you look at the method that the exception is thrown from (SimpleReloadableResourceManager#getAllResources), you'll see that it throws a FileNotFoundException with the ResourceLocation as the message if none of the loaded resource packs contain the ResourceLocation's domain. build is Gradle's output directory, not the IDE's output directory (if you're using IntelliJ IDEA or Eclipse). classes is IntelliJ IDEA's output directory and bin is Eclipse's output directory. I'm not sure why it's not working. Please post your code as a Git repository so I can debug it myself.

ClientCommandHandler isn't an event, you can't subscribe to it. You need to call ClientCommandHandler#registerCommand from your client proxy in preInit. There should be an error in the log telling you that the method is invalid.

The error message tells you exactly what's wrong: The JAVA_HOME environment variable currently points to the JRE, but it needs to point to the JDK instead.

dendrology:blockstates/leaves3.json is a ResourceLocation, it corresponds to assets/dendrology/blockstates/leaves3.json on disk. As I suspected from your previous post, none of your assets are being loaded. Is your assets folder in the correct location? Are your assets being copied to your IDE's build output directory? Are they included in the compiled JAR if you run the build Gradle task?

For future reference: Any code that imports classes from the cpw.mods.fml.* packages was written for 1.7.10 or earlier. FML was moved to net.minecraftforge.fml.* in 1.8.

Note that all subclasses of FMLNetworkEvent (e.g. ClientConnectedToServerEvent) are fired on a Netty thread rather than the main client/server thread, so methods that handle them must not directly interact with normal Minecraft classes. You need to use IThreadListener#addScheduledTask to run a task on the main thread where you can safely interact with normal Minecraft classes.

You need to create your own implementations of IRecipe to handle adding orbs to and removing orbs from the staff. You can probably extend an existing IRecipe implementation like ShapedOreRecipe/ShapelessOreRecipe. Register your recipe classes with RecipeSorter and add instances of them to the recipe list using GameRegistry#addRecipe(IRecipe). Side note: There is no ICraftingHandler in any modern version of Forge. It looks like ICraftingHandler was a predecessor to events like PlayerEvent.ItemCraftedEvent and was removed in 1.7.2 (I never encountered it myself).

Is this in your @Mod class? Are there any errors in the log? Post the testCommand class.

ModelLoader methods must be called in preInit, they won't do anything if called in init or later. It looks like your assets aren't being loaded. Where is your assets folder located? It should be in src/main/resources. If it's still not working, post the FML log (logs/fml-client-latest.log in the game directory) using Gist/Pastebin.

It sounds like you're only registering it on the client. You need to register your commands on both physical sides in FMLServerStartingEvent, which needs to be handled by a @Mod.EventHandler method in your @Mod class. If you're doing this and it's still not working, post your code.

The vanilla FontRenderer supports 256 pages of 256 characters, which is the entirety of the Basic Multilingual Plane (BMP) and the full value range of a char. To support the full range of Unicode code points, you'll need to iterate through the code points of a String (represented as ints or pairs of chars) rather than the code units (represented as chars). In Java 8, CharSequence#codePoints returns an IntStream of a CharSequence's code points. You'll need to create your own page textures and glyph width file for code points outside of the BMP and arrays to store the page locations and glyph widths. You'll then need to override FontRenderer#renderUnicodeChar to do the same thing as the super method but use your page textures/glyph widths. You can then replace Minecraft#fontRenderer with an instance of your class.

You're creating a new ModLeavesItem instance for the ModelLoader.setCustomModelResourceLocation call, don't do this. You need to use the ItemBlock you already registered. You can use Item.getItemFromBlock to get the Item form of a Block. Do you want your items to use the models defined by your blockstates variant or do you want them to use individual item models? If it's the former, use a ModelResourceLocation with the registry name as the domain and path and the variant name as the variant. If it's the latter, use a ModelResourceLocation with the item model's name as the domain and path and any variant name (it won't be used). I don't know why localisation wouldn't be working. Post the relevant code, and the contents and path of your lang file.