Changelog

1.2.0

Drive layout and suspension geometry: fDriveBiasFront (0 = rear-wheel drive, 1 = front-wheel drive, in between = all-wheel drive), fSuspensionUpperLimit, fSuspensionLowerLimit, fRollCentreHeightFront, fRollCentreHeightRear, fCamberStiffnesss (40 fields in total). They need Apply & refresh.
handling.meta export / import: Export shows the editor values as handling.meta lines with a Copy button. Import takes a whole handling.meta, one vehicle's <Item> or single lines; values out of range are skipped and listed, lines the editor does not have are counted and ignored. Imported values are only stored on Save (the server validates them again).
Field search at the top of the category list (Ctrl+F): names, field ids, descriptions and categories. Esc in the search box clears it.
Test drive measurements: while the panel is hidden for a test drive, a strip shows the speed, top speed, 0-100 km/h time and 100-0 km/h braking distance (last and best). The best values stay in the footer when you return, so profiles can be compared. Config.TestDrive (telemetry, unit = 'kmh' | 'mph').

New editor look in the NullSect theme: black panel, warm text, orange accent, NullSect mark in the header. Serif titles, numbers and labels in a monospace face, rounded buttons with the orange Save button as the main action. Fonts are bundled in nui/fonts/ (Geist, Instrument Serif, JetBrains Mono, SIL OFL); no internet access needed.
Field descriptions and docs now give the right units: the handling natives use handling.meta units (steering lock in degrees, top speed in km/h, 0.5 = balanced bias). Earlier texts said radians, m/s and "1.0 = balanced".
Turkish title is "Araç Handling" (was all caps).

Default profiles captured before a field was enabled (new version or Config.AllowedFields) had no original value for it: the editor showed - and the field could not be reset. Such a Default is now completed from the vehicle the next time an admin opens the editor on that model; stored values are kept.

Keeping your old config.lua? Add the six new field ids to Config.AllowedFields (see INSTALLATION.md). Config.TestDrive is optional. No database change.

Release defaults: Config.Locale is 'en' and Config.Debug is false (1.1.3 shipped with Turkish and debug output on; the documentation already listed these defaults).

An editor action that was still waiting for the server when the editor closed (e.g. the admin left the vehicle) was logged as an internal error; it now ends quietly.
Installation docs: neutral wording for getting the resource on Tebex.

Admin check: on servers where the ACE check answers 1 / 0 instead of true / false, every player was treated as an admin (0 counts as yes in Lua) and could open the handling editor and manage profiles. The ACE permission (Config.Permissions.ace) and the group.* checks now accept only true or 1.

Offline test for the 1 / 0 ACE answer.
ARCHITECTURE.md: profiles, applying handling (state bag + GlobalState), request contract, data ownership.
Offline tests (lua5.4 tests/run_tests.lua): field validation, sanitising, router gates, editor and profile lifecycle (version conflict, history / restore, activate, delete rules), public actions. Not shipped.

/vhcompare debug command (admin, Config.Debug): compares the handling and effective values of two vehicles of the same model.

Activating a profile now always applies it to every spawned vehicle of that model (including the vehicle being edited). The "also apply to vehicles that are already spawned" checkbox and Config.AutoApply.applyExistingOnActivate were removed (the option can be deleted from config.lua).

Newly spawned vehicles often did not fully use the active profile (e.g. a 1-gear profile spawned with 6 gears; other spawn-cached values differed from Apply & refresh): it was written after the vehicle had been created and its mods applied. The active profile is now written into the model's global handling on every client (GlobalState), so vehicles are created with it. New Config.HandlingNames for add-ons whose handlingId differs from the model name.
Vehicles spawned without a mod kit (e.g. /car) drove differently from the same vehicle after Apply & refresh. The mod kit is now set before the profile is applied, like Apply & refresh does.
After activating a profile and closing the editor, the vehicle sometimes reverted to Default or to the previously applied profile instead of the new active one.
The editor previewed the active profile on vehicles that were explicitly stock; it now shows Default as the applied profile for them.
The driver fallback (claim) was skipped for vehicles that reused the network id of an earlier vehicle, and was never retried after a timeout / rate limit, so such vehicles could spawn with Default handling.
Profile / default value fetches could be rate limited when several vehicles streamed in at once, leaving those vehicles unsynced.

Active profile was not applied to newly spawned vehicles with some spawn methods (server-created vehicles / entities whose type was not replicated yet when entityCreated fired). The server now retries briefly, and the driver's client asks once for the active profile as a fallback.
Profile is applied a second time shortly after spawn, so garages that set vehicle properties right after spawning cannot undo it.

Activating a profile without "apply to existing vehicles" now marks already spawned, untouched vehicles of that model as stock, so only new spawns get the profile.

Help page in the editor: short tuning tips (acceleration, top speed, grip, brakes, drift, durability). Each tip links to the fields it mentions.

Activating a profile failed with "Database error" on oxmysql (TINYINT(1) values are returned as booleans).