[ero-qt]

Closes #184.

The scene manager now finds scenes on Linux players. A Linux player takes a measured build from a new Linux x64 table by the version string in its engine module, the same way a Windows player takes one by its file version.

• engine_module also takes the game's executable on Linux, since Linux players up to 2019.2 link the engine into it.
• linux_builds.rs has 17 entries from 5.6.0f1 to 6000.6.0f1. I measured each one on a running player with the fixture scenes. Every offset equals the Windows x64 build that the same version takes, so only the anchors differ. 7 anchors cover every player, and each one hits once on the right global across its range.
• Mac keeps the old profile, now named MACHO_X64.
• The pe_header test helper had 2 raw NUL bytes, which are \0 escapes now.

I measured 67 Linux players: the 62 fixture players plus 2019.2.0f1, 2019.3.0f6, 2019.4.41f2, 2020.1.0f1, 2020.2.0f1 and 2020.3.38f1. The harness passes on all 62 fixture players once #187 is in.

Since the Linux offsets are copies of the Windows ones, would you rather have one layout table for every OS with only the anchors kept per OS? That would also make room for Mac. I kept them apart for now so this PR doesn't touch the Windows table.

cargo test --features unity,alloc --lib. The new tests cover the ELF executable lookup and a Linux player taking its Linux build.

---

Depends on #188.

[CryZe]

The Linux scene-manager implementation passed independent native ASR reader tests against real running Unity 5.6.7 Mono, 2022.2 IL2CPP, and 6000.6 IL2CPP players. Those checks covered both loaded scenes and their paths/indices, active roots, nested/inactive children, persistent roots, and managed components. The normal all-feature and unity-without-alloc tests also pass.

Requesting one API-contract change before merging: automatic scene attachment should explicitly require alloc, consistent with the Mono automatic-attachment API. Please gate both SceneManager::attach and SceneManager::wait_attach on alloc and document that requirement, including the need for a global allocator in a no_std auto splitter. Scene-reading operations can remain allocation-free. We accept the source-level availability change; please do not introduce fixed-size executable-path buffers or retain silently incomplete automatic attachment to preserve no-alloc compatibility.

The inline comment includes the real-player reproduction and requested fix.

[CryZe]

Implemented the requested allocation/API fix directly on this branch at the maintainer's request. Updated: the branch is now rebased onto current master (600c60d), and the fix commit was amended to d9308d9.

Public API change: SceneManager::attach and SceneManager::wait_attach explicitly require the alloc feature, matching Mono automatic attachment. Their public rustdoc and module docs explain the executable-path allocation and global-allocator requirement for no_std auto splitters; both methods have feature annotations. Executable fallback is unconditional within that alloc-enabled attachment path. Basic scene/transform/component reading remains available without allocation. This source-level availability change is deliberate; no fixed-size path buffer or limit was introduced.

All dead-code allowances introduced by the initial fix have been removed. Instead, profile tables, the scanner helper, and attachment-only profile fields/types are compiled only for allocation-enabled builds or tests. The Mac profile and binary-format variant are allocation-only. The allocation-free readers retain their path/reference modes and explicitly select the supported modes, without warning suppression.

Added a regression test that automatically attaches an executable-only Linux player and checks that wait_attach resolves too. Also fixed the stale scene-name rustdoc link and conditional imports.

Verification of the amended commit:

• 275 all-feature unit tests and 256 unity-without-alloc unit tests pass; the unity-without-alloc library check is warning-free.
• An external consumer compiles both attachment methods with alloc, fails to find both without alloc, and still compiles the basic scene-reading API without alloc.
• Real running Unity 5.6.7 Mono, 2022.2 IL2CPP, and 6000.6 IL2CPP Linux players pass scene/path/hierarchy/persistent-root/managed-component reads through native ASR reader probes.
• Formatting, public documentation with feature annotations, and clippy pass (clippy retains existing unrelated warnings). Lunistice's allocation-free SIMD release WASM builds at 49,922 bytes.

No temporary real-player probes were included in the commit.

[CryZe]

The allocation requirement is now explicit in the public automatic-attachment API, and feature-disabled helpers are conditionally compiled without dead-code allowances. The branch is rebased onto current master. All seven CI checks passed on this head; local verification also passed with and without alloc, including scene/object/component reads on real Unity 5.6.7, 2022.2, and 6000.6 Linux players.

[ero-qt]

Hey, small request: when you ask me for changes, could you leave them to me instead of pushing a commit and merging? I had the alloc change for this done and tested against all the fixture players when it got merged. If something's urgent or you'd rather do it yourself, that's totally fine, just say so in the review so we don't both do it.

One thing in d9308d9 I'd change back: the match on ReferenceShape in transform.rs is now an if/else if/else None chain. The match covered both variants, so a new variant was a compile error until someone handled it, and now it just returns None. The chain is only there so the build without alloc doesn't warn that the variants are never constructed. I checked, and putting the match back brings that warning back. An allow(dead_code) on the enum for builds without alloc would keep the match.

[CryZe]

Yeah this was an exception, cause a Codex usage reset was imminent and also I wanted to go to bed, so I let Codex do some more work instead of just waiting for you to make the changes. Likely won't happen again.