FMC stands for Fyddle for Minecraft. It's a mod development system for Minecraft v1.8 (and now v1.8.1), comprised of three components: FMC-Core, Fyddle, and Meddle.
FMC-Core is the Minecraft-specific component, which handles all Minecraft-specific tasks such as downloading game files, automating the process of breaking Minecraft down into Java source, assisting in the recompilation and creation of mods, and executing Minecraft with Meddle for testing mods.
Fyddle (pronounced "fiddle") is a general-purpose tool designed for aiding in deobfuscation, decompilation, and modification of Java applications.
Meddle is a general-purpose mod loader, designed to allow loading of modified class files and data at runtime, without the user replacing content in an application's original directory or JAR.
FMC is a work-in-progress. At this time it's limited to traditional JAR mods, and currently focuses on client-side mods (though depending on the mod you write, it might be compatible with the server as well). They can be launched either through placing them into a Minecraft JAR, adding them through a launcher which supports it such as MultiMC, or via Meddle. This is still the first stage of the overall goal; in the future, base-class Meddle mods will require little to none of the original class file, and Meddle will be required.
Using FMC is simple. It's broken down into basically three commands: 'setup' will create the initial environment necessary to make mods, 'build' detects changes you made to the source directory and generates mod archives automatically, and 'run' will start the game so that you can test your work. That's pretty much all there is to it.
For more details, see the readme files inside of the JARs in the "core" directory of the FMC archive.
This is untested on various platforms. If you have any problems, let me know, specifically the OS you're using and whether it's 32 or 64-bit. This is a factor due to native libraries that Minecraft requires.
There is no installer yet for using Meddle with the vanilla Minecraft launcher, although it is fully compatible. This wasn't a priority since there are currently other ways to run mods generated with FMC. I can add instructions on how to install it manually if there's interest, but an installer will be available soon.
There is no Eclipse or other IDE workspace available yet, since I have yet to dig into the file formats involved. If you're familiar with your IDE though then you may be able to figure this out on your own, but feel free to ask if there's anything you need to know.
You might see some assets being skipped during setup. This is normal, since some assets are referred to with different names, but are actually the same file. FMC ignores files that already exist so that you can re-run setup if you want without downloading everything again.
You will probably see one patch fail during the setup process. This is also normal, since code generated during decompilation is not always the same on each run, so multiple patches for the same result are sometimes necessary.
Q. MCP can already decompile the game. Why not just use that? A. There's no reason not to! MCP has always been great, and is likely to have more accurate mappings due to its connections with Mojang. FMC is simply an alternative, which I created partially just to see if I could, and partially to have my own modding software which doesn't rely on others to update. It's also intended to be the backbone of an API, which is not yet included.
Q. Is FMC compatible with MCP? A. From just a Java class standpoint, yes, JAR mods from both would work together. But from a development standpoint, no. The mapping file formats are incompatible, signatures/exceptions/fixes/patches would differ, and the decompiler is not the same version and could provide different results, as could Fyddle's own reconstruction process. Not to mention the mappings themselves are different.
Q. Is FMC compatible with FML/Forge? A. No. Meddle overrides the standard classloader to load and modify classes at runtime, which would prevent FML from doing so, and vice-versa. There could be a Forge port in the future, but that's not a priority at this time.
Q. How much would FMC's mappings differ from MCP? Would I have to relearn the game's code? A. That depends. The mappings themselves were all created by me, from my memory with previous modding, references in the code itself, general deduction, and outright guessing. This means some names may be identical, while other names could be distinctly different from MCP, especially regarding some of the 1.8 changes where new concepts were introduced. Some names could also admittedly be incorrect or misleading, and some are likely to change over time as I better learn the code. Mappings will always be an ongoing process, but I'll do my best to make it as painless as possible.
Q. Can I submit mappings? A. Probably not for the time being. That could result in names from MCP or other mapping projects being submitted, either intentionally or inadvertantly, and I would rather not give the impression that I'm taking them from elsewhere. The MCP team doesn't want others taking their mappings, and given the work involved you can hardly blame them. Perhaps when FMC is more mature I'll reconsider. But in the meantime there's nothing stopping you from adding custom mappings to your personal copy of FMC if you need to!
Q. Is FMC open-source? A. Not at this time. It started as a personal project and a personal challenge. It's still a work-in-progress, and various aspects are subject to change as I work towards the ultimate goal of a full development system with an API.
Q. What are these "fyClassID" variables added to every class? A. Those are added by Fyddle to aid me in automatically identifying and extracting names from classes after refactoring code during deobfuscation. You'll be able to disable them in the future (if not by default). Fyddle will include the other tools to allow you to extract your own name changes in the near future as well, I just didn't see it as necessary to focus on at this point in time.
Q. Can I include Meddle in a modpack? A. I'm not sure if there's much use for it yet, but Meddle's license allows for redistribution.
Looks like Modloader, but different. I'm interested...
ModLoader had some hooks for adding blocks and things, where as the Meddle component of FMC is still designed to be a generic loader for any Java application. So this is still closer to MCP than that. Don't worry though, the API will handle block registration and everything.
I do already have some API code (named FyPI), but I've decided to hold it back until I finish my system for bytecode manipulation, so that it doesn't have to be a JAR mod and source patches. I don't really want to use binary patches like FML/Forge does either if I can avoid it; I'd rather keep it minimally-invasive into the original JAR. I'm not using the ASM library, either, because it doesn't work quite like I want. So I've pretty much been rolling all my own code to do all of the Java class manipulation in Fyddle/Meddle so far, which has certainly been educational.
And as kind of a general update in regards to Fyddle itself, people might be interested to know that I plan to make a second attempt at automatically determining exceptions in obfuscated code. I tried before but it wasn't very successful, so currently I still repair all exceptions in Minecraft manually, then extract those, which are reinserted during FMC's "setup" process (during Fyddle's "reconstruct" process, more specifically). Fixing exceptions manually isn't particularly hard, it's just time-consuming and tedious work. It's going to be a lot of work to try to determine them automatically though as well, because I'm going to completely reconstruct the stack frame of a method and work from there, but it might be worth it in the end. I ran Minecraft 1.4.7 through FMC the other day and had to fix all the exceptions manually again, which is what spurred my renewed interest in trying to automate this process. I'd really like to make mappings for several older versions of the game, just for fun, because I still enjoy playing and modding old versions, even back into the alphas and betas. I just don't want to have to fix exceptions manually for them as I go.
Just wanted to post an update since it's been over a week. There's no new version yet since the major feature of the next version will be the ability to modify bytecode, which is crucial to releasing an API and mods without having to include Mojang's code like with JAR mods. I'm thinking that will be ready inside of a week. Currently I can disassemble a method down to a series of Java classes, which from there can export it as text, or export back out as bytes to save in a class. At this point, after going through this process, they match identically to the original classes, so that all seems to be working fine. Now I'm working on the part to actually insert opcodes, or chunks of assembly code via text, which means basically I'm writing an assembler. But it shouldn't be too bad, and will be a big step forwards.
If you're wondering why I didn't just save myself the trouble and use the ASM library like Forge, you might be interested to know that I asked myself the same question a few times! But after getting past the trickier parts, I'm glad I stuck it out. ASM doesn't work exactly the way I wanted, I prefer to avoid external libraries when possible, and a big part of it is still the experience. I'm pretty comfortable working with the Java class file format now, which I doubt I would be had I used ASM from the start.
UPDATE: Just so you know, the "inside of a week" bit got thrown out the window when Mojang released 1.8.1, because I decided to migrate to that now instead of wasting more time on a fairly buggy 1.8. Updating between game versions is something I knew was coming eventually anyway, so I'm using this time making the tools necessary to map between two versions, which will come in handy in the future as well. At this point in time I've mapped all of the class names over, and today will probably finish mapping the fields/methods/etc inside them, and lastly will convert exceptions and everything else. Hopefully then the migration will be finished and I can get back to work on bytecode modification. I may or may not release an update to FMC just for 1.8.1 without the extra features. Depends on how much I can get done in the near future.
I'm bumping the thread to announce that FMC v1.1 is released. Minecraft 1.8.1 is now supported!
The mappings are essentially direct ports from 1.8 (as direct as possible, at least). This took a lot of work, despite this being a somewhat trivial Minecraft update. I've never dealt with having to convert anything between game versions, so it was a learning experience, and I had to come up with some extra tools along the way. Hopefully it won't be quite as painful next time, but I certainly don't look forward to large updates! But I felt that 1.8 had enough bugs that going to 1.8.1 should be a priority.
FMC-Core/Fyddle/etc don't have a lot in terms of updates, since the primary focus was updating Minecraft versions. There's still some changes under the hood though, some of which to make things easier in the future.
As always, if you have any problems/bugs/etc, let me know!
The Meaning of Life, the Universe, and Everything.
I'm going to try it out and see what it can do. I honestly don't think it will replace forge (if that was the intention) but my curiosity has gotten the better of me. (Also make sure to tell people that they need to have their JDK in an environment path, somehow I never had mine in and I was getting some errors)
Can't seem to get the "fmc-setup" to work. (unable to detect javac!)
I've setup the JDK in the environment path and it works in the command prompt. Using Win 8.1 with JDK 1.8.0 u25
If you're able to run "javac" from the command prompt, then you should be able to run fmc_setup from the same prompt. If not, something weird is definitely going on, because FMC's Java test is literally it trying to execute a javac process.
Keep in mind that if you're setting up your environment path in one command prompt window, but trying to run fmc_setup from another (or by double-clicking it in Explorer), then the environment changes aren't global. You would have to setup the environment in that Windows system properties GUI area for it to be used everywhere. Otherwise you have to use FMC in the same command prompt that you set the environment in. You might already know all this, but I'm pointing it out just to make sure, and for anyone else's sake.
I have been looking for an alternate method of modding than using MCP, mainly because in version 9.10-pre I cannot reobfuscate all modified and unmodified files without causing many errors in launching Minecraft. Hopefully this will partially allow that and potentially allow edited map files for reobfuscation.
I am also keen to help in any way possible with this to get it up to standards for general modding use
Yep, an MCP alternative pretty much sums it up for now. And I hope it offers a benefit to what you're working on, DoubleParallax, despite its early state.
For anyone wondering about progress who doesn't follow my ramblings on Twitter, I've made quite a bit. Bytecode manipulation works, being one of the big things. And I've actually added enough functionality to the new API layer (FyPI) to completely port my Hopper Ducts mod to the platform. The mappings got quite an update during all of this, too, with things both added and changed.
I haven't made another release yet because there's a lot of loose ends to tie up to make these new features into a useful development platform. The API may work but there's not actually a build system to implement it. There's also not a proper system in place yet for managing the loading of API-based mods (which will all ride on top of the Meddle mod loader, already in FMC). It's like parts scattered across a workbench with exposed wires connecting them all. It still has to be fit into a box before anyone can use it reasonably.
It looks like the upcoming Minecraft 1.8.2 may just be some bug fixes, so I might sit on 1.8.1 for a bit longer this time instead of pissing away weeks updating mappings again.
Is there a difference between the completion of version 1 (1.8) and version 1.1 (1.8.1) or are the classes/methods still obfuscated the same amount?
I believe I'd stopped updating mappings for a while to work on FMC itself when 1.8.1 was released, and then it took a couple of weeks to actually do the transition, so the two are probably pretty on-par with one another.
Keep in mind that the 1.8.1 version will get a significant mapping update soon. I might be able to convert some of that back to 1.8 as well if there's enough interest. No promises though!