What the public Prism Mod config shows
Public PrismConfig source provides a concrete view of part of Prism Mod's configuration design. It defines a server-side configuration class with two boolean options: Disable Developer items and Disable Lore. Both are marked as requiring a reload. That means the code expects a mod reload before changes are fully applied.
These settings also show how the project groups some of its content. Developer items and lore are categories that can be disabled. A configuration guide should not invent additional settings that are not documented, but these visible options are enough to establish a useful testing pattern: change one value, reload, confirm the result in a disposable profile, and record the previous state.
Understand server-side scope
The configuration class identifies itself as server-side. That means the setting is intended to be authoritative for the game session rather than merely a private visual preference. This distinction matters in multiplayer, where the host or server normally controls shared gameplay configuration.
Because Prism Mod is a legacy project, do not assume a modern tModLoader interface looks exactly like the original environment. The source tells you the intended setting scope and labels, while the loader version you actually run determines where the configuration appears and how it is stored.
Why reload-required settings need discipline
A reload-required setting usually exists because content availability or registration cannot be safely changed in the middle of a running session. If Prism Mod disables a category of items or lore during loading, it needs a fresh initialization pass with the new value. That is why the visible properties carry reload requirements.
Leave the world, apply the change through the supported configuration interface, perform the requested reload, and reopen the disposable test world. Do not change several reload-required values simultaneously when diagnosing behavior. One change per cycle gives you a clear cause-and-effect relationship.
Keep a configuration record
Create a small text note that records the Prism Mod build or commit, tModLoader version, and important settings. Note whether developer items and lore are enabled or disabled. If you later compare two environments, this prevents the common situation where the code looks identical but the hidden configuration state differs.
Configuration records are especially helpful with older projects because you may test rebuilt source or different branches. Store the note with the corresponding package or profile so every working setup is self-describing.
Be careful with config files between builds
If your loader stores Prism Mod settings in a file, back it up before experimenting. Do not assume a file generated by one loader generation will always be accepted by another. Property names, serialization formats, defaults, and validation rules can change.
When moving between significantly different environments, it is often safer to let the new build generate a fresh config and then reapply known settings through the supported interface. If a stale config appears to cause problems, move it aside rather than deleting your only copy.
Configuration in multiplayer tests
For multiplayer testing, keep host and client Prism Mod states aligned. A server-side configuration should be tested with the same mod build across participants unless the exact loader setup documents otherwise. A different client build can turn a configuration symptom into a confusing network or content-sync problem.
Use a private test server or local host before changing a persistent multiplayer world. Verify that clients join, settings apply consistently, and reload-required changes remain stable after the necessary restart or reload.
When a setting seems not to work
First confirm that you performed the required reload. Then confirm you are editing the active profile's Prism Mod configuration rather than an old folder or second installation. Check the loader log for parsing errors and make sure the host controls server-side settings when testing multiplayer.
If behavior still disagrees with the UI, reset to defaults in a disposable profile and test the setting by itself. If you are working from source, confirm that the binary you launched actually corresponds to the branch containing the PrismConfig code you read.
Configuration summary
Prism Mod's visible configuration is manageable when changed deliberately. The public code identifies server-side toggles for developer items and lore, and both require reloads. Back up config files, record values with each profile, and treat different branches or loader environments as separate test states.
Those habits turn configuration from hidden state into a diagnostic tool. The same discipline remains useful if you later modernize the code and add new settings of your own.
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.