Choonster

You should be able to edit or create a profile in the launcher and select Forge 1.8.9-11.15.1.1902-1.8.9 as the version.

World#getEntitiesWithinAABB returns a List<T>, where T is the class you pass as the first argument or any super class up to Entity. You can't cast a List<T> to T, you need to get an individual element from the list. This is basic Java knowledge.

The issue is that you're still registering an ItemBlock for the door and then registering a model for this instead of the ItemDiamondDoor instance. I explained this in my first reply: I've fixed these issues and slightly cleaned up the door registration code, you can view and/or merge the changes here.

The page I linked lets you create a Pull Request, which you can then merge.

I've identified and fixed the problems: BlockDiamondDoor overrides Block#getRenderType to return 7, which isn't a valid return value in 1.8+. The default return value of 3 tells Minecraft to use the baked model system to render the block, which is usually what you want; there's generally no need to override this. This numeric return value was replaced with an enum in 1.9. The diamondDoor.json blockstates file doesn't include the powered property and you haven't told Minecraft to ignore it. You can create an IStateMappper to do this by creating a StateMap.Builder, calling StateMap.Builder#ignore with the properties to ignore and then calling StateMap.Builder#build. Register the IStateMapper by calling ModelLoader.setCustomStateMapper in preInit. You can view and/or merge the changes here. It wasn't immediately obvious what the issue with the model was, since you have 101 model errors and Forge only logs the first five. This was made configurable via the forge.verboseMissingModelLoggingCount system property in 1.9.

I'm glad you figured that out. I haven't done this myself, but it may be possible to implement it yourself with Block#onEntityCollidedWithBlock. I can't really help you any further with this, though there may be existing mods that have done this.

Minecraft will always use assets/<modid>/blockstates/<registry_name>.json for the Block's models (unless you register a custom IStateMapper), but the blockstates file used for the Item models depends on the ModelResourceLocation you pass to ModelLoader.setCustomModelResourceLocation or return from the ItemMeshDefinition you pass to ModelLoader#setCustomMeshDefinition. To use the inventory variant of the assets/<modid>/blockstates/<path>.json blockstates file for an Item model, use a ModelResourceLocation with <modid> as the domain, <path> as the path and inventory as the variant. If a MissingVariantException is logged for the inventory variant of this blockstates file, you may be running into this issue where Forge is treating your inventory variant as partially-defined instead of fully-defined. If you still need help, post the code where you register the Item model, the latest blockstates file (including its path) and the full FML log.

Java doesn't allow operator overloading, so you can't use relational operators like >= to compare non-numeric values. Use the static equality methods in the ItemStack class to check if two ItemStacks are equal or use the getter methods to get each part of the ItemStack (e.g. ItemStack#getItem to get the Item, ItemStack#getCount to get the count/stack size).

Fluid models rendering with gaps was a known issue that was fixed in Forge 1.11.2-13.20.0.2279. It's very unlikely that this will be backported to 1.10.2. The model loading for the inventory variant not being loaded is probably due to you adding a blocks/ prefix to the model path. I'm guessing your blockstates file is assets/sw/blockstates/fluid/plutonium.json, not assets/sw/blockstates/blocks/fluid/plutonium.json. You can use forge:fluid as the item model if you want the item form to render as a 2D-style square with the fluid's texture. Having the item form look like a bucket may be confusing, since it wouldn't actually be a bucket.

This is basic Java knowledge that you should already have before making a mod. Store the EntityCow instance in a local variable, set the fields and then pass it to World#spawnEntity.

The GuiContainer#inventorySlots field stores the Container that you pass to the GuiContainer constructor. You could have found this out for yourself by looking at the GuiContainer class in your IDE. Slot IDs only have to be unique within the Container instance. Two different Container instances can each have their own Slot instance with ID 1.

You never set the cow's position, so it should have spawned at 0,0,0. Set the Entity#posX/Y/Z fields to some coordinates based on the player's coordinates before spawning the cow in the world so the cow is spawned near the player.

I don't have time to debug it at the moment, but I'll do so tomorrow. One suggestion I'll make in the mean time is replacing your .gitignore file with a whitelist version like this one from my mod. This allows you to specify exactly which files to include in the repository rather than adding an exclusion for each new file type or directory (e.g. IDEA project files and output directories). Edit: I just noticed that you're using lambdas (a Java 8 feature) but you haven't told Gradle to compile your code against Java 8 instead of Java 6 (the default set by ForgeGradle). You can do so by adding these lines to your buildscript.

The directory structure looks correct now, but the buildscript still has the wrong source set directories. Now that your files are in the standard locations, you should be able to delete the sourceSets block entirely.

You're using a 1.7.10 version of OptiFine on 1.11.2, this won't work.

When you used Gradle to generate the Eclipse project, it should have marked src/main/java and src/main/resources as source folders. I don't normally use Eclipse, but I generated an Eclipse project for TestMod3 and this is what it looked like:

The structure in the Eclipse screenshot looks correct. Is the blahsmod directory in the File Explorer screenshot where the files in the Eclipse screenshot are located? If so, you appear to be confused. The MDK is an example ForgeGradle project, just like your mod. You only need to copy the buildscript and Gradle Wrapper from it into a new directory, you don't need to (and shouldn't) put your mod's project directory inside of it. All of Forge's files are stored in the Gradle cache, not the project directory.

Gradle will skip a task if it already has valid output from a previous run of the task. If you've already run setupDecompWorkspace for the current Minecraft/Forge versions and MCP mappings, Gradle will use the existing JARs rather than decompiling Minecraft again.

That's probably a good idea. You're missing the Gradle Wrapper (gradlew, gradlew.bat and the gradle directory) and gradle.properties file (if you have one). The buildscript says that the source code and resources are in subdirectories of src, but this isn't reflected in the repository's structure.

The src directory contains a directory for each source set, by default this is just main. Each source set contains a directory for each programming language's source files (by default this is just java) and a directory for resources that are copied to the output without being compiled (called resources). Your mod's Java source code goes in src/main/java/<package>, your mod's assets go in src/main/resources/assets/<modid>. build.gradle goes in the top-level directory with the src directory. The Git repository should also be created in the top-level directory. Forge's documentation has a page on setting up a ForgeGradle workspace and IDE project here. If you use the standard structure, you shouldn't need to mess around with anything for it to work.

This is an OutOfMemoryError, just like your previous thread. The same solution applies: Remove the _JAVA_OPTS environment variable that's adding the -Xmx256M JVM argument.

1.7.10 is no longer supported on this forum, you won't get any help with it.

Have some patience, your thread was only up for a few hours before you posted again. Help will rarely be instant on this forum (or any other) due to differing time zones and the limited amount of time spent on here by the people able to help you. Because you're using 1.8.9, GameRegistry.registerBlock automatically creates and registers an ItemBlock unless you tell it not to by calling one of the overloads with a Class<? extends ItemBlock> argument and passing null as that argument. The registry system has been overhauled in 1.9+ and ItemBlocks are no longer created automatically. There's no reason to extend a class (e.g. ItemDoor) and override its methods if you're going to implement them to do exactly the same thing as the super methods (e.g. ItemDiamondDoor). You can use ItemDoor directly, there's no reason for ItemDiamondDoor to exist. I can't see the causes of your problems by looking at the code on GitHub, I'll need to debug it locally to help you further. I currently can't do that because your repository isn't structured properly and doesn't include the buildscript (build.gradle), look at my mod and its .gitignore file for an example of the proper structure and which files to include. Once you've fixed the structure, reply here and I'll try to debug it when I get a chance.

It's described in the EAQ, which you're supposed to read before posting.

I explained where the 3 GB comes from and how you can stop it here. Note that it's very unlikely you'll be able to successfully decompile Minecraft with with 1 GB of RAM, even though the linked post will let you try it.