However, I did want to create this quick post to help people potentially convert any existing add-ons that use Modloader to the new system I'll be putting out with the next release:
-First, obviously BaseMod is no longer present. Your mod class should now inherit from FCAddOn, and one additional step is required to "register" your mod, and that is to instantiate its class as follows:
Code: Select all
public class FCBetterThanWolves extends FCAddOn
{
public static FCBetterThanWolves m_instance = new FCBetterThanWolves();
}
-FCAddOn contains a single abstract member function which you will need to override (a compile error will result otherwise), which is the Inititialize() function. As the name indicates, this is called when Minecraft first starts up, and is generally where you should do such things as registering blocks, etc.
-The FCAddOn class itself is extremely bare bones. I do not include any "convenience" functions in it (basically...this is a "pure" API with no "library" type functionality), of which Modloader has a number for handling things like registering blocks, creating custom packets for opening guis, and that kind of thing. The only time I include hooks is if the existing vanilla code structure makes doing something impossible otherwise without base class modifications. If you are uncertain as to how to do something as a result, then I suggest taking a look at how BTW is doing such things, as it is itself an FCAddOn. If you need a specific additional hook that I haven't included (I've only added ones for what I need myself and for what others have told me they need), then post the request to the appropriate thread as you usually would.
-There is no functionality present for specifying which mod is initialized before or after which others. However, knowing that for add-ons it may be important to do so before or after other mods (particularly BTW), I've included PreInitialize() and PostInitialize() functions in FCAddOn that are called before and after *all* mods are initialized. Thus, if any part of your initialization process is dependent on order, just override those and plop those parts into the appropriate function within your mod class.
-Unlike ModLoader, this obviously all works for both client and server compiles. However, if you haven't done server coding before, you should be aware that not all functions that exist on the client also exist on the server, thus your mod may require slight changes (usually removing code that pertains specifically to the client) in order to function. In the case of FCAddOn, all functions that only apply to the client version are clearly prefaced with "Client".
-I've included basic logger functionality in the FCAddOnHandler class to provide a central place where BTW and add-ons can log relevant information (similar to how modloader.txt works), so that players will know where to look if something goes wrong (it outputs to BTWLog.txt). If you want to make use of it, check out FCAddOnHandler.LogMessage(). Note that messages logged via this method will also appear in the server window if you're running an SMP server.
-As a final note: keep in mind, this isn't intended to be in any way noob-friendly. As I said, I've kept it extremely bare bones to minimize my own development investment here. It works, and should work very well, but I'm certainly not performing all the error checking and hand holding that ModLoader tends to within its code. Thus, if you fuck something up, don't expect a nice little message indicating what it was that you fucked up; expect a crash, or for your add-on to just not function.
I think that covers the basics. If there are questions pertaining *specifically* to the above, I'll endeavor to answer them, but please don't turn this into a "does it have 'foo' hook?" thread. In such cases, assume the answer is 'no' by default, and request it in the appropriate thread if you really need it.
