Choonster

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.

Use the IFluidHandler capability for fluid-related operations. You can pass false as the second argument of IFluidHandler#fill and IFluidHandler#drain to simulate the filling/draining without actually modifying the contents of the IFluidHandler.

Forge's documentation has a page on the Simple Network Wrapper here. This is what you should use to send the packets.

Find the FML log (logs/fml-client-latest.log) in the game directory Upload it to Gist by dragging the file onto the page and clicking "Create secret gist" or "Create public gist" Link it here

If you want it to work properly, yes. That may work in single player, but it's guaranteed to break when the server isn't running in the same process as the client (i.e. LAN hosted by another player or a dedicated server).

The Ordering class is from the Guava library, which uses its own functional interfaces (that predate Java 8). Make sure you've imported com.google.common.base.Function (Guava) rather than java.util.function.Function (Java 8).

Post your new Block and TileEntity classes.

Block#removedByPlayer is called on both sides, so you're spawning a real EntityItem on the server (which also spawns it on all nearby clients) and a "ghost" EntityItem on the client (that can't be interacted with because the server doesn't know about it). Entities should only be spawned on the server. Don't manually spawn the EntityItem, override Block#getDrops like I told you to in my first reply. If you store a compound tag in the "BlockEntityTag" key of an ItemStack's stack compound tag, Minecraft will automatically call TileEntity#readFromNBT with this tag when a player places the block. You don't need to do this yourself. Is the update method being called every tick (e.g. because it implements ITickable#update)? If so, you shouldn't be calling World#notifyBlockUpdate every tick, only call it to send the TileEntity's update packet or re-render the chunk (it always does both). It's possible that this is causing the TileEntity's update packet to be sent before the client knows that there's now a TileEntity at that position. The flags argument of World#notifyBlockUpdate is completely unused by the server and isn't sent to the client. Why are you reading/writing the tank and its contents from/to NBT separately? Just read/write the tank (FluidTank#readFromNBT/FluidTank#writeToNBT) and it will read/write its contents.

ItemStacks don't have a stack compound tag by default, you need to create one and set it as the stack compound tag by calling ItemStack#setTagCompound. Alternatively, use a method like ItemStack#setTagInfo that automatically creates the stack compound tag if it doesn't exist and then calls NBTTagCompound#setTag on it with the specified key and value.