How to update RedM scripts without losing your config

Most RedM servers run out-of-date scripts, and it is not laziness. Updating by hand means re-downloading from Tebex, diffing a config you edited months ago, running SQL you are not sure has already run, and restarting in the right order, for every script, every release. This guide gives you the manual routine that keeps your settings safe, and then the automatic route that makes the routine unnecessary.

The manual routine

1. Back up first. The database and the resource folder. If that is not automated, Server Controller (from $2.99/mo) does scheduled mysqldump and file backups with one-click restore, and it has a free tier.
2. Read the changelog. It tells you whether the config changed, whether there is SQL to run, and whether the folder was renamed. A rename means changing the ensure line too.
3. Download the new version from your Tebex purchases with the same Cfx.re account you bought with. For escrowed scripts, this is the only place a valid build comes from.
4. Copy everything except your config. Replace the code, the interface and the manifest. Keep your config.lua and any translation file to one side.
5. Merge the config. Open the new config beside yours and copy across every setting that is new. Settings the update removed can stay; the script will ignore them. This is the step people skip, and it is why "the update broke my server" usually means "the update added a setting my config does not have".
6. Run the SQL, once. If the update ships a migration, run it once against the right database. Running an older install file again can fail on tables that already exist.
7. Restart in order. The framework first, then shared libraries, then the script. A script restarted before its dependency comes up with nothing to talk to.

Seven steps, per script, per release. With fifteen scripts and monthly releases that is the better part of a day each month, which is why it does not happen.

The automatic route

Poggy Core (Free) removes the routine for every Poggy script, free and paid. When your server starts and every hour after that, it checks an update feed for each Poggy script whose published version is newer than the one installed. For each one it:

• installs the new files, merging config and translation files: settings the update adds are added, settings it removes are cleaned up, and every value you set is kept;
• backs up every original it replaced in poggy_core/update_backups/;
• creates or upgrades the database tables when the script starts, so there is no SQL to run;
• restarts the updated scripts. At server start that is immediate; while players are online, the restart waits until the server is empty.

Escrowed scripts update the same way. The build comes from the feed, and your per-server licence file is never written, compared or deleted. Nobody re-downloads from the portal.

The console shows what happened: one line per updated script, and poggycore update all lists what is available at any time. Automatic restarts need two lines in server.cfg, and poggy_core prints them if they are missing:

add_ace resource.poggy_core command.refresh allow
add_ace resource.poggy_core command.ensure allow

If you would rather approve each update

Turn both switches off in poggy_core/config.lua:

AutoUpdate   = false,
ApplyOnStart = false,

poggy_core then only reports. poggycore update all shows what is waiting and poggycore update all apply installs it, with the same merge and backups. A server that wants to read release notes before anything changes loses nothing by doing this.

Scripts from other authors

Everything that is not a Poggy script still needs the manual routine. Two habits make it bearable: keep a copy of every config you have edited outside the resources folder, so a diff is one command rather than a memory test, and update one script per restart, so a problem points at one thing. And back up before every one of them; the routine above starts with that step for a reason.

Why versions matter

A script only updates when its published version number is higher than the one you run. Same or older is never touched, which is what makes the automatic route safe: an update cannot go backwards, and a script you edited locally at the same version is left alone. It also means a script author who forgets to bump the version has shipped nothing, so the version line in fxmanifest.lua is the one thing to check when an update you expected has not arrived.