good days

 

i have a mod i wanna split in multi parts,

 

per example

in the minecraft 1.7  the mod alienvs predator made by arisux  has main mod package AIRI.jar its contains the materials and blocks for the mod.

and the package AliensVsPredator.jar  has the mobs and  the weapons.

 

and the  package  AliensVsPredator.jar demands AIRI as dependency

 

someone  tellme that can be done whith a modified version of graddle but google has not confirm it

in the other side google speaks about an utility from chikenBones but for 1.7 and this 1.8

 

how this could be achive

Maybe make the different parts like several Mods, where you have a main mod wich require several ChildMods. and all the Child mods require the main mod? just like you implement an API etc.

I'm not sure how that mod specifically does it, but I think generally these are just separate mods that are dependent and maybe have an API to better facilitate the interaction between them.

 

The dependencies have to be arranged in the proper order. For example, if one part's code references a block from the other part's code, then you need that mod loaded first.

 

The API exposes the methods you want for interaction, so if you had for example a vampire entity in one part and wanted to allow other parts create new vampire types, then you'd provide an API for createVampireEntity() or similar.

 

The key point though is that those guys didn't just take an existing mod and split it -- instead they coded their mod from the start to be in multiple parts. That takes good structured approach to the mods.

 

Why do you want to split your mod anyway? If you want people to be able to only enable certain things in your mods, you could more easily just make it configuration options.  The Minecraft Forge wiki has a tutorial on that here: http://www.minecraftforge.net/wiki/How_to_make_an_advanced_configuration_file

 

You can even make a nice GUI so the player can change the configuration from within the game (instead of manually editing the config text file). I have a tutorial on making a config GUI here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-configuration-guis.html

Why do you want to split your mod anyway? If you want people to be able to only enable certain things in your mods, you could more easily just make it configuration options.  The Minecraft Forge wiki has a tutorial on that here: http://www.minecraftforge.net/wiki/How_to_make_an_advanced_configuration_file

 

I'm doing it right now because while the n mods together share a theme, they are not reliant on each other and people can decide to only download the ones they actually want.  Maybe they want one aspect and not the others.

I'm doing it right now because while the n mods together share a theme, they are not reliant on each other and people can decide to only download the ones they actually want.  Maybe they want one aspect and not the others.

 

Sure. You can also just allow the players to configure one mod the way they want. I usually have configuration options to disable certain things. It just seems like splitting a mod might be a lot of work. I know you're an experienced modder, so I'm not questioning whether you should do it, but the guy who started this thread may not be as confident.

 

 

I could, but there are a lot of things that work in tandem. Aside from things that are truly configurable (e.g. length of a year), my configs don't have much in them. You can't just turn one thing of and expect everything else to work.

Why do you want to split your mod anyway? If you want people to be able to only enable certain things in your mods, you could more easily just make it configuration options.  The Minecraft Forge wiki has a tutorial on that here: http://www.minecraftforge.net/wiki/How_to_make_an_advanced_configuration_file

 

You can even make a nice GUI so the player can change the configuration from within the game (instead of manually editing the config text file). I have a tutorial on making a config GUI here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-configuration-guis.html

Just a random FYI about your tutorial comments: the 'Mod Settings' gui in Forge was never intended to be functional - it was added by cpw purely as an example for modders to see what was possible with the config API. Many of the features (parent/child menus etc) need to be implemented by the modder, but Forge will correctly interpret them.

 

You may want to check out GotoLink's Battlegear2 config code - it's not really 'replacing' the gui menu so much as adding yours to the list of mods with config guis using IModGuiFactory.

damm

no i have more doubs than in the begining

 

 

the trouble begins here 

http://www.minecraftforge.net/forum/index.php?topic=29261.0

 

i could'n add more weapons to mi mod  whithout damage the game textures

and i need add more weapons

 

 

lets say i just let this modmercenario1.8.jar here whith most of the tools materials gui keybind and items

 

and lets say i do a second mod called  modmercenario_moreweapons1.8.jar

 

i need reference the materials from the first mod to make the recipes in the second

 

so here comes mi first cuestion

 

eclipse can load and alredy compiled mod0.jar  while is working on a mod1 and call the clases from mod0 to use them in mod1 ??

 

Why do you want to split your mod anyway? If you want people to be able to only enable certain things in your mods, you could more easily just make it configuration options.  The Minecraft Forge wiki has a tutorial on that here: http://www.minecraftforge.net/wiki/How_to_make_an_advanced_configuration_file

 

You can even make a nice GUI so the player can change the configuration from within the game (instead of manually editing the config text file). I have a tutorial on making a config GUI here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-configuration-guis.html

Just a random FYI about your tutorial comments: the 'Mod Settings' gui in Forge was never intended to be functional - it was added by cpw purely as an example for modders to see what was possible with the config API. Many of the features (parent/child menus etc) need to be implemented by the modder, but Forge will correctly interpret them.

 

You may want to check out GotoLink's Battlegear2 config code - it's not really 'replacing' the gui menu so much as adding yours to the list of mods with config guis using IModGuiFactory.

 

Thanks.  I think my tutorial does the right thing though. In the main menu if you select mods I implement the config gui (yes pretty much just implementing the example). However I also handle the in-game pause menu config gui and replace the example with proper configuration settings. The one piece I hadn't worked through was how to handle multiple mods having ingame config so I'll check out GotoLink's stuff to see if that what he's solving.

 

But basically I think it is weirder to have the in-game pause menu have a GUI that only contains example stuff instead of handling it as appropriate to your mod. At very least people should disable that GUI then for their mod if they're not going to use it.

 

I personally think that all mods should be able to be configured in-game if possible. Whether or not that uses the actual Configuration or GuiCofig classes is up to the modder, although I think it would also be cool if everyone settled on a standard where you could go in and change settings for all your mods through a common interface.

 

Regarding Draco's comment -- I find configurations are perfectly capable of turning off things in your mod. Since the majority of stuff is in registries you can quite simply just not register blocks and stuff (the original poster is citing an example where the blocks are in one part, entities in another). Certainly there can be cases where there is more interaction but I'm not sure how splitting the JARs would make that any easier to manage.

CoolAlias, I checked out GotoLink's code. It is pretty much the same as what I'm doing. I create a GUI factory and call a GuiConfig, whereas he calls a custom GuiScreen. Or maybe I'm missing what you were trying to point out to me...

 

The cool thing about the built in config gui (even if it is just a starting point) is that it automatically creates all the buttons and layout simply based on your Configuration file. So once you set it up, you just have to manage the Configuration and the GUI automatically will show those options, limit the range, allow reset to default, etc. It is pretty slick in my opinion.