Choonster

You can cancel WorldEvent.PotentialSpawns to prevent any entities from being spawned passively, but structures spawn their entities directly and don't fire any events apart from EntityJoinWorldEvent. PopulateChunkEvent.Pre is fired before a chunk is populated (i.e. before most structures are generated) and PopulateChunkEvent.Post is fired after a chunk has been populated (i.e. after most structures are generated), so you can use these to set a per-chunk boolean value and use this in conjunction with EntityJoinWorldEvent to prevent any entities from being spawned during structure generation. Unfortunately mod world generators all run after PopulateChunkEvent.Post, as do structures generated in IChunkGenerator#generateStructures rather than IChunkGenerator#populate. The only vanilla structure to do this is the Ocean Monument. You could suggest that entities spawned by structures fire a unique event (either on the forums or on GitHub), but there's no guarantee that it will be accepted (and very little chance it will be added to 1.10.2).

The ID of the tag type that the list will contain. Use the values from the Constants.NBT class.

EntityLiving#inventoryHandsDropChances and EntityLiving#inventoryArmorDropChances store the drop chances for the entity's held items and armour respectively. These fields are both protected, so you'll need to use reflection to access them.

You're also using the wrong annotation for your ClientConnectedToServerEvent handler: @Mod.EventHandler is only for FML lifecycle events (classes that extend net.minecraftforge.fml.common.event.FMLEvent) and only works in your @Mod class. @SubscribeEvent is for gameplay events (classes that extend net.minecraftforge.fml.common.eventhandler.Event) and only works in a class that's had the Class object or an instance registered with the appropriate EventBus.

Post your code.

The TileEntity shouldn't know or care about that, the TileEntitySpecialRenderer should initialise its stored TileEntity instance with any data required to render it in the inventory.

The Minecraft class implements the IThreadListener interface, so you can use an instance of it as an IThreadListener.

You probably should implement it so that your model isn't rendered at a weird scale or rotation in GUIs, on entities, etc. If you're wrapping an existing model that implements IPerspectiveAwareModel, you can likely delegate to that.

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?