[Draft] Generate platform-specific member layouts in UVTD

[tc-imba]

Caution

This draft was implemented and reviewed with substantial AI assistance using OpenAI Codex and the superpowers workflow. The commits have passed automated tests and multiple independent AI review gates, but they should still be treated as untrusted until a maintainer or the author completes a human hunk-by-hunk audit.

Why this PR exists

This is the first focused rewrite extracted from the much larger Linux experiment in #1342. It responds directly to the maintainer feedback here:

#1342 (comment)

The key issue was that UEPseudo member-layout files are UVTD-generated output, so Linux support must not hand-edit generic generated wrappers or mutate offsets at runtime. This PR moves the platform-specific source of truth into UVTD and makes UVTD generate complete platform setter files plus compile-time selection.

This PR changes generation only. It does not add Linux runtime support to RE-UE4SS, does not change xmake, and contains no Palworld runtime/product code.

Provenance

• Upstream base: b50986bd114f4cb187d9309846b003419c38b73b
• Head: a9e1c50138a87a17021e9b841c6b9db7b4d30f78
• Configuration commit: d606d8ddebe6852d35f44b5b5ffa7c8de18b79ee
• Generator commit: a9e1c50138a87a17021e9b841c6b9db7b4d30f78
• Coordinated generated-output validation PR: https://github.com/Re-UE4SS/UEPseudo/pull/176

What changed

1. Platform member-layout configuration

UVTD now loads platform_member_layouts.json from both the development config and the bundled default config. Each entry identifies:

• the platform output directory;
• the compile-time platform macro;
• the Unreal version;
• the affected classes and their complete member-offset maps.

The initial data set contains complete Linux UE 5.1 layouts for FProperty and UEnum. The model is intentionally platform/version/class based rather than embedding product-specific runtime adjustments.

Configuration loading validates identifiers, path tokens, version/class/member names, offsets, duplicate platform/version entries, and duplicate (version, class, ifdef_macro) selections. Invalid reloads fail closed and retain the previously valid in-memory configuration.

2. Deterministic generated setter publication

PlatformMemberLayoutGenerator plans all output paths before writing, rejects both exact and ASCII case-folded collisions, and emits complete setter fragments under:

generated_include/FunctionBodies/Platform/<Platform>/

Publication is transactional:

1. Generate into an owned sibling staging directory.
2. Move existing generated platform output to an owned backup.
3. Publish the staged directory.
4. Restore the backup if publication fails.
5. Report cleanup failures with the owned paths involved.

Platform generation and preflight happen before the existing generic/virtual cleanup, so invalid platform configuration cannot erase the prior output set.

3. Generated compile-time selection

UnrealVirtualGenerator now emits deterministic platform branches at member-layout include sites, followed by the existing generic include as the fallback. It supports zero, one, or multiple platform definitions and preserves the existing suffix-specific generation behavior.

For the current data, UVTD generates Linux selection only for UE 5.1 FProperty and UEnum. Generic generated wrappers remain platform-neutral.

4. Regression coverage

The focused tests cover configuration parsing and transactional reload, invalid tokens and identifiers, duplicate selection macros, deterministic output, exact/case-folded collisions, preservation of prior output on rejection, staging/backup cleanup behavior, and generic/suffix-specific include fallbacks. Root-level CTest discovery is also enabled for these targets.

Generated-output evidence

A fresh generator run from a9e1c50138a87a17021e9b841c6b9db7b4d30f78 produced files byte-identical to the coordinated UEPseudo PR:

• FProperty: 62bc54dccf0c602b4e53ea298fe8ab9e527268d3cf1d4f91a3bba1e05d7d7f5a
• UEnum: 3040d454894336fd3f6477fee7ca4c572a55e6053fe645a9ea0bdc974fbbd1f0

Verification performed

Windows-target build using clang-cl/xwin:

export XWIN_DIR=/home/liu/.xwin
cmake --build /tmp/re-ue4ss-uvtd-xwin-baseline \
  --target UnrealVTableDumper \
           PlatformMemberLayoutConfigTests \
           PlatformMemberLayoutGeneratorTests

Result: exit 0; all requested targets were up to date after their successful build.

Focused Windows executables under Wine:

WINEPREFIX=$HOME/.cache/ue4ss-wine-config-tests \
ctest --test-dir /tmp/re-ue4ss-uvtd-xwin-baseline \
  -R 'PlatformMemberLayout(Config|Generator)Tests' \
  --output-on-failure

Result: 2/2 tests passed.

Generated-output integration:

WINEPREFIX=$HOME/.cache/ue4ss-wine-config-tests \
wine /tmp/re-ue4ss-uvtd-xwin-baseline/Game__Dev__Win64/bin/PlatformMemberLayoutGeneratorTests.exe \
  '<fresh non-existing artifact path>'

Result: generator tests passed; the two generated setter hashes matched the values above and were byte-identical to PR B.

With PR B temporarily checked out in deps/first/Unreal:

cmake --build /tmp/re-ue4ss-uvtd-xwin-baseline --target Unreal

Result: exit 0; Game__Dev__Win64/lib/Unreal.lib linked successfully. The submodule was then restored to the upstream-pinned SHA.

Additional gates passed: git diff --check, exact path allowlist, committed/staged/unstaged/untracked no-xmake guard, generated hash comparison, and clean worktree checks.

Suggested review and merge plan

Because this is still a substantial generator change, I suggest treating the architecture decision separately from the rest of the Linux port:

1. Review the config model, publication semantics, and generated include strategy in this PR first.
2. If merging directly to main is premature, merge or retarget this draft to a temporary integration branch such as linux-platform-layouts.
3. Review the coordinated UEPseudo PR as the concrete generated-output proof for this exact generator commit.
4. Once the architecture is accepted, merge PR A first, then PR B in UEPseudo.
5. Keep every later Linux subsystem in a separate PR; do not merge the original 149-file experiment wholesale.

The old reference experiment still contains product-specific and rough exploratory code. I intend to clean/rewrite that later, including removing Palworld-specific content where it does not belong. None of that content is being proposed in this PR.

Known non-blocking review notes

• If generation and owned-staging cleanup both fail, the current diagnostic reports the cleanup exception rather than preserving both exception causes.
• Collision preservation and successful replacement are tested, but publication, rollback, and backup-cleanup failures are not yet covered through explicit filesystem fault injection.

These were classified as non-blocking in the final review, but are useful follow-up hardening work if maintainers accept the architecture.

Architecture question for maintainers

Is a config-driven UVTD source of truth that emits complete platform-specific setter files, with compile-time platform selection and the existing generic setters as fallback, an acceptable architecture for this project?

Review provenance

• AI assistance is disclosed.
• Every changed hunk has been manually reviewed by the author.
• Generated files match the linked generator commit.
• No xmake files changed.
• No unrelated formatting changes are present.
• Focused tests pass on the changed platform.
• Windows regression CI passes when shared code is touched.

This PR will remain draft until the human audit is complete and maintainers confirm that the platform-specific generated-layout architecture matches project expectations.