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.

I know that MCPatcher asks you to store mod packages in a subfolder of .minecraft/mods by default, since the original ModLoader only checked the top level. It's not a good idea, obviously, but I guess that would explain the other thread. I've gotten around the problem by using MultiMC for the time being. I never had any problems developing pure Modloader mods with MCP/Eclipse, so the somewhat ugly loading strategy that Risugami used apparently worked pretty well. That said, I will leave it to cpw to figure out the best overall solution. Thanks for passing the message on to him.

I'm having this problem (posted on Aug. 19th). While the author of that thread may not have been very diplomatic, what he was reporting is an actual issue. The problem appears to be the way that the newest FML for 1.2.5/1.3.x searches for mods. It uses the minecraft classpath(s) as a starting point to look for mods in minecraft.jar. MCPatcher adds the root ".minecraft" directory as a classpath, causing FML to attempt to load all mods in the .minecraft folder and all subfolders. Any unwanted mods that happen to be lying around (for example older versions or in my case the contents of the MCP folder) get picked up and loaded. Those unwanted mods are what cause the crash. I reported this to the author of MCPatcher as well. I know that some people are not fond of MCPatcher, but I think that this might be something worth changing about FML regardless. Checking the classpaths may seem more elegant than checking minecraft.jar explicitly, but I would suggest that a more limited approach (only load mods from predetermined locations) would be better. FML Log Excerpt (the whole thing is on pastebin): MCPatcher Log: