Questions About Mod Design and Compatiblity

[neovista]

So, I've finally gotten a decent idea for a mod that I want to develop; however, I have some design/compatibility questions.

 

1) I want my mod to be easily usable with other mods (mainly IndustricalCraft and BuildCraft) and use their power systems (if present, and it would be configurable as to which one would be used), but I don't want to make the mod require that these mods be present - I'd like it to be able to stand on it's own as well. Any advice/tips on how I'd go about doing that?

 

2) I'm unsure as to whether I want to implement WorldGen (though, I'd only be doing 1 or two new Ore Types) as it seems to me that WorldGen is almost excessively overused (though the Ore Dictionary has lessened the visual impact) and I could just as easily go along the path of having the "base ore" as something that can be crafted. Any thought one way or the other?

 

I had some other questions, but they are much more Forge specific in nature and can wait until I finish designing the mod

[Xfel]

For 1): Many mods (IndustricalCraft and BuildCraft for sure) provide a seperate API download, which contains .java files with the general api classes. You can include these files into your mod's source and use them for interfacing. Normally, you are allowed to redistribute these classes with your mod, so that it will run no matter whether the other mod is there or not.

[gcewing]

Including the other mod's API files in your mod is not the best idea, because it means that when the other mod is present, there are two copies of the API files around. If they're identical, that's not a problem, but if the API changes in any way, the presence of outdated API files in your mod can break the other mod.

 

A better way is to isolate everything that references the other mod's API into a separate group of classes that are not referenced directly anywhere from your main code. Then at run time, test for the presence of the other mod, and if it's there, use reflection to dynamically load and instantiate a class that creates and registers all the blocks, items, etc. that use the API. And then ship your jar file without any of the other mod's API files in it.

 

If you do things that way, your mod has a good chance of surviving updates to the other mod's API, as long as the changes consist only of adding new interfaces and methods, and not changing any existing method signatures.

 

If you haven't used reflection before, read up on Class.forName(), getConstructor() and invoke().