Remapping Fork Patches

This repo is based on Paper 1.16.5. It can be used to remap patches of Paper forks.

This branch is specifically and only for fork remapping. This is not for Paper development or for general use. It requires special steps and special set up. Follow the instructions in this readme, don't ask for help if you haven't read this entire readme and followed all of these steps.

Remapping patches requires knowledge of how to fix issues when patches don't or can't apply correctly. Patches not applying correctly is not an issue with this repo or paperweight. You must fix them and continue the process manually yourself. This is identical to any other upstream update.

Setup

Paper's unmapped 1.16.5 patches are in patches/server-unmapped/0001. Place the patches you want to remap in 0002. Paperweight will only remap patches placed in the last directory - for example if there are directories 0001, 0002, and 0003, only the patches in 0003 will be remapped.

If you are remapping patches for a fork of a fork, place you other upstream patches in 0002, and your patches in 0003.

Pre-remapping

The patch remap task has no registered inputs, to make working with it repeated easier. That means if you run the task by itself, it will fail.

Before you start remapping patches, you must first set up the patch environment by running:

./gradlew applyPatches

You will only need to do this once to set up the environment before you start remapping.

Remapping

To start remapping patches, run the remapPatches task:

./gradlew remapPatches

This can take a very long time, hours even, as patch remapping is a very complex and CPU & disk intensive task. How long it takes depends entirely on how many patches there are to be remapped, and how powerful your computer is.

That said, while you may need to walk away during the process, the remapping process does require some amount of hands-on work to get it to complete. If you leave for a while and come back to a patch failure, you'll need to fix the issue and restart paperweight to pick up from where it left off, explained below.

Fixing patch application issues

It is pretty unlikely that patch remapping will succeed first try. Paper's patches have already been fixed to apply correctly on this branch, but either your patches or your upstream patches are likely to fail in one way or another due to minor differences in tooling, setup, etc. Again, it is your responsibility to handle patch application issues as they come up just like any other upstream update.

While the process of fixing issues with patch application is the same, how to resume and complete the process is different, as it hopefully goes without saying that patch remapping is a more complex process which requires extra work vs just a simple patch update.

Patch remap working directory setup

There are a variety of files and directories that paperweight uses during patch remap, but only one directory that you need to worry about. This is the directory where patches are applied, and code is remapped.

<project_root>/.gradle/caches/paperweight/patch-remap-input

That directory contains what would be the Paper-Server directory during the patch remapping process.

Apply patch fixes

If a patch fails to apply, go to the patch-remap-input directory to fix the issue, like you normally would. This repo contains the apatch.sh script in the scripts directory if you want to use it.

Once you have fixed the issues in patch application, and are ready to continue, run am --continue in the patch-remap-input directory:

git am --continue

Each patch is applied in its own am session, so this won't cause any of the other patches to incidentally apply. After the am command in the above patch-remap-input directory is completed, continue the remapping process with:

./gradlew remapPatches --continue-remap

Due to the --continue-remap flag paperweight will pick up where it left off. If the patch that failed is in a pre-remap upstream patch set, it will simply continue applying the other patches. If the patch is in the remap patch set, paperweight will record the patch, remap it, and re-apply it on the remap branch as it normally would, then continue applying the rest of the patches from there.

Completed patch remap

After the process is complete and all patches have been remapped, the new remapped patches (only including the remap patch set explained above) will be generated into patches/server-remapped.

Help, something went wrong

If something goes wrong, it's almost certainly a patch application issue discussed above. We will not support or help you work through these kinds of issues. Dealing with patch breakages is part of the process of maintaining a fork, so if you don't already know what to do, don't expect us to teach you how to do it.

If there is an error in paperweight that is causing some issue other than patch application, then we can look into figuring out what's wrong and fixing it. Please, please, read through everything here first and follow the instructions word for word. Do not try to simplify the process. Do not make up your own steps. If you do, again, we will absolutely not help you.