Vehicles · medium severity · found by reading the files
A .meta file is invalid XML — and sometimes that means the game discards it
A car does not spawn, has no handling, ignores its modkit, or is missing entirely — while the resource itself starts with no visible error.
What it means
N .meta file(s) are not valid XML. N of them are rejected by the game; the rest load fine today and are cosmetic.
- File
- vehicles.meta, carvariations.meta, carcols.meta, handling.meta, vehiclelayouts.meta
- Structure
- Any .meta file under a vehicle resource.
- Must hold
- Must be well-formed XML. rage::parManager discards THE WHOLE FILE on a parse error, not the bad line — so one stray character removes every vehicle the file declares.
How to fix it
- FIRST decide whether the game actually cares - Watchdog's game-tolerance script maps (defect class x file type) to the measured outcome. Most malformed metas load fine and must be left alone.
- For the ones the game rejects, the defect is always something that breaks the ELEMENT TREE: a mismatched or unclosed tag, or a doubled '<'.
- Repair with Watchdog's repair-meta script, which refuses anything it cannot fix provably.
- Back up the original, upload as <name>.new and swap with two moves - never overwrite in place.
- Verify by downloading the file back and comparing bytes; the upload reporting success is not evidence.
- Confirm in a CLIENT log, not the server console - parse failures are client-side only and never appear server-side.
When it is not this
It was validated against .NET's XmlReader over 3,040 real files with exact agreement, which proved only that the files are non-conforming XML. Nothing in the game asks that question. The consumer is rage::parManager, and it is far more lenient: measured over 408 MB of real client logs covering 225 known-broken files, 202 of 212 malformed metas were LOADED SUCCESSFULLY ('done loading ... in data file mounter') with no error at all, and only 10 were rejected. Reporting all of them would have sent an operator editing 167 working files on a live production server. Known tolerances: invalid '----' comments (46 loaded, 0 rejected); a mismatched closing tag inside carcols.meta (25 loaded, 0 rejected); debris after the root element (27 loaded, 0 rejected); stray bytes before <?xml in vehicles.meta (12 loaded, 0 rejected); a bare '&' (2 loaded, 0 rejected). Known rejections: a mismatched closing tag in carvariations.meta or handling.meta, an unclosed or malformed tag in handling.meta, and sometimes stray bytes before <?xml in handling.meta (2 of 6). The pattern: CARCOLS_FILE is extremely permissive, HANDLING_FILE is the strictest, and trailing junk after the root is universally ignored because the parser stops at the end of the root element. The checker itself is still correct as an XML checker and must not be loosened - do NOT swap in a lenient parser, because then real rejections go undetected too. Gate on impact, not on conformance. ONE DELIBERATE DIVERGENCE from XML: an undeclared entity such as ' ' is accepted; zero of 3,040 real metas contain one, so the check buys nothing measurable.