Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[1.6.4] Best practices for organizing code for a mod?


keybounce
 Share

Recommended Posts

So I'm trying to understand the best practices for organizing code for a mod.

 

I'm starting with something simple. I took an existing add-on for another mod, made a change to it, and got it to run happily in Eclipse. Now I'd like to compile it for use in normal Minecraft.

 

In the process, as far as I can tell, the recompile/reobfuscate scripts require that all the source code live in one place, underneath forge/mcp/src/minecraft (and typically in the net or org folders under there -- java package names).

 

All of my source stuff is going to be elsewhere -- in my case, I'm using one git repository per "thing" (in this case, Linking Tweaks), or one directory per API package (in this case, the Mystcraft API). And, Eclipse is putting all the .class files right next to the .java files (and note that the minecraft .class files are separate from the minecraft source files).

 

What is considered "best practices" for organizing the source code for mods, on the assumption that you'll be working on multiple mods, some of which are yours, some are API's of other people, etc., to permit easy compiling, without accidentally modifying stuff you are not supposed to (I already accidentally had a refactor alter the copy of the Mystcraft API I'm using, so this isn't a pointless question.)

 

(The tutorials I've seen are all at the "Here's how to make a block", or "here's how to make a recipe" level -- nothing on "Here's how to organize code to keep multiple mods separate and clean".)

Jeb! The sheep! The fence pens, they do nothing still leak!

Link to comment
Share on other sites

Hi

 

I would suggest that any API code (that you don't want to accidentally change) should go in a Library.  This is what Forge does for the 1.7+ releases.

 

If you have multiple mods at once that you are working on - I've never done this but I imagine you just have different top-level packages for each.  The "Pahimar setup" appeared to have something like that (although I never used it either) - it's out of date now with the Gradle builds but the approach might be what you're after.

 

-TGG

Link to comment
Share on other sites

Alright, how do I set up a library?

 

For a specific example, lets say I wanted to use the Mystcraft API.

http://binarymage.com/mystcraft/publish/mystcraft-api-1.6.4-0.10.12.01.zip

 

If you have multiple mods at once that you are working on - I've never done this but I imagine you just have different top-level packages for each.

The goal is multiple small, independent mods. For example, the current (finished) is a tweak to reduce the OP teleportation effect of Mystcraft. Next will be a terrain generator to replicate various vanilla worldgens in mystcraft ages (read: perfect ability to import old worlds, seamlessly, into ages, by calling the appropriate worldgen based on the generator-settings, level-type, and generator-options strings.)

 

Jeb! The sheep! The fence pens, they do nothing still leak!

Link to comment
Share on other sites

If you are using Gradle, you can easily set up multiple projects in the same workspace; check Lex's tutorial:

 

 

Also, after getting tons of help from GotoLink on using one of his APIs and then writing one of my own, I put together this little piece that you may or may not find helpful:

 

http://www.minecraftforum.net/topic/2496232-tutorial-modding-with-apis/

 

Hope that helps!

Link to comment
Share on other sites

If you are using Gradle, you can easily set up multiple projects in the same workspace; check Lex's tutorial:

 

 

Also, after getting tons of help from GotoLink on using one of his APIs and then writing one of my own, I put together this little piece that you may or may not find helpful:

 

http://www.minecraftforum.net/topic/2496232-tutorial-modding-with-apis/

 

Hope that helps!

 

I am not using Gradle; this is for 164.

 

Hmm ... looking over your tutorial, it seems that Gradle can be used in 164. So ... I've only seen 17x tutorials for Gradle. And none of the mods that I'm working with are Gradle.

Jeb! The sheep! The fence pens, they do nothing still leak!

Link to comment
Share on other sites

I am not using Gradle; this is for 164.

 

Hmm ... looking over your tutorial, it seems that Gradle can be used in 164. So ... I've only seen 17x tutorials for Gradle. And none of the mods that I'm working with are Gradle.

Gradle has nothing to do with the mods per se, it's just a more convenient way of organizing / setting up your workspace. For 1.6.4, you need Forge 9.11.1.964 in order to use Gradle (which I highly recommend).

 

If you have an existing mod, the easiest way to switch to Gradle is to follow Lex's tutorial to create an empty example mod folder, then delete the example mod and just copy your existing source code into the /src/main/java/YourCode folder, and assets into /src/main/resources/assets/your_mod_id/Folders folder. Once you've done that, import it into Eclipse as an existing project and it should work great (make sure to change the values in the build.gradle file for when you export your mod).

 

Rinse and repeat for however many mods you have, and there you go, you've got them all in the same workspace, but as independent projects that you can run one at a time in your debug client - that's a huge step above the mess that was working with MCP and having all your projects in the same source directory, at least in my opinion xD

Link to comment
Share on other sites

For 1.6.4, you need Forge 9.11.1.964 in order to use Gradle (which I highly recommend).

 

If you have an existing mod, the easiest way to switch to Gradle is to follow Lex's tutorial to create an empty example mod folder, then delete the example mod and just copy your existing source code into the /src/main/java/YourCode folder, and assets into /src/main/resources/assets/your_mod_id/Folders folder. Once you've done that, import it into Eclipse as an existing project and it should work great (make sure to change the values in the build.gradle file for when you export your mod).

 

Now for the $128 question: If I'm working with an existing 965 mod, can I turn it into a 964 Gradle mod? Will it load at runtime if the user has 965 and other 965 mods?

 

My first project is a tweak to an existing mod (Veo's "Linking Tweaks".).

My planned next project is a pair of symbols for worldgen options for Mystcraft.

 

After that ... comes some choices.

Jeb! The sheep! The fence pens, they do nothing still leak!

Link to comment
Share on other sites

Now for the $128 question: If I'm working with an existing 965 mod, can I turn it into a 964 Gradle mod? Will it load at runtime if the user has 965 and other 965 mods?

 

My first project is a tweak to an existing mod (Veo's "Linking Tweaks".).

My planned next project is a pair of symbols for worldgen options for Mystcraft.

 

After that ... comes some choices.

Yes, you can switch between 965 and 964 without any problems. In fact, they are exactly the same except for the fact that 964 supports Gradle, whereas 965 does not. Whether you do or do not use Gradle has absolutely no impact on your end users.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.