Quick answer: Always keep a CSV/JSON source of truth and re-import after struct changes. Use Core Redirects for renamed fields so existing data maps over.

A weapon DataTable’s row struct gets a renamed field. After recompile, the DataTable shows empty or default values — the binary data no longer matches the struct layout.

Keep a Source of Truth

DataTables should be imported from a CSV or JSON file checked into source control. The .uasset is a build artifact. When the struct changes:

  1. Update the struct.
  2. Update the CSV/JSON column headers to match.
  3. Re-import the DataTable from the source file.

Core Redirects for Renames

; DefaultEngine.ini
[CoreRedirects]
+PropertyRedirects=(OldName="FWeaponRow.Dmg",NewName="FWeaponRow.Damage")

Maps old serialized property names to new. Existing data loads into the renamed field.

Avoid In-Editor Struct Edits Without Source

If you only edit the DataTable in-editor (no CSV), a struct change orphans the data. There’s no source to re-import from. Discipline: source file first, always.

Validate After Changes

Write an editor utility or commandlet that iterates all rows and logs any with default/zero values where data is expected — catches silent data loss.

Verifying

After struct edit + re-import, all rows have correct values. References to the DataTable resolve. No empty rows.

“The CSV is the truth; the .uasset is a cache. Re-import after every struct change.”

For designer-heavy projects, build a Google Sheets → CSV export pipeline — designers edit the sheet, CI re-imports DataTables on pull.