Minecraft Forums

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:

• Home
• Blog
• Features
• License (it's MIT!)
• >> Download <<
• Develop
• Mod Index

Screenshots

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.

mabey jeb should hire you on to make the gamemode api. :tongue.gif:

Quote from addemod

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.

Approved!

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.

Has somone alerted Jeb to your work?

This looks great.

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).

Quote from Pikdome

Has somone alerted Jeb to your work?

This looks great.

As far as I am aware, Jeb hasn't seen this.

Quote from vegnagun1

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.

YOU ARE SO AWESOME!

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.

maybe you should get in contact with mojang seeing as you could help them with the modding api since you could add alot to it.

Any way to make the plugin system work with normal java classes?

Quote from plerer

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).