To be honest, since 0x10c came out I haven't worked on this at all. I've been focusing my attention on the DCPU-16 Toolchain (https://github.com/D...m/DCPUToolchain) instead.
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
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...
Automatic Updates.
Mods can be automatically updated from a central server, and when
joining multiplayer servers, mods can be automatically downloaded and
enabled.
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
menu).
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.
Website
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
site:
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.
The
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.
When
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
updates.
ModBridge is now 1.2.3 compatible. I've removed the dependency on
ModLoaderMP, instead opting to replace this with a functionally
equivalent system.
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
repository now.
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
straight away.
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
textures first.
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).
ModBridge
ModBridge lets you write Minecraft mods in C#. It has several advantages over developing native Java mods:
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 site:
Due to the active development, these screenshots may represent out-of-date code; never-the-less they show ModBridge as a functioning system:
Questions? Thoughts? Suggestions? Leave them below.
Write forwards-compatible mods in C#
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:
Write forwards-compatible mods in C#
Like this post? Click the little
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.
Write forwards-compatible mods in C#
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 updates.
Write forwards-compatible mods in C#
This looks great.
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).
As far as I am aware, Jeb hasn't seen this.
Write forwards-compatible mods in C#
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.
Write forwards-compatible mods in C#
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 straight away.
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.
Write forwards-compatible mods in C#
Follow the instructions at the download page for more information on how to use the new versions of ModBridge.
Write forwards-compatible mods in C#
Write forwards-compatible mods in C#
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 textures first.
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.
Write forwards-compatible mods in C#
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).
Write forwards-compatible mods in C#