A reversible first test for a Minecraft mod

A first run should answer one question: can this file load in a controlled setup? It should not be a change to the world, profile, or configuration that you use every day. This workflow is intentionally conservative and applies to the public Verity-CE release as well as to other Java mods.

Why a separate instance matters

Your regular Minecraft profile may contain worlds, other mods, resource packs, and configuration files that took time to set up. Adding an untested JAR to that profile risks corrupting world data, breaking other mods, or producing log output that mixes your existing setup with the new addition. A separate test instance isolates the experiment. If it fails, your regular profile is untouched. If it succeeds, you have documented evidence of what a working configuration looks like before you apply the same change elsewhere.

A separate instance also produces cleaner log output. When you start a new test instance with only the documented dependencies and the new mod, a loader error is almost certainly caused by one of those files. When you add the same mod to a profile with twenty other mods, a loader error could be caused by any of them.

Keep the working instance separate

Create a new Minecraft 1.21.1 instance rather than adding files to the instance that contains your regular worlds. Give the test instance a name that makes its purpose obvious, such as 1.21.1-verification. Confirm that its game directory is separate before you copy any files. If your launcher does not expose a separate directory, make a full backup of the existing directory first.

A backup is useful only when it can be identified later. Record the date, the Minecraft version, the loader version, and the original location. Do not overwrite the backup while a test is in progress.

Change one layer at a time

Start the clean test instance once before adding the loader or mod. That establishes that the base instance can launch. Then install the loader required by the current project documentation, launch again, and only then add the documented dependencies and release asset. A launch failure is easier to investigate when each change has a known boundary.

Avoid copying an entire mods folder from another profile. A folder can contain old libraries, duplicate versions, or unrelated mods that make the result impossible to interpret. For the same reason, avoid changing Java arguments, shaders, resource packs, and configuration files during the first test unless the project documentation specifically requires them.

Keep a small record

Write down the repository URL, release URL, exact asset name, date, Minecraft version, loader version, and every file you add. A plain text note is enough. This record lets you compare a later error with the setup that actually produced it, instead of relying on memory or search results.

For Verity-CE, begin from the public repository and the linked release page. The release documentation remains authoritative if it conflicts with this checklist.

What a successful launch confirms

A clean launch with no loader errors confirms that the JAR loaded without a dependency conflict or version mismatch. It does not confirm that every described feature is present, that the file matches a security standard, or that the configuration is complete. Treat a clean launch as one required step, not as the end of the verification process.

After launch, check the loader log even when the game starts normally. Warnings in a successful log can indicate a dependency that loaded in a degraded mode or a configuration value that was ignored. Compare those warnings against the release notes before dismissing them.

Define a stop condition

Stop the test when the loader reports a version or dependency problem. Do not add random replacement JARs until the error disappears. First compare the error with the current README and release notes. If the problem cannot be explained by those documents, remove the last change and return the test instance to its previous working state.

A controlled test does not certify that a file is safe or compatible with every system. It does make the next decision observable and reversible, which is a better basis for troubleshooting than modifying a production profile blindly.

Moving to a regular profile

If the test instance launches correctly and the loader log shows no unexpected warnings, you have a documented baseline. Before moving the mod to your regular profile, back up the regular profile and compare its Minecraft version and loader version with those in the test. A difference in either can cause the mod to fail even when the test succeeded.

Apply the same change sequence in the regular profile that you used in the test: add the loader first if it is not present, then the dependencies, then the mod JAR. Launch after each step and check the log before continuing.