What is the plan to deal with forge mod compatibility?

[kriNon]

I'm fully aware that vanilla support is the priority at the moment, however, I think it would be wise to think about how Forge mod compatibility will work in the future.

Currently, there is support for joining forge servers, and some limited proof-of-concept compatibility for modded blocks (ThermalExpansion:Rockwool).

Mod authors creating client versions of their mods in rust for stevenarella seems very unlikely. Ideally, it would be nice if we could support regular java mods. What would be the best way of making this happen?

[mpfaff]

Supporting Java mods is an absurd goal, even if you exclude those using mixins which I see no way of supporting.

[kriNon]

I think that deciding on an approach to supporting mods is very important. Full support for java mods would be a huge undertaking.

We could however offer partial support. Simple stuff like interpreting simple blocks and items added to the block/item registries can go a long way.

Alternatively a Java based implementation of forge that is designed to communicate with the stevenarella client. I'm not sure how something like this would work, but I imagine that it would also be quite involved.

I'm not sure if there are any other alternative ways java mod support could be achieved but I'd be interested to hear if anyone has any ideas.

[mpfaff]

When I wrote "even if you exclude those using mixins", I was considering a Java implementation of the Forge API that communicates with stevenarella. I've never done work with JNI before but I've heard performance can be awful. I'd like to hear from someone with more experience whether they think that would be an issue for this project and if there are better ways of implementing a compatibility layer.

With that being said, I do worry that many forge mods might access the global Minecraft instance which would have to be faked for compatibility.

[iceiix]

It is a very interesting question of how it could be possible to add Forge mod compatibility, or if this is even feasible. I think it is, but won't be easy.

First problem is the JVM. How to load and execute Java bytecode to begin with? JNI into a native JVM may be an option, but that wouldn't work with #446 🕸️ Web support (which is another can of worms, an unsolved problem). And honestly, avoiding running the full-blown JVM is one reason I started working on this project in the first place. But there may be other solutions. Highly experimental, but I find these projects enticing, maybe they can help here:

• https://github.com/plasma-umass/doppio
• https://github.com/wasmerio/wasmer-java

But even if the bytecode compatibility problem can be solved, next challenge is how to support a compatible API. The big problem of course is Forge mods do not really use an "API" for much of what they need to do, rather they hook into the "native" internal game code. It is possible to fake this, as demonstrated by this very interesting compatibility layer mod, Intermediary:

• https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-mods/wip-mods/2360685-intermediary-run-minecraft-1-2-5-mods-in-1-7-10

but is fraught with peril as you might expect. A reduced level of compatibility could be imagined where native classes are unavailable, only the real API calls as provided by https://github.com/MinecraftForge/MinecraftForge. This would require mods to be ported to run under this client, not running unmodified, like how Forge mods had to be "ported" to run on MCPC Bukkit servers in 1.2.5:

• https://web.archive.org/web/20150217055048/http://mcportcentral.co.za/wiki/index.php?title=Ports_for_1.2.5

which is not ideal as hypothetical 100% compatibility, but would be more practical, and at least some compatibility would give the porters a head start. This strategy would also benefit from OSS mods.

At the opposite end of the spectrum, is a strategy where there is no Java compatibility. This is where we're at right now. The client-side portion of the Forge mods would have to be reimplemented. ThermalExpansion:Rockwool is a trivial proof-of-concept of this approach, there is much to be done to make this idea workable. What would a plugin API/framework actually look like? The code as written assumes mostly static definitions, and is not very extensible at runtime. Prior work on more abstracted modding APIs may be helpful for inspiration here, such as the NOVA (Neatly Organized Voxel API):

• https://nova-team.github.io

which aims to "create a total abstraction layer for creating addons to Voxel games such as Minecraft and Terasology"

This is all very far off, but one point in favor of Stevenarella is multi-version support, mitigating the version update treadmill moving target. I am personally most interested in 1.7.10 mods, especially those in FTB:IE:

• https://feed-the-beast.com/modpack/23_ftb_infinity_evolved_1_7

which is a "stable" target to aim for, not actively changing drastically. Although massive, this set of mods is a known finite quantity.

Another useful technique here is graceful degradation / progressive enhancement:

• https://en.wikipedia.org/wiki/Progressive_enhancement

That is, you can connect to modded servers today (thanks to Forge handshake support), but unrecognized modded blocks show up as magenta/black checkerboard placeholders. Modded block support can be implemented incrementally, instead of all at once, and the missing functionality degrades gracefully (or at least, as gracefully as it can).