I can't say when or if I'll return working to this mod unfortunately.
However, ModBridge is open-source, so if someone wants to fork it and
work on it, they're free to do so.
ModBridge lets you write Minecraft mods in C#. It has several advantages over developing native Java mods:
Forward Compatibility. C# mods are automatically forward compatible with new versions of Minecraft.
Security. C# mods are sandboxed so that they can't do nasty things on your computer. That means...
Mods can be automatically updated from a central server, and when
joining multiplayer servers, mods can be automatically downloaded and
Disabling / Enabling. Mods
can be disabled and enabled without restarting Minecraft. They are
isolated from the main client in such a way that they can safely be
deregistered and re-registered with the client (but only from the main
No ID Conflicts. Mods are assigned block IDs and item IDs from ModBridge and hence there are no ID conflicts when running mods.
No Decompiling. Mod developers don't need to decompile or reverse engineer the Minecraft client as they don't link against it.
The ModBridge website at http://modbridge.org
now contains all of the up-to-date information, including source code
and downloads. Below are some quick links to access various parts of the
Ey, when will it be released?? Really wanna try this :smile.gif:
Right now :smile.gif:
Link is in the first post, along with details on how to get started.
Edits and Notes:
The spam filter seems to keep triggering when I edit the main post, so in the meantime:
You want to click "Last Successful Artifacts" on the download page and place all of those files in your mods/ folder.
example recipe for those not looking at the code is two dirt blocks
placed horizontally and will produce an example block instead of stone;
it is no longer the configuration shown in the screenshot.
exiting Minecraft, ensure that the mod hosting executable closes along
with it! Sometimes Minecraft terminates and this process doesn't
execute, which causing it to go into a spin loop while it waits for
input from a Minecraft instance that no longer exists. This'll be fixed
in a later version.
ModBridge now has a website at http://modbridge.org/, including links to download, source code, a mod index and developer information.
I'm going to update this topic on Tuesday (or sooner) to change around references to point people to there.
Also, Minecraft 1.2.3 support is coming; I just need to provide the
build server with the new JARs and libraries (such as new versions of
ModLoader and MCP) and it should be good to go. I don't expect to have
to make changes to the source code, but we'll see how we go.
Alright I've cleaned everything up so it should all be consistent now.
Just to let everyone know, I'm currently awaiting updates from
ModLoaderMP and MCForge before I can make this run on 1.2.3. I'm also
investigating ways that I can reduce reliance on third-parties for
ModBridge is now 1.2.3 compatible. I've removed the dependency on
ModLoaderMP, instead opting to replace this with a functionally
When implementing MCForge, I'll apply patches that change it from using
ModLoaderMP to using our replacement instead so that I don't rely on
Flan's update process. Going forward this will allow our build server to
automatically build a functionally equivalent version of ModLoaderMP
for the current Minecraft version, regardless of where Flan is at with
updating his (our reimplementation is not made easy by the fact that
ModLoaderMP is not open-source).
Just after your personal opinion on this, is it worth trying to learn C#
after just managing to get my head around java? I'm a competant enough
modder but i'm not sure if i want to put the time in with many more
months of tutorials to try and find it out :/
This looks absolutely amazing and i'm a huge fan of the forward
compatibility, but i know it'll entail alot more learning on my part DX
C# is very similar to Java, in fact, it's basically Java with the naming
standards changed (so doSomething in Java is DoSomething in C#).
There's a lot of extra C# features such as events, delegates,
properties, etc. but you don't need to know how to use those in order to
use C#. At the very least, if you know Java, you will pick up any of
the extra bits very quickly.
I suggest looking at some C# code examples and you'll find out just how closely it resembles Java.
Alright, I've started putting the infrastructure in place for an
ABI-compatible version of ModLoader and ModLoaderMp that ModBridge will
use underlyingly, known as ModLoaderPlus. It's in the source code
Essentially this infrastructure will replace ModLoader and ModLoaderMp
in a backwards-compatible way, meaning that we don't need to wait for
Risugami or Flan to update their code. Better yet, this implementation
is open-source, so if there's any issues when a new version of Minecraft
comes out, people can work on patching it to work with the new version
In addition, I'm looking to see if there's a way to implement
ModLoaderPlus so that it remains backwards-compatible, but also allows
native mods to be enabled and disabled without restarting Minecraft,
similar to how C# mods are. However, it's impossible to offer
forwards-compatibility with native mods regardless of what is done, due
to the fact that ModLoaderPlus needs to be ABI-compatible with ModLoader
/ ModLoaderMp at all times (so I still recommend writing mods in C# if
you want features other than enabling / disabling).
If anyone wants to help with rewriting this infrastructure component, let me know via PM.
The build server now produces both versions for ModLoader and
ModLoaderPlus. Note that ModLoaderPlus is still experimental and not
fully implemented, so it's likely to break native mod functionality (and
probably ModBridge itself).
Follow the instructions at the download page for more information on how to use the new versions of ModBridge.
ModLoaderPlus is now able to successfully act as a replacement ModLoader
for ModBridge. Note that there are still a lot of ModLoader APIs that
aren't implemented in ModLoaderPlus, so it'll still likely break a lot
of native mods.
ModBridge can now dynamically load textures from C# resources into
Minecraft for use as block textures as demonstrated in the screenshot:
Note that at this time, ModBridge loads all texture requests into slot
168, so technically it can only store one texture in Minecraft at a
time. Modifying this to use available slots however is a very simple
task of implementing the getUniqueSpriteIndex functionality in
ModLoaderPlus (and this should be done hopefully next weekend).
After that is working, I'm going to look at modifying it so that there
is no limit on how many textures you want to load in, not even the limit
imposed by the default terrain.png's free slots. I know that some
native mods such as BuildCraft and IndustrialCraft already do this, but I
have to work out how they're using their own 256x256 images for block
Never-the-less, this is a pretty big step and brings ModBridge closer to being actually useful for developing mods!
NOTE: There is not a build yet that
incorporates this functionality; I'll likely wait until I have
getUniqueSpriteIndex working first.
Any way to make the plugin system work with normal java classes?
ModLoaderPlus can give you the benefit of enable / disable for native
mods, but that's something users install and has no effect on your mod
writing (you just write against ModLoader / ModLoaderMP).
Unfortunately there's no way to bring across any of the other features
to native mods since they link directly against Minecraft, which
naturally means they are not forward-compatible with new versions. Hence
if you want forward compatibility, you need to write your mod in C#.
If you are working with an existing code base, you can pretty much copy
all of your existing classes straight into C#; you will need to correct
slight issues but as I mentioned before, Java and C# are very similar.
The only other thing you will need to change is updating your API calls,
since inside the C# hosting environment there are no ModLoader APIs
(things are done differently).