FML ignores @Mod annotations on Modloader classes.

[JRoush]

I would like to offer dual support for FML/Modloader.  I don't have a compelling reason to break Modloader compatibility since quite a few people still use it and I don't actually need any FML or Forge features.  That may change at some point, though, and I'd like to get a head start by providing a proper interface to FML.

 

The problem is that FML checks if a mod is ModLoader compatible before it checks annotations, and thus my mod gets treated like a legacy Modloader class even though I provide an FML-specific interface.  Most Forge mods don't have this problem because they aren't still using Modloader-compatible classes.  I can see how that would be the "preferred" solution, but as I said I have no real reason to ditch Modloader yet.

 

I could simply put the annotations on another class and make that my FML interface, but that would not stop FML from finding the Modloader class as well.  There appears to be no way to deactivate a mod, or for a mod to deactivate/hide itself, so ultimately I'd be stuck with two registered mod classes (unnecessary and ugly).

 

Would it be possible to alter the ModContainerFactory priorities so that FML annotations are checked first?  Is this the correct place to ask?  Should I be submitting a pull request somewhere, or is it sufficiently obvious what would need to be changed?

 

EDIT:  I have been able to work around this problem by having two separate mod classes, one for Modloader and one for FML.  I said this was "unnecessary and ugly" above, and it is, but apparently making one class the parent of the other in the mod metadata collapses the two into a single entry in the in-game mod list.  That was the only side effect of having two mod classes that was visible to the player, so fixing it made having two separate classes an acceptable solution.

[keepcalm]

You can submit a pull request at https://github.com/cpw/FML. That's probably the easiest way.