Files
GaCy-GO/docs/login-cyrene-investigation.md
T

155 lines
9.5 KiB
Markdown

## Current verification
The full shipped ASB manifest and block table use the same schema/build header
as their startup counterparts. The full block table references 9,270 installed
block files; the original startup table references 15. The staging tool
`tools/startup_manifest_overlay.py` validates selector hashes, format identity,
and referenced block presence, then stages the full tables under startup names.
Installation and exact restoration were verified in an isolated directory before
installing on the closed Client, with original selectors retained separately.
The user then supplied an in-game screenshot confirming the requested white
train, pink/purple nebula, petals and Click to Start UI. This proves the scene
is correct and the startup manifest boundary was the loading failure.
The user also reported a hang after Logout and re-entering. The shipped Lua
still registers its completion event against `Anim_LoginShow_LoadingWarpGO`,
while the UP asset map identifies `Anim_LoginShow_LoadingWarpGO_UP`. A second
staged rewrite changes only that event clip name, preserving the selected UP
prefab. It was installed after the user closed the Client. The user confirmed
that Logout and re-entering now succeeds. The requested scene and the reported
relogin regression are therefore verified in the actual Client.
The installed solution uses the shipped startup Lua rewrite and full startup
manifest projection; the experimental SDK overlay is disabled and is not
required for this result. Paths and content hashes are taken from the supplied
installation; no machine-specific installation path is embedded in the tools.
Content-addressed original files and selector backups remain available. A Client
update may replace these local startup selections; re-stage from that Client's
own validated files instead of reusing another build's manifests.
# Cyrene login train investigation
The requested reference is the login screen with a light-colored train, pink
petals and purple/pink nebula. An examination of the currently configured
Client's startup asset blocks found ordinary login scene objects and assets
such as `LoginShow`, `UI3D_LoginShow_StarCloud` and `Eff_Login_TrainFX`. This
does not establish that the Cyrene variant is available: the asset reader did
not completely decode the Client's asset blocks, and their manifest maps
hashed block names rather than directly exposing all scene paths.
The server's maintained Lua scripts are delivered through the game session;
this does not establish a way to change the scene before login. No Client file,
login scene, server configuration or player data was modified for this request.
The remaining work is to locate the variant and determine a supported startup
selection or safe installation path before attempting a change. The supplied
image is reference evidence only, not proof that this Client contains the scene.
A further user-provided screenshot shows the same scene on a 4.6.54 CN beta
build. This confirms the scene can be used on that beta version. The user has
indicated the asset exists; the remaining task is to find its asset and the
selection mechanism. Startup config and the installed Video directory did not
reveal a named Cyrene login video; those searches do not cover all assets.
## Variant located in the installed Client
A bounded offline scan of the installed Client's asset blocks found a block
with SHA-256 `385d8abe0abf06a8255aa26dbb9d41e480ff1600e7126ebf0a3606dee2030487`.
The asset map contains
`assets/asbres/ui/ui3d/loginshow/loginshow_up.prefab`, an animator named
`LoginShow_UP`, `LoginShow_Controller_UP`, and `MonoLoginTrainControl`.
The same block includes objects named `Eff_Login_TrainChangeFX_01`,
`Eff_Login_TrainFX_Flowers_02_Rate`, and
`Eff_Login_TrainFX_Flowers_03_Rate`. This establishes that the Client has a
separate flower/train-change login variant, as the user reported. It is a
strong candidate for the reference screenshot but has not yet been rendered
and visually verified. The map and extracted metadata are under ignored
`.runtime/login-05d-map` and `.runtime/login-block-05d*`; no game file was
modified. The native startup selection path still needs to be traced so the
variant can be activated before login.
## Startup Lua path and staged installation
The installed Client's baked `GameStartupUI3DPage` stores the exact path
`UI/UI3D/LoginShow/LoginShow.prefab`. The LuaV index maps that module to a
byte range in a content-addressed Lua block. The maintained
`tools/rewrite_baked_lua_string.py` builds a separate block and index changing
only that length-prefixed path to `UI/UI3D/LoginShow/LoginShow_UP.prefab`;
it validates every source block hash and updates module offsets and hashes.
The matching SRMI selector is reconstructed with the new index digest.
The rewrite was reversed on an isolated verification directory and recovered
the original Lua block, index and selector byte-for-byte. The staged files
were installed by `tools/install_baked_lua_stage.py`; it retains original
content-addressed files and saves the old selector outside the Client, writes
new files before atomically replacing the selector, and supports restoration.
The game was not terminated or restarted during installation. This proves file
integrity and reversibility, not that the scene can load during startup: the
UP prefab was found in the full asset manifest but not the startup manifest.
Visual Client verification remains required.
The first Client attempt looped at the startup warning. The original selector
was restored immediately, and the staged patch is not active. The latest
available Client log reports a timeout while fetching `M_LuaV.bytes`; the log
does not establish whether the modified selector caused the timeout. A further
read-only check found a second, newer LuaV index under the Client's Persistent
data. That active hotfix contains its own copy of `GameStartupUI3DPage`, so a
rewrite of only the StreamingAssets index is insufficient. A rewrite of the
hotfix copy has been staged separately but has not been installed. The update
and selection process must be understood before another Client attempt.
## Controlled SDK overlay test
The optional overlay initially caused the SDK to panic at startup: its
ServeMux subtree conflicted with the SDK's existing product-name wildcard
login routes. Overlay dispatch now wraps the existing mux instead; an
integration-style test exercises both the wildcard login and overlay paths.
The SDK then started with an isolated, ignored test configuration, and an
HTTP request returned the exact staged selector. All 14 blocks referenced by
the staged hotfix index were found and their sizes and MD5 hashes verified.
The Client downloaded the staged selector and modified block into its
Persistent Lua cache and was able to start. The user reported that the normal
train still appeared, including after restarting the Client. The staged
hotfix selector and downloaded block prove delivery to disk; they do not prove
that this Lua module controlled the startup scene. A plausible remaining cause
is that the login page is created from the shipped bootstrap bundle before the
hotfix is applied; a separate activation or animation in the UP prefab is
also possible. Neither explanation is established yet. The original Persistent
selector was backed up before this test; the original StreamingAssets selector
remained unchanged. No claim is made that the requested scene works.
The next controlled test installs the staged shipped Lua selector as well as
the already-delivered hotfix selector. An initial installation attempt was
cancelled because the Client was running. After the user confirmed it was
closed, the installer completed and retained the original shipped selector in
an ignored backup directory. Both selected modules now contain the UP prefab
path. Client startup and visual verification of this combined test are pending;
the original warning-loop attempt did not have the consistent SDK overlay.
## Confirmed startup failure boundary
The combined test produced a startup warning loop. Its Player.log explicitly
names `UI/UI3D/LoginShow/LoginShow_UP.prefab` and reports
`AsbManifestV5_Managed.GetBundleNameHashByBundleIndex name error: index=-1`.
This proves that the patched shipped startup module executes, but the manifest
available at that point cannot resolve the UP prefab's bundle. The UP prefab's
presence in the full asset map is insufficient for early startup loading.
The log is retained privately as `.runtime/cyrene-bootstrap-manifest-failure.log`.
Both original Lua selectors were restored, and the experimental SDK was stopped
and replaced by the original SDK so it cannot redeliver the failing patch.
The next change must make the evidenced UP bundle and dependencies resolvable
at startup, or defer selecting it until the full manifest is available. Repeating
the path-only rewrite is not a fix. The requested pink scene remains unverified.
An opt-in Lua overlay has been added to the SDK source so an updater can be
served a consistent staged selector, index and changed block while obtaining
other files from local hotfix and shipped caches. It is disabled by default.
`lua_overlay.enabled`, `stage_dir`, `hotfix_dir`, and `streaming_dir` belong in
local configuration (or the corresponding `GAC_LUA_OVERLAY_*` environment
variables). The SDK uses the shared public SDK base URL and a server-defined
route, restricts requests to Lua manifest/block filenames, and checks the
staged selector and index before startup. This is an unverified compatibility
approach: the Client's startup request path, cache behavior, and UP prefab
availability must still be confirmed. It has not been enabled or deployed.