How to create a new version?

This tutorial assumes you have already read through the Creating mappings page and have exported mappings for a client/server version.

Mappings must be in Tiny v2 format for this step. The namespaces should also be official and named at the top of the header. For versions after (and including) RetroMCP-Java v1.0, mappings must also be merged in that both client and server mappings are present in one Tiny v2 format mappings file.

To do this, one must place their mappings in the same directory as a RetroMCP-Java instance, named as client.tiny and server.tiny respectively. If one does not have a server for their version, there is no need to create a server.tiny file.

After doing so, one can run the "Merge mappings" task in RetroMCP-Java which will merge the client.tiny (and server.tiny if it exists) into 1 Tiny v2 format mapping file. If only client.tiny exists, then the namespaces are re-arranged such that official -> named becomes named -> client. If server.tiny also exists, then it becomes named -> client/server where client/server are the obfuscated names present inside the Minecraft client and server JARs.

The output of this task will be present in the same directory as the RetroMCP-Java instance named as merged.tiny. The easiest way to create a version is to use a similar version (e.g. c0.0.23a -> c0.0.23a_01), replace the minecraft.jar and minecraft_server.jar before decampiling, place merged.tiny and rename it to mappings.tiny in the conf folder.

After that, patches must be regenerated (unless similar enough) which involves deleting client.patch and server.patch. Additionally, it is wise to regenerate access files client.access and server.access.

After doing so, decompiling will almost certainly fail. Most are due to exceptions not being present/correct for the current version, the decompiler may also fail to decompile a method (which can be found by searching for // $FF: Couldn't be decompiled) in the files, or wrongful access caused by ProGuard's obfuscation efforts which are valid in bytecode but not valid for source code.

All versions of Minecraft require at the very least Exceptor files. Access and patches may be required for certain versions.

Writing Exceptor files

Exceptor files are used to add exceptions such as java/io/IOException to methods which ProGuard removed the exception from. Exceptor files can be found in the conf folder and are named exceptions.exc. Exceptor files use the bytecode name to determine what method is to be altered. The basic format of Exceptor files are as follows:

# Package/Class/Method Signature Full/Path/To/Exception
com/mojang/comm/ConnectionList/<init> (ILcom/mojang/minecraft/server/MinecraftServer;)V java/io/IOException

The above example will add IOException to the constructor of ConnectionList which takes an int and a MinecraftServer instance as parameters.

Writing Access files

Access files are used to alter visibility of a class, method, or field. Again, ProGuard can narrow the visibility of these members at the bytecode level which is valid but not at the source code level. Access files are named client.access / server.access as a holdover from previous versions of RetroMCP-Java. When decompiling as Merged, both access files are applied to the codebase.

The basic format of Access files are as follows:

PUBLIC net/minecraft/client/Minecraft
PRIVATE net/minecraft/client/Minecraft fullscreen
PROTECTED net/minecraft/client/Minecraft startGame ()V

The above example access widens Minecraft.class to be public, makes the fullscreen field be private, and makes the startGame (which returns void) method be protected.

Creating patches

The final step of creating all the files needed to successfully decompile a version is to fix any and all errors that resulted in decompilation. This may include functions that Fernflower failed to decompile or it may include functions that Fernflower inadvertently changed the behavior of. For example, many Infdev versions require patches to fix blocks being broken from appearing in the middle of the screen instead of going straight to the hot bar.

Thankfully, this step is relatively easy to perform if all the issues are simple decompilation bugs. If Fernflower failed to decompile a method, you will need to use another decompiler like CFR, Procyon, or Krakatau. I personally use Recaf as it is a Swiss army knife when it comes to working with bytecode, multiple decompilers, or even when debugging and deobfuscating Java binaries.

After fixing all decompilation issues, you simply need to run the Create Patches task which will output a client.patch and a server.patch (if a server has been decompiled) of every edit that was applied. These can also be placed into the conf folder.

A standard conf folder may appear like such:

• client.access (optional)
• server.access (optional)
• exceptions.exc (required)
• mappings.tiny (required)
• client.patch (optional)
• server.patch (optional)

These files must then be compressed to a ZIP file and uploaded to the MCPHacker's website in the versionsV3 folder as of writing. The versionsV3/versions.json file must also be edited to include the new version.

An example of such an addition would be the following:

{
    "id": "c0.30-c-1900",
    "releaseTime": "2009-11-10T19:00:40+00:00",
    "resources": "https://mcphackers.org/versionsV3/c0.30.zip",
    "time": "2025-11-21T15:31:44+00:00",
    "type": "old_alpha",
    "url": "https://mcphackers.org/BetterJSONs/jsons/c0.30-c-1900.json"
},

releaseTime and time attributes can be found in the relevant JSON on the BetterJSONs repo. resources attribute is a link to the newly placed ZIP file of all the files you created which will be present at https://mcphackers.org/versionsV3 when published. The id attribute can also be found in the relevant JSON and is named using the Omniarchive ID style.

After doing this, create a pull request (PR) to the main website and await for confirmation.