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

Questions About Mod Design and Compatiblity


neovista
 Share

Recommended Posts

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 ;)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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().

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.