v5.4.4

Fixed

The resource refused to start on servers that already had a garage column, with Data truncated for column 'garage' at row 2 in the console. The boot migration adds the columns msk_garage needs and then tightens garage to varchar(60) NOT NULL. On a fresh database the column is created correctly in the first step and the second one has nothing left to do. If the column already existed, from msk_garage v3 or from another garage script, the first step does nothing at all, because ADD COLUMN IF NOT EXISTS skips a column that is already there without touching its definition. The column keeps the shape it had, which usually means it allows NULL and is sometimes wider than 60 characters. The second step then has to map those existing rows onto the stricter definition, and a NULL cannot become NOT NULL.
Why it only happened on some servers. Whether that aborts the start or passes silently comes down to your sql_mode. With STRICT_TRANS_TABLES, the MariaDB default since 10.2.4, it is an error and the statement is rolled back. Without it the value is quietly turned into an empty string and you only get a warning in the console. An older database on a strict server is the combination that broke, and a fresh install never showed it at all.
What changed. msk_garage now cleans the column up while the old, looser definition is still in place: rows that are NULL or empty get your Config.DefaultGarage, values longer than 60 characters are shortened to fit, and only then is the column tightened. On a healthy database the cleanup matches no rows and costs nothing.

Changed

The vehicle type table moved from server/vehicles.lua to server/main.lua. This is a pure reorganisation. The mapping from the type column in owned_vehicles to the type CreateVehicleServerSetter expects is unchanged and behaves exactly as before.

Nothing to do by hand

There is no SQL for you to run. The cleanup is part of the boot migration and runs on every start, so a database that ends up with empty values later repairs itself on the next restart. No rebuild and no database change, replace the resource files and restart it.

Want to know which case you had?

Run this against your database before the update to see what the migration was choking on:

SELECT SUM(`garage` IS NULL) AS nulls,
       SUM(CHAR_LENGTH(`garage`) > 60) AS too_long
FROM owned_vehicles;

Rows counted in nulls came from a garage column that was created as nullable, rows in too_long from one that was wider than 60 characters. Both are handled now.

Changed files

fxmanifest.lua
server/main.lua
server/vehicles.lua

Changed files​

Changed files