A game update is out, and you want to bring your mods and your world up to date without losing the world. Changing Vintage Story server settings and adding mods are the two changes that can stop a world from loading, so this workflow runs them in a fixed order: copy the saves, change one thing, start the server and read the log, then change the next thing. Cascadia Merge does the file work and shows you each result as a card. You make every decision, and you keep the server stopped while files change. Plan to spend your time on reading the diffs and the log, not on typing paths, and write down the version of each mod before you change it, so that the list can serve as your record of update day.
Choose the server's data folder as the working folder of a new chat. The agent lists the folder with list_dir, so you can see Saves, Backups and Mods before anything is touched. On a Windows PC the default location is the VintagestoryData folder under your user's AppData\Roaming folder, unless you started the server with another data path.
With the server stopped, the agent copies the Saves folder into Backups with your own backup script. You read the exit code in the card, ask for a second list_dir of the Backups folder, and confirm that the new copy is really there before you go on.
Edit serverconfig.json or replace one mod, never both at once. The agent shows the diff for a setting change, and you accept or reject it in Ask first mode. A mod you replace by hand goes into the Mods folder as a .zip file, and only one such file changes per round.
Start the server with your own script, let the agent search the log for failed mods, and join from the game. If something breaks, you know which change caused it, and you can move that one file or restore that one line from the copy you made at the start.
Mods/foundMods/examplemod/modinfo.jsonreadversion Mods/3 matchesmod-list.txtsaved{
"ServerName": "Friends World",
"Port": 42420,
"MaxClients": 10,
"Password": null,
"AllowPvP": false,
"AdvertiseServer": false
}This is an excerpt of a serverconfig.json, not a complete file, with placeholder values only. The game port is 42420 (TCP), and a null password means that no password is set, so add one before you open the world to the internet. Edit the real file only while the server is stopped, and keep your own copy of it next to the Saves folder.
Start by looking before you change anything. The agent uses list_dir and glob to find the Mods folder inside the data folder, read_file to open the modinfo.json of each mod that sits in a folder, and write_file to save a plain list of names and versions in your working folder. If you need help with mods on a hosted server, first check that you can reach its data folder, because the agent can only work on files you can open. Print the list. You compare it with the mods your players have, since server and players need the same mods and versions, and you decide what to update. Nothing has changed yet, and you have a record of what was installed before the update, which helps if you must undo a step later.
Your world is one .vcdbs file in the Saves folder, so copy that folder before every game update, mod change and settings change. Stop the server first. The agent uses copy_file to place the world file in the Backups folder, and Shell runs your own backup script and reports the real exit code in the card. A copy that was never restored is only a guess, so restore it once into a spare folder, open it and check that the world is there. Only then do you move on to the part of the work that changes files, with a safe way back if the change goes wrong. You delete nothing, and a save is never removed without a copy. If the folder holds several worlds, copy the whole Saves folder so that none of them is missed.
Now change a single thing. To adjust Vintage Story server settings, the agent uses edit_file on serverconfig.json and shows the diff in Ask first mode; to update a mod, you place the new .zip in the Mods folder yourself, from the official mod database only. If the world will not load after installing a mod, the last change is the suspect, and you can undo it by moving that file out again. Stop here. You do not add a second mod before the first one has been tested, because two changes at once hide the cause. Plan only can write the steps down first without running them, which is useful when you want a checklist for update day that a second admin can read too.
Start the server with your own start script. Shell runs it and shows the real exit code, and then grep searches the server log for the words failed and error. Troubleshooting a dedicated server starts with that log, and the card lists every matching line so that you can read them in order. glob finds the log files if you are not sure which one is the newest. Next you join from the game and walk around the world. You accept the change as finished only after the log is clean and a second player has joined. If it is not clean, you go back one step, read the first error rather than the last, and restore the copy of the saves if the world itself has become damaged.
