Minecraft Forums

Magic Mojo Mod Loader (or M3L for short) is a new mod loader for Minecraft!

For advanced modders, sometimes Minecraft Forge leaves things to be desired. For instance, when mods get more ambitious and try to add some really complex features to the game (Ships Mod, for example), Forge features fall short and modders need to convert their mod into a "coremod." The problem with coremods, is that without support from the Forge API, it's super difficult to make coremods compatible with one another. So most coremods end up causing conflicts with other mods, and it's near impossible for any single mod author to try to code compatibility with every other mod.

To try to solve this problem, I'm creating a new mod loader called Magic Mojo Mod Loader. The basic idea is that this mod loader doesn't have coremods. Instead, the modding API is easily changed and is receptive to request for new features from the modding community. If everyone can get the hooks they want into the mod API itself, then there's no more need fore core mods, and the mod loader can do a better job of ensuring compatibility between mods.

Development status: Backburner'd!

Since I'm taking a break from Tall Worlds Mod, there's not much drive to keep developing M3L, so I'm going to take a break from that too. The short version is, I'm one modder trying to do too many things in limited hobby time. So far the result has been I'm not getting much done on any one of these projects The donation money just isn't there to give me more hobby time, so if I want to get anything done at all, I need to become more focused.

The entire project is open source of course. Contributions are always welcome from other modders. None of this technology is disappearing any time soon, it's just going to start gathering dust.

Now I'm going to focus all of my energy into my Ships Mod and make that mod the best mod it can be. Since I'm no longer splitting my time among too many projects, I should be able to make some real progress, so look forward to some exciting new features there!

M3L is back in action!

After a brief lengthy hiatus, M3L is once again in a working state. I had to do a lot of work to deal with Minecraft's pesky obfusaction (and I was apparently not allowed to use MCP), but all the basic tech that powers M3L is now restored to working order. M3L can successfully transform Minecraft classes! And M3L has been updated to work on Minecraft 1.8.3! See the fun screenshot below for the first transformation M3L did to Minecraft 1.8.3.

Uhhh... that's great. When can we actually load mods?

Like maybe this fun mod here

Here's the plan.

Right now, M3L is a transformation engine for (obfuscated) Minecraft. It has a lot of nice whiz-bang features that should hopefully make transforming Minecraft classes ridiculously easy. It also makes updating to new versions of Minecraft easy too. These tools will let us do the usual things like adding blocks, items, entites, etc. However, these tools will also let us do completely insane things like entirely replacing the chunk loader.

That means M3L is a bunch of tools that will someday let us load mods, but it can't actually load any mods yet. There's still some more work to be done. One bit of work is to figure out what a mod should look like, and what a mod should be able to do to Minecraft.

What's the modding API for M3L?

The fine folks over at Sponge Powered, have spent a lot of time thinking about these questions and came up with SpongeAPI. It seems the main goal of SpongeAPI is to create a stable API for Minecraft that completely shields mods from what Minecraft is actually doing at any particular version. This means theoretically that mods wouldn't have to be updated when Minecraft updates, because SpongeAPI would hide details about what was updated from mods. SpongeAPI does this by creating an imaginary version of Minecraft that doesn't actually exist (ie an interface) and tells mods to only think about the imaginary version. Then, the Sponge implementation of the API has the task of transforming the existing version of Minecraft into the imaginary version. As long as Sponge can do the transformation correctly, the API works and mods will never have to know that Minecraft changed.

These seems like excellent goals, but there's one rub. The imaginary version of Minecraft that SpongeAPI describes is significantly different from what Minecraft actually does today. This means that transforming the current Minecraft into the imaginary version is actually a huge amount of work. It's certainly far more work than I want to do by myself inside M3L.

So, for the near future, I have no plans to make M3L implement SpongeAPI.

If not SpongeAPI, then WhatAPI?

The absolute last thing I want to do is completely fabricate some entirely new modding API from out of the void. If at all possible, I'd like M3L to adopt an existing API for at least the mundane things that have been done before. Like adding new blocks, entities, crafting recipes, etc.

There are already a few modding APIs out there, and making another one that does the same stuff Just Because is madness. No one would ever use M3L if they had to switch to an entirely new API for the Ordinary Things. Ideally, we should only need to add new bits to the modding API for the extra-ordinary things. For the crazy insane new things. For the replacing chunk loader things.

Forge API

The Forge API can handle all of your ordinary modding needs. Let's use that one for the ordinary stuff. Then M3L will create its own API only when absolutely necessary.

M3L will make a best effort to implement as much of Forge API as possible. That means M3L mods will look quite a bit like Forge mods. M3L mods could certainly never work on Forge, but it may be possible that Forge mods could work on M3L. Probably not out of the box. The M3L mod format and the Forge mod formats should be very similar, but they won't be completely identical. Probably chiefly because of differences in deobfuscation. I suspect it might be possible to create a tool that can automatically convert a Forge mod into an M3L mod.

With such a tool, it may actually be possible to play a Forge mod on M3L without the mod author needing to specifically support M3L. Mod authors don't like it when you tweak their mods, break them, and then report those bugs, so we'll have to use this power wisely.

There's one caveat to implementing the Forge API. M3L will not, under any circumstances, allow the use of Forge coremods. M3L mods are strictly forbidden from making direct changes to Minecraft classes. This means that Forge coremods will never ever ever ever ever work on any version of M3L. The whole point of M3L is to make coremods obsolete by improving modding API technology so it can keep up with the imagination of modders.

Compatible with all the things? That's great! When do we get to use M3L?

Obviously, it's going to take while to make M3L fulfill all these goals. Here's the plan for moving M3L in that direction, one step at a time.

1. Screw compatibility with all the things. Make a version of M3L that's just good enough to play Tall Worlds.

The first goal, above all things, is to get a version (any version) of Tall Worlds out there that people can actually play. This means I'll be taking some shortcuts in the compatibility department. The initial release of M3L and Tall Worlds Mod will be compatible with exactly zero things. Don't fret, this is just the first release. Things will get better. I promise. =)

2. Work towards a minimal Forge API implementation that will let modders create the most basic M3L mods.

The first goal here is to add enough to the modding API to let modders add simple blocks.

3. Keep adding to the API implementation, let modders do more and more things.

Then we'll move out from there, adding more and more things to work towards completing the implementation of the Forge API.

4. Start building the M3L API.

Once we have most of the basic modding topics covered, it's time to start showing off what M3L can really do. We can work on APIs for the more advanced modding topics that Forge doesn't do, like custom entity collision, support for large entities, and block-based entities. Support for tweaking (or entirely replacing) the chunk loader.

Everything is awesome open source!

Oh, and M3L is open source! There are no more legal obstacles in my way and I can freely distribute all the required bits and pieces. =D

It's a good idea, but Magic Mojo? Really? How about just Magic?

Edit long time after: I just realized I was first for what I think was the first time.

Hahaha, oops. Cut and paste problem. It should be fixed now.

I honestly don't see the point of yet another mod API. What is it that Forge is lacking? Make a PR? It's just sad to see that quite a few modders are seeing ASM as an easy way out compared to trying to put their hooks into forge. If you can make it generic enough that it's not just specific to your mod, PR would be welcome.

I tend to use ASM as a short to medium term solution. If it's possible for me to do so, I make a Forge PR, and remove my ASM hooks when my PR is accepted.

In my experience, it has been very difficult to get changes from the community (like PRs) accepted into Forge. The management of the project has been fairly hostile towards suggestions from the community, and I just don't think it's worth all the effort and arguing to try to convince the project maintainers that each improvement you want is worth accepting. I think it's better to have a project that is open to community input from the beginning, rather than have to implement workarounds to an inadequate improvement process.

Posting this here rather than futher hijacking acomputerdog's thread:

Quote from Cuchaz

I might not have been clear in the announcement. The point is that mods no longer write hooks. All the hooks are owned by the modding API. But since the hooks are really simple to write, that makes the hook system easy to change, and therefore it should be feasible for modders to get their PRs for hooks accepted. Then there's no longer any need for a coremod system.

I do see what you're getting at. What I wondered is why you've decided to go down the route of making a separate platform rather than just implementing it as a layer on top of (for example) FML as a way of making coremods unnecessary - as in, stick with precisely the same mandate but make an abstraction layer rather than a whole other loader. This means that mod authors can leverage the power of the other platform (and saves you having to reimplement that functionality and concentrate on fleshing out your API) when it makes sense but fall back on your solution when a coremod would otherwise be required, thus addressing exactly the shortcoming you've identified but in the environment of a more mature platform.

The main issue I see you encountering is that you don't seem to have designed with the tweak system in mind, so are you essentially throwing out the concept of being compatible with forge/blazeloader/liteloader/optifine in favour of your own ecosystem? Or do you plan to swap out the functionality in your system for that in the tweak system - because at that point surely you actually are just being a coremod and might as well at least leverage the more advanced mod loading and more developed API in the existing systems.

I'm not saying what you're doing is a bad idea, it seems like a really good idea, what I don't understand is the approach you're taking, it seems to be throwing out he baby with the bathwater so to speak. Just because you can't get code pulled into Forge doesn't mean you can't write a library designed to enhance forge that everyone can use.

Quote from Mumfrey

Posting this here rather than futher hijacking acomputerdog's thread:


I do see what you're getting at. What I wondered is why you've decided to go down the route of making a separate platform rather than just implementing it as a layer on top of (for example) FML as a way of making coremods unnecessary - as in, stick with precisely the same mandate but make an abstraction layer rather than a whole other loader. This means that mod authors can leverage the power of the other platform (and saves you having to reimplement that functionality and concentrate on fleshing out your API) when it makes sense but fall back on your solution when a coremod would otherwise be required, thus addressing exactly the shortcoming you've identified but in the environment of a more mature platform.

The main issue I see you encountering is that you don't seem to have designed with the tweak system in mind, so are you essentially throwing out the concept of being compatible with forge/blazeloader/liteloader/optifine in favour of your own ecosystem? Or do you plan to swap out the functionality in your system for that in the tweak system - because at that point surely you actually are just being a coremod and might as well at least leverage the more advanced mod loading and more developed API in the existing systems.

I'm not saying what you're doing is a bad idea, it seems like a really good idea, what I don't understand is the approach you're taking, it seems to be throwing out he baby with the bathwater so to speak. Just because you can't get code pulled into Forge doesn't mean you can't write a library designed to enhance forge that everyone can use.

If we're going to make a new modding API, I don't see much point in sticking with FML as the mod loading layer. The mod loading layer is essentially hidden from modders anyway. I'd wager that most of them don't even know why FML is not the same thing as Forge. We might as well take the opportunity to make some technical improvements in the mod loading layer while we're re-imagining a mod loading system.

I'm certainly not trying to throw out compatibility with other mod loaders. Compatibility with other mod loaders is actually a big goal for the project, so your comments there are surprising to me. My system does actually use the tweak system in the launchwrapper, so compatibility with other systems (like LiteLoader) shouldn't be hard to do at all. I just haven't implemented it yet because this is a very very early release. I even explicitly mention in my announcement the goal of compatibility with the mod loaders you listed. Of course, this is exactly the kind of feedback I'm looking for at this stage, but I'm puzzled as to why you think I'm not shooting for compatibility as a goal.

It just occurred to me that the fact that I'm using the Tweaker system isn't obvious from the announcement. Here's the relevant source code if you want to explore:
https://bitbucket.org/cuchaz/magic-mojo-mod-loader/src/dea2538ffc7341028ccd29ca3d26ee92844afaa9/src/cuchaz/magicMojoModLoader/tweaker/Tweaker.java?at=default

Quote from Cuchaz

If we're going to make a new modding API, I don't see much point in sticking with FML as the mod loading layer. The mod loading layer is essentially hidden from modders anyway. I'd wager that most of them don't even know why FML is not the same thing as Forge. We might as well take the opportunity to make some technical improvements in the mod loading layer while we're re-imagining a mod loading system.

I appreciate that it's early days and that what you have on your repo is not representative of the final solution, I was just wondering why you'd want to engineer that solution at all when "off the shelf" options exist. If you feel that it's possible to improve mod loading in general then great, and not being tied to an existing platform does have that benefit of course.

Quote from Cuchaz

I'm certainly not trying to throw out compatibility with other mod loaders. Compatibility with other mod loaders is actually a big goal for the project, so your comments there are surprising to me. My system does actually use the tweak system in the launchwrapper, so compatibility with other systems (like LiteLoader) shouldn't be hard to do at all. I just haven't implemented it yet because this is a very very early release. I even explicitly mention in my announcement the goal of compatibility with the mod loaders you listed. Of course, this is exactly the kind of feedback I'm looking for at this stage, but I'm puzzled as to why you think I'm not shooting for compatibility as a goal.

I was mainly trying to fathom the class loading dynamic that's in play here, it looks like you're stacking a custom classloader instead of just having all your class loading logic implemented as a plugin (transformer) for launchwrapper's classloader, or is your custom classloader only used when launchwrapper is not in play? I guess that's the peril of reading code on bitbucket vs properly downloading and playing with it. Anyway I'm going to just keep quiet and watch this project with interest, since it's clear that looking at it now isn't giving a clear enough picture of where you intend it to end up.

Quote from Mumfrey

I appreciate that it's early days and that what you have on your repo is not representative of the final solution, I was just wondering why you'd want to engineer that solution at all when "off the shelf" options exist. If you feel that it's possible to improve mod loading in general then great, and not being tied to an existing platform does have that benefit of course.

I think we could make some improvements in how mods are loaded that might make responding to changes in Minecraft easier. That should hopefully reduce the overall cost of maintaining a mod loading system. But since it would appear to be such a fundamental change to the way mods are loaded now (from the point of view of a project like FML), I decided to start fresh.

Quote from Mumfrey

I was mainly trying to fathom the class loading dynamic that's in play here, it looks like you're stacking a custom classloader instead of just having all your class loading logic implemented as a plugin (transformer) for launchwrapper's classloader, or is your custom classloader only used when launchwrapper is not in play? I guess that's the peril of reading code on bitbucket vs properly downloading and playing with it. Anyway I'm going to just keep quiet and watch this project with interest, since it's clear that looking at it now isn't giving a clear enough picture of where you intend it to end up.

Sorry about that. The confusion is probably my fault since I didn't explain a lot of details about how the mod loader works under the hood. M3L uses the tweaker system on the client to apply transformations to inject the hooks. However, there's no tweaker for the server, so a custom classloader was needed in that environment. M3L is meant to be a mod loader for the client and the server. As far as I know, LiteLoader and BlazeLoader are currently client-only mod loaders.

Quote from Cuchaz

I think we could make some improvements in how mods are loaded that might make responding to changes in Minecraft easier. That should hopefully reduce the overall cost of maintaining a mod loading system. But since it would appear to be such a fundamental change to the way mods are loaded now (from the point of view of a project like FML), I decided to start fresh.

Makes sense, I'll be interested to see how it turns out. There were huge flaws in ModLoader's mod loading system which I attempted to address with LiteLoader, and since then it's evolved and in some ways is more robust than FML's. I'm interested to see what the alternatives look like.

Quote from Cuchaz

Sorry about that. The confusion is probably my fault since I didn't explain a lot of details about how the mod loader works under the hood. M3L uses the tweaker system on the client to apply transformations to inject the hooks. However, there's no tweaker for the server, so a custom classloader was needed in that environment.

That makes more sense, although it might have been easier to just run launchwrapper on the server side like fml does.

Quote from Cuchaz

M3L is meant to be a mod loader for the client and the server. As far as I know, LiteLoader and BlazeLoader are currently client-only mod loaders.

LiteLoader is aimed specifically at client-only modding, which extends as far as single player but I do not target server modding in any way you are correct. However BlazeLoader I imagine must have some server part since otherwise there's no way for it to do the "game changing" part which is the headline capability.

Basically my system is aimed squarely at things which don't add any new blocks, items, abilities or whatever to the game, so I don't actually need a server-side part.

Quote from Mumfrey

That makes more sense, although it might have been easier to just run launchwrapper on the server side like fml does.

It's a possibility. If FML uses launchwrapper on the server (I haven't looked into what's in its server jar yet...) I might even have to use it too to get compatibility to work.

Quote from Mumfrey

However BlazeLoader I imagine must have some server part since otherwise there's no way for it to do the "game changing" part which is the headline capability.

I've always wondered that myself, but I remember acomputerdog saying there's no server modding support in BlazeLoader just yet.

Quote from acomputerdog

That should work, as long as your tweaker is is loaded after mine so that my changes do not override yours. You can tell which classes BL is overriding by accessing the field net.acomputerdog.BlazeLoader.launcher.BLClassTransformer.overrideClasses. It is private atm, so you will need to use reflection to access it. Currently BlazeLoader does not support the server.

FML/Forge's server installer downloads additional libraries (scala, launchwrapper, a few more I can't remember off my head). You could possibly do that too, somehow.

Which brings me back to my point, what does your mod loading system do that's better than what FML does?

Quote from luacs1998

FML/Forge's server installer downloads additional libraries (scala, launchwrapper, a few more I can't remember off my head). You could possibly do that too, somehow.

Which brings me back to my point, what does your mod loading system do that's better than what FML does?

The point of Magic Mojo Mod Loader is to remove the need for coremods and increase inter-mod compatibility. Advanced mods have no hope of being compatible as long as modders are allowed to create their own modding APIs via direct access to Minecraft base classes. We need a system that can ensure compatibility that also keeps up with what modders are doing.

Quote from AvengedXtremis1994

Interesting another modloader for me to test. After I figure out how to install it with Eclipse, I can't seem to get it to work and I'm following it all correctly. A suggestion to an installer for modders so it ain't so much of a pain to install with Eclipse or any IDE, but I guess you have plans for that anyway.

I'm not planning to make an installer for the development environment. A good programmer should be able to figure out how to get a development environment working. =) If you want to share some of the details of what isn't working for you, I can try to help out.

Quote from AvengedXtremis1994

Thanks, but until I try again to try and install I can't really tell you since I actually deleted the workspace I was going to use for this modloader. But one thing I can tell you and it is that I created a new blank workspace to use maybe that could be it, I did everything correctly but once I got to the Gradle Tasks thing and did the stuff to get things to show nothing shows.

If you try to set up your workspace again and something does work, feel free to ask questions here. Let me know what you're trying to do, and details about what didn't work, including any error messages, and then I can try to help out.