9.5 KiB
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.