I've been trying to switch to Wuppy's advanced modding setup (http://www.wuppy29.com/minecraft/modding-tutorials/wuppys-minecraft-forge-modding-tutorials-for-1-7-set-up-part-2b-advanced-forge-setup/ and http://www.wuppy29.com/minecraft/modding-tutorials/wuppys-minecraft-forge-modding-tutorials-for-1-7-creating-your-own-mod-advanced-setup/), but I can't figure out where to put my resources folder in a place where it will be recognized. Does anyone know the right way to do it with this setup?

It should be in the forge project folder

/src/resources/assets/yourmod/...

 

It still isn't working. Here's a picture of my file tree with relevant stuff opened.

An example of a reference to one of said resources: new BlockLickable().setBlockName("blockLickable").setCreativeTab(CreativeTabs.tabBlock).setBlockTextureName(MODID + ":lickable");

MODID is darkfangsmod

Why are there two projects? There should be no 'Forge' project. Seriously guys STOP DOING THAT.

See tutorial linked above. Maybe it doesn't work… I'll go back to trying to get the Pahimar setup to work. ._.

Ok, so I'll assume that the right way to have multiple mods is to use 2 different packages.

If that's the case, is there a way to disable/enable mods when I run the client so I can test 1 mod at a time?

Download Forge src

Make Folder called 'Mod1'

Unzip Forge src into 'Mod1'

Make Folder called 'Mod2'

Unzip Forge src into 'Mod2'

OMFG YOU HAVE TWO MODS OMG OMG OMG OMG GOMG OMGMGOMGKMKGMOGMOGMOMGOGJOGOGO

 

Seriously guys we've made this stupidly simple, quit complicating it.

If you want to have both mods in a single eclipse workspace that's slightly more complicated, but not really.

Just setup a workspace somewhere, anywhere. And then run the 'eclipse' task on both mods. Then input the eclipse projects... Seriously.. not hard.

... Code goes into src/main/java (why on earth is that empty for you?), assets go into src/main/resources.

 

The src/main/java he's talking about is the one at the top.

 

If you want multiple mods in one project, declare them in packages and put them under the src/main/java at the top as stated above,

(if you're only doing one, follow the same pattern),

e.g., package com.darkfangs.darkfangsmod goes in path src/main/java/com/darkfangs/darkfangsmod,

and package com.darkfangs.lightfangsmod goes in path src/main/java/com/darkfangs/lightfangsmod.

 

Texture assets would go in src/main/resources/assets/darkfangsmod/textures

and src/main/resources/assets/lightfangsmod/textures.

 

They won't build as separate mod jars, but both mods will appear as separate mods in Minecraft when you load it.

Thanks for that tutorial, Lex, it was extremely helpful.

 

Quick question: are there specific naming conventions we should use for those of us who don't own a domain? The link seems to assume everyone owns a specific web domain, unless I'm totally off about the net./org./com.user.modid.

Could of sworn I mentioned that you'd use your email.

like com.google.lexmanos

Or, get yourself a host

Alright, well I now have a question. I'm not having any errors, just a general question.

 

I still use a 'Forge' folder, but I do it so that my run configurations can run multiple mods at once (mini question, what's the advantage of using "Debug configurations" over "Run configurations"? Or, what's the difference?). I just set it so that each one runs Forge, then under 'User Entries' in the 'Classpath' tab of each configuration, I just add the java projects of the mods I want to run with it. I also like having a Forge folder and then making separate Java Projects for each mod because then the only things in that mod project is the code and the resources for it. I guess the one downside is that I have to install Gradle on my machine and copy over and change the build.gradle to make it work, but I've gotten that to work as well.

 

SO, the question is, is what I'm doing still wrong?

mini question, what's the advantage of using "Debug configurations" over "Run configurations"? Or, what's the difference?

Debug allows you to have breakpoints, hot swap, and the like, Normal run is a normal run uninstrimented.

 

I just set it so that each one runs Forge, then under 'User Entries' in the 'Classpath' tab of each configuration, I just add the java projects of the mods I want to run with it.

That's fine, you can do that for whatever classpaths you want.

I also like having a Forge folder and then making separate Java Projects for each mod because then the only things in that mod project is the code and the resources for it.

... The gradle wrapper is optional it's recomended so that users who grab your repo don't need to have gradle installed. Beyond that you shouldn't have anything else. So.. what exactly are you saving by doing it that way?

I guess the one downside is that I have to install Gradle on my machine and copy over and change the build.gradle to make it work

The first aprt is exactly what the wrapper is ment to save you from, and the second part ... why edit shit multiple time?

SO, the question is, is what I'm doing still wrong?

Short answer yes, I've explained in my video how to set things up. Forcing outsiders who see your mod to figure out how to setup gradle and how to edit a build.gradle is a bad idea. They SHOULD just clone your repo, run setup, and be good to go, no external installs.

OK, I just wanted to comment here - I set up my workspace via wuppy's advanced setup and IT WORKS GREAT. I have not installed gradle (nor even know exactly what it is), and I don't have to edit the build.gradle but once per project.

 

I understand that every setup has advantages and disadvantages, and that some people will fight tooth and nail for setups that make no sense to other people. It's like bracket placement rules or hard/soft tab arguments or even Mac vs. PC - both sides are valid and full of people that will never change. Use what you are used to and learn to use it properly.

 

Let me try explain how this advanced setup is supposed to make things work.

 

I have a single folder for all of my modding related stuff. In that folder are a folder for eclipse and related files (extracted zip), a folder for forge and related files (extracted zip) and a folder for my Eclpise workspace, in which I save my mods.

 

Once creating these folders and unzipping force src and eclipse into their respective folders, I ran "gradlew setupDecompWorkspace" and "gradlew eclipse" in the ~\modding\forge\ directory. I then ran Eclipse and selected ~\modding\workspace as my Eclipse workspace.

 

In Eclipse, when I want to make a new mod, such as my SpawnerCraft mod (made on this system), I make a new project in Eclipse called the mod name. I then make the build path for that project include Forge, and setup a new Run Configuration for Forge that includes the new project.

 

TADA, the mod has its own folder and I only ever have to install all the Forge files (386 MB) once. This is not that big of a deal, honestly, and new people should do the simple option of a new forge enviroment for each mod - it is simpler.

 

To publish (case study) Spawnercraft, I take the com.cad97.Spawnercraft package and copy it over to the src/main/java. I take the other files (excluding build.gradle if this isn't the first jar build) and put them in src/main/resources. I run my Run Config of just Forge (no other projects) to make sure the mod is working. If this is my first time building the mod, I will edit the build.gradle as appropriate. If not, I'll copy over the pre-existing one in the mod folder already and use it (checking that the forge version is the same, as I may have updated since the last build). I then "gradlew build" in ~\modding\forge and I have the .jar for the mod. Then I delete the new files out of the Forge project and carry on my way. If I feel it necessary to save myself the agonizing effort of editing three tags in build.gradle, I'll copy it over into the mod project to keep it for the future.

 

Then, I can repeat as necessary.

 

Advantages of this format:

• If I were to use git or mercurial or whatever to mirror my mod to github or bitbucket or whatever, I would not be uploading the Minecraft/Forge source.
  
• It is easy for me to see what files are directly pertaining to the mod in a nice small folder.
  
• I have the same enviroment that I've been used to from previous projects that every project is (gasp) its own project.
  
• When updating Forge I only have to do it once (taking several (>10 even) minutes on my old machine).
  
• 
  
• Profit
  

 

Disadvanteges:

• Some setup time to get the Run configs and the different folders.
  
• People not being able to comprehend this setup.
  
• Having to copy over files to export a project (which should only happen once per project if you're good).
  
• If people are grabbing my mod source, they will have to realize that it needs to be built and ran through Forge rather than being self-contained (but really these are mods not programs).
  

 

Sorry for the rant, and just to clarify, everything here is opinion and as such could be very wrong to some people if they are of the opposite opinion.

 

Screengrab of my setup in Eclipse:

 

 

 

 

 

Did I really just spend thirty minutes explaining an opinion on the internet. In a location where it has been discouraged. What am I doing with my time? (Waiting for a response on another topic.)

I havent read every comment but by what i can see you dont have you .java files in the right place to begin with they should be under the "src/main/java" and your texture files should be under "src/main/resources".

I havent read every comment but by what i can see you dont have you .java files in the right place to begin with they should be under the "src/main/java" and your texture files should be under "src/main/resources".

 

The point of the setup is that they aren't. Yes, this is not the intended way of setting up your workspace. No, it does not not work. (not not = does)

 

For the gradlew build to work, the files have to be there, and to build a mod if I wish to release it I move them there. For writing, however, it works fine to have them in their own project AS LONG AS you actually set up the whole enviroment correctly, and messing one thing up could screw you over.

 

I set this up following wuppy's tutorial and just modifying a couple folder hierarchies to make it fit my organization style better.

 

Oh, and I should probably say this (I forgot it originally): I did set up a JAVA_HOME Environment Variable. I did not set up a PATH Environment Variable.

Because they can... Before ForgeGradle such a setup was nice. Now... It's just not needed.

Wuppy's  setup is a great setup, It makes everything a whole crapload easier. I've tried both ways.

Also, I've heard the normal setup does not work for some people due to eclipse freaking out.

Honestly guys we should let it rest. It's (somewhat) like Mac vs. PC vs. Linux, there's no real answer, just the best for each person.

 

As long as it works for you, it's fine. If it doesn't work, set it up by the "official" way before you complain to the people who want you to set it up that way

Ok. But...

[move]THIS ARTICLE CAME VERY CLOSE TO BEING A HOT TOPIC![/move]

-.- Gunna lock this, cad97, this is not a PC vs Mac debate, this is a you're doing something extremely stupid by complicating the setup when the scripts do EXACTLY what you are trying to emulate for you, natively.

The other issue is you flat out have no idea how the system actually works as evidenced by this statement:

"I only ever have to install all the Forge files (386 MB) once."

 

Anyways locking before it becomes more of a bitchfest and bad information.