Back up before every change

Any Prism Mod update experiment should begin with a recoverable copy of the current state. Back up players, worlds, the active mod package, configuration files, and loader details needed to recreate the environment. A world backup taken after something already went wrong is not equivalent to the clean copy from before the change.

Name backups with a date and Prism Mod state. A folder called prism-mod-before-test-branch is more useful than backup-final-new2. If you work with source, include the commit hash. If you use a binary, include the original filename and source URL.

Define what update means for a legacy project

For an actively maintained project, update often means installing the newest release. Prism Mod is different because the public repository represents older development. An update may mean switching branches, rebuilding source for another tModLoader generation, applying your own compatibility patch, or changing the loader while keeping the mod source constant.

Do not call an unrelated Prism project an update. Prism Menu and Prism Launcher have independent release histories for different games. They cannot update the Terraria Prism Mod. Relevant update paths are connected to boilermaker021/prismmod or a derivative you intentionally choose to test.

Clone the working profile

If you already have a working Prism Mod environment, do not update it in place first. Duplicate the profile and make the change in the copy. The original becomes your known-good baseline while the duplicate is experimental.

Duplicate the disposable world too. That gives you an A/B comparison without pointing an experiment at the only copy of a save. This is especially helpful when testing source modernization because subtle changes may not crash immediately but can still alter content behavior.

Switch branches deliberately

When moving to or from the visible test-branch, record the commit before switching. Git users can create a local branch or tag for the working state. ZIP users can keep the old archive untouched. Inspect differences before building the new state.

A branch can contain experimental work, so its name is not proof of improvement. Build or install it into the duplicate profile, run the same minimal mod list, and compare results with the baseline.

Treat loader upgrades as separate migrations

Changing tModLoader is a major variable. If you update the loader and Prism Mod simultaneously, a failure does not tell you which change caused it. Change one layer at a time. Preserve the old environment until the new one passes clean launches, configuration tests, world save and reopen tests, and log review.

A loader upgrade can also change configuration storage or project metadata rules. Do not retire the old profile just because a title screen opens. Stability means the mod loads, the test world behaves, and the resulting data can be reopened without relevant recurring errors.

Use a real rollback plan

Rollback means more than reinstalling an older mod file. Restore the whole known-good set: mod package or source-built output, loader version, configuration, and the world or player backup taken before the change. If an experimental world was saved, restore its pre-change copy.

Keep a short rollback checklist inside the profile folder. Disable the experimental build, restore baseline files, restore config, restore the world copy, launch with the minimal profile, and verify the log. A checklist prevents forgotten duplicate packages or stale settings.

Archive successful setups

Once you find a stable Prism Mod environment, archive it. Save the package or source commit, loader details, configuration, and a note explaining how it was built or installed. The goal is to preserve your own reproducible environment, not to create an unofficial public binary mirror.

For source-based setups, version control is the best archive. A patch or branch shows exactly what you changed relative to upstream and makes future debugging much easier than an undocumented folder of edited files.

Backup and update summary

Prism Mod updates should be reversible experiments. Back up first, clone the working profile, change one layer at a time, test copied saves, preserve logs, and only retire the old environment after the replacement proves stable.

Newer is not automatically safer when project and loader histories are complex. A known-good historical setup can be more useful than an unverified modern combination. Preserve what works, document what changes, and let test results decide whether a migration succeeded.

Practical Prism Mod checklist

Before you finish, record the exact Prism Mod source you used, the branch or commit when known, the Terraria and tModLoader versions in the test profile, the configuration state, and the location of your backup. Keep the smallest possible mod set while diagnosing a problem, save the first relevant log error, and avoid changing more than one major variable at a time. If you downloaded source code, keep it separate from loadable packages and do not assume a repository ZIP is a compiled mod. If you opened a test world, make sure your valuable world remained untouched. Keep the main boilermaker021/prismmod repository distinct from other projects that happen to use Prism in their name. This short record makes every later test easier to repeat, compare, and reverse.

A reliable Prism Mod setup is one you can explain from source to launch. You should know where the files came from, why you expect them to match the loader, which settings were active, what changed since the last working run, and which backup returns you to safety. That documentation is especially valuable for a legacy overhaul project because current compatibility cannot be assumed from a modern loader name alone. When evidence is missing, label the result unverified rather than filling the gap with a guess. When a test succeeds, preserve the profile before making the next change. This habit keeps experimentation fast because you always have a clean place to return to and a precise record of what made the working state different from the failed one.

A final Prism Mod verification pass should compare the active files with the source, confirm the loader profile is the one you intended to test, preserve the current log, and keep the backup untouched. If a result depends on a branch, configuration value, or local source edit, record that dependency beside the profile. This makes the outcome reproducible and prevents a later successful or failed launch from being attributed to the wrong change. For a legacy project, precise notes are part of compatibility work because they replace assumptions with a known test state.