[1.8.9] Custom Door issues

[blahblahbal]

I'm having issues getting a custom door to even appear in-game. Its item is fine, but when I place it, it 1) only places half of the door, 2) doesn't drop the right item/block when mined (instead it drops a block that apparently derives its name from an item), and 3) renders invisible.

 

Here is the code on github:

BlockDiamondDoor:  https://github.com/blahblahbal/Blah-s-Minecraft-Mod/blob/master/blahmod/blocks/BlockDiamondDoor.java

ItemDiamondDoor:  https://github.com/blahblahbal/Blah-s-Minecraft-Mod/blob/master/blahmod/items/ItemDiamondDoor.java

ModBlocks:  https://github.com/blahblahbal/Blah-s-Minecraft-Mod/blob/master/blahmod/blocks/ModBlocks.java

ModItems:  https://github.com/blahblahbal/Blah-s-Minecraft-Mod/blob/master/blahmod/items/ModItems.java

 

And the json models are simply copied from vanilla.

 

I must be missing something, but I can't see it.

[blahblahbal]

So... no one can help? I'm sure there's someone out there who's able to. I know I'm not the best programmer, but I'm trying. I don't have the resources a lot of people have, since I am the only one working on my project.

 

I've been working on the door problem for the last few hours (as well as some things with my custom biome), but no luck as of yet.

[Choonster]

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.

[blahblahbal]

Alrighty, I'll fix the structure tomorrow, since it's late here right now. I'm also going to look into updating to 1.11.2. The last time I tried to update I had problems, but that was on a super early version of Forge for 1.9.

 

There might be some issues with fixing the structure, since I've built a lot of it around the improper structure. Hopefully I won't have too many edits to do.

[blahblahbal]

It looks like I messed up the structure more than I thought I did. I moved things around into a similar structure as yours is in, but Eclipse is forcing me to put 'main.java.blahblahbal.blahmod.<whatever>' in place of EVERY 'blahmod.<whatever>' in the code's imports and package declaration(s).

 

I'll mess around with it some more.

 

EDIT: Now when I load the game, it says 'java.lang.ClassNotFoundException: main.java.blahblahbal.blahmod.Main'

Probably because the structure is broken...

Edited May 23, 2017 by blahblahbal

[blahblahbal]

Fixed that by creating another subfolder. It seems that there are way too many subfolders. I'm not sure if I should even upload the source in its current structure. In Eclipse, it needs the 'package main.java.blahblahbal.blahmod.<whatever>', but in yours it doesn't have that type of structure. Just 'package choonster.testmod3.<whatever>'.

 

Did I set up Eclipse incorrectly? I don't even remember how I set it up. I think I had to do some minor hackery to get it to work, even though I followed the step-by-step instructions provided in the download.

 

Plus, when I compile the mod and run Minecraft (like I said above), it gives that 'java.lang.ClassNotFoundException.' I moved the files/folders within yet another subfolder, and (as I said at the start of this post) it works (which makes sense actually).

 

I guess I just don't understand why all the folders are needed, and that's why the original structure of my mod is odd.

 

I'm gonna upload the build.gradle file, and the other files in a minute or two.

[Choonster]

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.

Edited May 23, 2017 by Choonster

[blahblahbal]

Hmm... I followed that page exactly. I can't remember what exactly went wrong, since it was more than a year ago that I started this.

 

I do remember running 'gradlew eclipse' and it not working. Or something. What I do know is that I had to fiddle with some settings in Eclipse, since it didn't create the workspace properly. From what I can tell of YouTube videos, my workspace is quite different from most modders'. I had to import the deobfed.jar with the project setup manually.

 

...It's really fuzzy in my mind what I had to do. Maybe I should just rewind, and re-setup everything.

 

Before I go any further, what are the exact files I need on the repo? That I don't have, I mean.

[Ugdhar]

Follow the link choonster provided, follow the instructions to the letter, it tells you which files you need from the forge mdk.

Then create your src folders as he described.

 

*Edit: Note that the project directory and your eclipse workspace are NOT the same folder. Your project directory will be INSIDE the eclipse workspace folder.

So say your eclipse workspace will be C:\Workspace you would want a folder in there called minecraftmod, which is where you will place all the mdk files and run gradlew from. Then when you open the C:\Workspace workspace in eclipse, you just import existing project, and pick the project folder.

Edited May 23, 2017 by Ugdhar
addendum

[blahblahbal]

Okay, so I followed the instructions on that page again, after extracting the MDK to another directory. Oddly, when I ran 'gradlew setupDecompWorkspace' it didn't decompile Minecraft. Is there something I'm missing on that page?

[Choonster]

19 minutes ago, blahblahbal said:

...It's really fuzzy in my mind what I had to do. Maybe I should just rewind, and re-setup everything.

 

That's probably a good idea.

 

 

19 minutes ago, blahblahbal said:

Before I go any further, what are the exact files I need on the repo? That I don't have, I mean.

 

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.

[Choonster]

1 minute ago, blahblahbal said:

Okay, so I followed the instructions on that page again, after extracting the MDK to another directory. Oddly, when I ran 'gradlew setupDecompWorkspace' it didn't decompile Minecraft. Is there something I'm missing on that page?

 

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.

[blahblahbal]

Ah, okay.

 

I've got the folder(s) setup now, but it's not compiling when I save a source file. Do I have the folder tree done correctly?

 

 

This is inside

 

Edited May 23, 2017 by blahblahbal
Formatting issues

[Choonster]

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.

Edited May 23, 2017 by Choonster

[blahblahbal]

Should the structure in the Eclipse package explorer be composed of folders, or source folders?

 

EDIT: I'm assuming source folders, because if they were just folders, they won't compile, since as they are in the first screenshot, they don't. But from what you said about the Eclipse screenshot... it's confusing me.

Edited May 23, 2017 by blahblahbal

[blahblahbal]

3 hours ago, Choonster said:

The buildscript says that the source code and resources are in subdirectories of src, but this isn't reflected in the repository's structure.

Ah, yeah... I have no clue what the sourceSets section even does. It doesn't change where the command prompt draws the files from.

 

Anyway, I've uploaded the other missing files onto the repo.

[jeffryfisher]

When you finally get your project set up correctly, if your door still won't open, try running in the debugger so you can step through your methods and into any vanilla methods they rely upon when you try to open/close a door. Then when you ask for more help, you'll be able to tell us what you saw  happening (or not happening).

[blahblahbal]

Oh, the door opens/closes just fine. It's just that it renders invisible and when I place it, it doesn't place both halves.

 

EDIT: Here's a gif of what's happening:

(Excuse the error in the middle of the gif, that happens with the Minecraft launcher's output window sometimes)

Edited May 23, 2017 by blahblahbal

[Choonster]

10 hours ago, blahblahbal said:

Should the structure in the Eclipse package explorer be composed of folders, or source folders?

 

EDIT: I'm assuming source folders, because if they were just folders, they won't compile, since as they are in the first screenshot, they don't. But from what you said about the Eclipse screenshot... it's confusing me.

 

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:

 

  

Edited May 24, 2017 by Choonster

[blahblahbal]

Ah, ok. I think I've got it now, check this screenshot:

It's still a tad wonky (with the src and src/main folders), but at least it looks a lot better than before.

[blahblahbal]

Okay, I tried to compile it in the new location, and it's only 'compiling' the resources. I'm not sure where I need to put the .class files in order to get them to compile.

 

EDIT: Nevermind, fixed it. Uploading to github in a couple minutes.

Edited May 24, 2017 by blahblahbal

[Choonster]

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.

[blahblahbal]

Oh, right. I'll delete that section. Should be uploaded in about a minute or two.

[Choonster]

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.

Edited May 24, 2017 by Choonster

[Choonster]

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.

Edited May 25, 2017 by Choonster