[1.8][SOLVED] What is the best file structure for a mod?

[SuperGeniusZeb]

So in trying to mod for the first time I'm finding out just how difficult it can be when you follow one set of tutorials and then jump to another one because the first one never told ou how to implement metadata blocks, but then the 2nd one is setting up the classes and functions in different files with different class/function names and then this 3rd tutorial you go to has more information you need but apparently the way you're setting up your code won't allow you to implement the solution because you're using a different structure and other crazy confusing stuff.

 

Basically, I don't know how to set up my mod's code. I understand most of the basic concepts of registering blocks/items into the game, as well as their models, but trying to follow a tutorial is difficult when you've never modded before and the classes, files, and methods of getting things done don't work with the way you've already set up your code.

 

So what do you think is the best structure for a 1.8 mod? Should an item's model be registered in the same class file as the item itself? What exactly is supposed to be done during pre-init, init, and post-init? Right now I feel my code is full of patchwork methods of doing things, and some things work but are accomplished inconsistently from other things since I've followed so many different tutorials. I'm sure this probably sounds like a vague question, but I feel like I need to do a rewrite from the ground up... except that I don't want to use a structure of doing things that is inconsistent or inefficient or won't work with certain things like metadata blocks with textures based on metadata. So how should I set up the packages, and what is the best way to register items and blocks (especially for a mod that happens to be about monochrome colored blocks/items in 14 colors and 5 shades, making nearly every block/item identical, aside from some additional special blocks/items), as well as their models/textures? I've seen several tutorials, and they all seem to put various methods/classes/variables/etc. in different places (and to make it even more confusing, they give them different names as well), and right now I'm confused as to which path to follow.

[Ernio]

There is no silver lining. Find your own stylr. Improve it with stuff you learn.

 

As to forge-oriented "rules".

 

preInit() should load configs and initialize items/blocks + register them. general rule is - all registry-related stuff goes to preInit().

 

But wait! There's more! In init() you should do all stuff regarding rendering. That is because since all registering happend in preInit(), it is logical that rendering code needs know who will use given rendering stuff, thus - it happens in init(). In init you would also register recipes and stuff that use registered earlier items/blocks/entities.

 

postInit() is used generally to communicate between mods - e.g "unregister something if some other mod was installed".

 

Can't say much without more direct questions.

[jabelar]

A lot of organization is a matter of style. On the bigger mods I've worked on, the classes are usually first grouped by whether they are client (like renderers and models) or common, then simply grouped by type (entities, items, blocks, ai, etc.)

 

Regarding your specific question about registration, I prefer to have ability to control the order of the registration as in some cases it matters (like with crops the order that the ItemSeed and BlockCrop are registered matters). So I don't register in the constructor of the class. But if you make a registration method in your class and call that, that would still give you control of order.

 

I would look at big open source mods by solid coders and try following their organization.

 

Additionally, the organization depends a bit on how big the mod is. A simple mod with a couple blocks doesn't need a complex organization, but a comprehensive mod with entities, structures, packets, guis, etc. needs good organization.

[weckar]

In addition to what's already been said, I personally find (as a java programmer, not a modder) that organising assets properly is 100x more difficult than organising classes.

With the way minecraft loads things, I imagine this being even more true.

In other words, get that right early.

[jeffryfisher]

So in trying to mod for the first time I'm finding out just how difficult it can be when you follow one set of tutorials and then jump to another

Indeed... for your first mod, do something dirt simple, something for which you need only one tutorial. Well, you'll need an installation tutorial followed by a 1st-mod tutorial. I recommend getting both from the same author because even those can have elements of "style" that need to fit together.

 

because the first one never told you how to implement metadata blocks

Blocks with subtypes are best left to 2nd mod and later. You'll find out why when you get to the json files. Forge has invented a nifty way to reduce the tedium (mcforge.readthedocs.org/en/latest/), but you should do a simple mod end to end and taste success before climbing that learning curve.

 

...and then this 3rd tutorial ... has more information you need but apparently the way you're setting up your code won't allow you to implement the solution because you're using a different structure and other crazy confusing stuff.

Even in 1.7, but especially since the jump to 1.8, there's a whole raft of features required in every mod. Consequently, experienced modders, who code for multiple mods rather than just one, have a tendency to "factor out" those common features and encapsulate them in some idiosyncratic shared package that makes sense to themselves and nobody else.

 

For instance, for my own series of four mods (with more planned), I have written an abstract mod class that each of my mods extends. My abstract class does a number of things that every mod must do, and it has some methods that multiple mods need to call. For example, the abstract mod class defines the common proxy class inside of itself. Every mod inherits it, so I don't need to go to the trouble of creating a new one every time I write a new mod.

 

For your first mod, you should probably stay away from any "fancy" structure; just write a simple mod as if it were the only mod you ever planned to write. After you've made your second mod and see what each has in common with the other, then you may think about ways to avoid code duplication. Warning: My approach has the drawback that if/when I "improve" my abstract mod parent class, I must rebuild all of my mods so they can play nice with each other.

 

Basically, I don't know how to set up my mod's code.

Your mod will have a "main" class having the @Mod annotation. That in turn will have annotated preinit, init and postinit event-handler methods. Incidentally, there are additional handlers you can have in there too, but simple mods won't need them.

 

Because of the way that rendering is done for mc 1.8, and because rendering is a client-side only feature, any mod that defines any block or item will need a proxy. The "common" proxy class will mimic your main class's preinit, init and postinit, but the methods will probably be empty (since mine are shared among mods, this is where I write status to the log). A client proxy class will extend the common proxy and fill in the client-side rendering setup code (e.g. calls to a "mesher"). Read about the sided proxy annotation for instructions on how to declare these things. Forge will then figure out which proxy class to inject at runtime so you don't have to.

 

Beyond that, you add classes to control the behaviors of the things in your mod. If you have some items, then each may have its own class, possibly extending one of Minecraft's item classes so you can hitch your wagon to existing functionality and only need to code your idiosyncrasies. Likewise blocks. When in doubt, look at the vanilla code (located in ~<Forge dir>\build\tmp\recompSrc\net\minecraft). If you don't have that, then you might want a better Forge installation tutorial that sets up a decomp workspace instead of a mere dev workspace.

 

Should an item's model be registered in the same class file as the item itself?

No, I don't think so. The server needs items, but only the client needs rendering info like models. An item will likely be registered by either your main class or the item class itself. However, item models are "meshed" in a client proxy.

 

What exactly is supposed to be done during pre-init, init, and post-init?

In general, pre-init constructs things, and init operates on those things. Each also calls its parallel method in proxy.

 

For example, my preinit is full of block and item assignment to "new" expressions (my blocks and items registering themselves). Note: There's exactly one and only one instance of each block and item in the whole program; that one instance is the program for all occurrences of that thing in the world.

 

My init method has recipes and achievements. Its client-side proxy meshes item models

 

My post-init method registers a game-time event "listener" (not to be confused with mod-loader event handlers in your main mod class).

 

Right now I feel my code is full of patchwork methods of doing things, and some things work but are accomplished inconsistently from other things since I've followed so many different tutorials.

Once you've learned Forge from a Forge tutorial, the best tutorial for actual Minecraft features is the deobfuscated Minecraft source code that I mentioned above.

 

So how should I set up the packages

Your first simple mod should be one package. In general, each new mod is a self-contained package. If you graduate to shared code, then you might make one shared package plus one package per mod. By the time you get fancier than that, you'll have lessons to teach the rest of us.

 

a mod that happens to be about monochrome colored blocks/items in 14 colors and 5 shades

I've seen this mod described elsewhere. I think I recommended one abstract class for all of the shared functionality. That would be extended by five classes representing the five shades. These would become five distinct block instances. Each of those five classes would have 14 subtypes based on block metadata (which means learning about class BlockState).

 

making nearly every block/item identical, aside from some additional special blocks/items), as well as their models/textures?

The json files will drive you crazy, but at least Forge has a custom format that will spare you from at least some of the Cartesian product: mcforge.readthedocs.org/en/latest/

 

When you get down to brass tacks, try searching for specific keywords (like class names) that you're up against. I've found that Google does a better job of finding threads on this site than the forum search does (because the forum search tends to dredge up blizzards of error logs and crash reports). A more global search can turn up other modding forums too. Almost any hurdle you face has already been discussed. When that fails, start a new thread specific to the crux of your problem (it becomes more useful for the next person searching for the same thing).

 

Good Luck!

[SuperGeniusZeb]

Thanks for the tips and suggestions, everyone! It turned out that for my particular problems, wiping my class files clean and starting fresh helped me to figure out how to get several things working and how certain things are supposed to work, and I've restructured my mod to be more modular, consistent, organized, and compatible with the pre-init/init/post-init structure. I'll keep in mind what you all have said, and hopefully my mod's development should go smoothly now. (And when I'm finished I'll make sure to post a topic here showing you the completed mod!)

 

Again, thanks for the help.