camfly moves the free camera by a distance and a turn in equal steps over a number of ticks, where camgo jumps: a
run can fly the view across an area without a route Link gets stuck on. A flight of 1.3 km round Hyrule Field showed
what it is not good for: the video memory in use stayed flat, the game loads and lets go of textures by where Link
is, not by where the camera looks.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
This takes back the three commits that added it (cd2f9f1, e60677e, a01910d): its runtime layer and Steam binding, the Co-op tab and what it drew over the game, the launcher's copy of Steam's library file, its settings, tests and docs. The tree is as it was before them, with the bug capture that came after kept: its note on screen no longer makes room for co-op's lines, and dbg_area, which the co-op had brought and the capture uses, stays.
The four settings of that co-op join the retired names, so a settings file that still has them logs no unknown key. A steam_api64.dll that the launcher put beside the game is left where it is: nothing loads it any more.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
F8 now always writes a folder under logs/captures: the area, Link's position and rotation, the camera of the frame on screen and the game's own, the presented frame as a PNG, frame times around the press, the machine, the settings that differ from the defaults, the end of the log, the save, and the game's flags and texts. A note on screen names the capture. The flight recorder's F8 dump goes into the capture's folder.
NX2NAVI_CAPTURE_REPLAY starts a run on a capture's settings, teleports to its area, walks Link to where he stood and puts the free camera where the camera was; tools/capture_run.py prepares the profile from the capture's save, runs it and compares the two captures. docs/bug-capture.md has the files and the steps.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Up to four players, each in their own game and save, meet in a room. Rooms are Steam lobbies and the games talk through Steam's networking, so nobody forwards a port and nobody runs a server. The game signs in to Steam as its test app (480), so Steam shows the player as playing Spacewar. Off by default; the menu has a Co-op tab with Create a room, Join a room by its ID, Invite a friend, the players, chat and Leave, in English, Russian, Brazilian Portuguese and Simplified Chinese.
runtime/steam.c loads steam_api64.dll from beside the exe at run time and declares the C functions it calls itself; nothing of the Steamworks SDK is in the repository, and a player copies the file from a Steam game they have. runtime/coop.c is the room: the lobby's owner is the host, lets games of the same protocol and game build in and lists them, and every game takes positions, chat and progress only from the players on that list. runtime/coop_game.c reads Link from the Player actor and shares progress, items, songs and quest items through the game's own flag routines, each value only ever raised; small keys, rupees, ammunition and hearts stay each player's own, and the save is copied to coop-backup before anything of a room reaches it. The other players show as a name with a distance where their Link stands, projected with the upscaler's camera.
One Steam account cannot be in a lobby twice, and this PC has not the memory for two games, so the room and the game side were run with one game and tests/coop_peer.py as the second player over runtime/coop_local.c, a stand-in for Steam on 127.0.0.1 that only the environment turns on: the peer was let in, saw the game's Link in Hyrule Field, chat went both ways, the save was copied, one flag the save lacked was set and a flag the game does not share was refused. On Steam itself one game signed in as app 480, made a room, showed its ID and the player's Steam name on the Co-op tab and left. Not run: two Steam accounts in one room, an invite, a join by room ID over Steam, a host that leaves, a removal, and the menu's text probe on this build.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The camera kept its height (only ZR and ZL changed it) and rose whenever the closest surface in the lower part of the view came within about three metres, so flying up to a character, a rock or a wall sent it upwards. It now moves where it looks and nothing stops it, the ground included.
Ground avoidance is a checkbox in the debug menu's free camera section. With it on, the nine view distances read back from the lower view become points of the scene (from the view's angles and the camera's pitch), and only a column whose lowest surface rises by less than about 30 degrees counts as ground: the camera goes no lower than a metre above it. Steeper things, objects and walls, are left alone. The read-back runs only while the switch is on.
Tested on a village save, 4 m/s forward for 5 s and then ZL for 4 s: with avoidance off the camera ended 17.4 m lower, through the floor; with it on it ended 0.7 m lower and held there. Flown at Link with the first version of the ground test, its height did not change.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Turned to alternate sides every time, he stayed pressed against the cliff face south of the Kakariko Village gate for ten sidesteps.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A teleport without a start position, or with one the area does not list, put Link where nothing held him: in Kakariko Village he fell for good, and the game refuses events, teleports included, while Link is in the air. The game's list has an empty name in 45 areas, which the Teleport tab listed as a default start; those entries are left out, and such a request takes the area's first listed position. For a few seconds after arriving, Link falling 25 m below where he arrived is taken for a fall through the ground, and the area's next start position is asked for, up to three times.
The free camera's left stick moved it along its view, so a camera looking down flew into the ground, and below it the picture showed the void under the map, which looks like ground the game failed to draw. The stick now moves it level, only ZR and ZL change its height, and with DLSS, DLAA or FSR 3.1 or 4 on, nine of the view distances the upscaler's motion pass works out (vk_dlaa.c fcam_probe) come back each frame and the camera rises where the ground ahead or below is within a clearance that grows with its speed. Flown at 25 m/s two metres above Hyrule Field, it went over every hill.
For test runs, NX2NAVI_DBG_TEST gains route and routeto: Link is steered through points, or through the area's own start positions, from the way he moves, and sidesteps where he stops gaining ground. The start positions' coordinates are read from the same file as their names.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With it on, the game draws from a camera of the menu's instead of its own, in play and in cutscenes. The left stick moves it along its view and sideways, the right stick turns it, ZR and ZL raise and lower it, R makes it faster and L slower, and Link stands meanwhile; or the camera stays where it is and the pad plays the game.
It works inside the game's own camera update: a new patch site sends the instruction at which the frame's position, target and up vector are final to a host function, which replaces them for the camera that follows Link and the one the events direct, so the game draws, culls and loads detail for what the free camera sees. The camera of the interface's 3D models and the one the sound follows stay the game's. The set is off unless the menu switches it on. A teleport's arrival starts the free camera again from the game's view.
Tested in Hyrule Field with scripted stick input (turn, rise, strafe, with Link's position unchanged), with the pad playing while the camera stays, across a teleport to Kakariko Village, during the Kakariko arrival cutscene, and switched on by a click in the menu.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The Teleport tab lists every area of the game with its named start positions, read from the player's own game files: the warp songs' pads, both sides of the loading zones and the boss rooms among them. A click changes area the way the game's own doors do: during a short event of the game that only waits, the menu reserves the next area and start position in the game's data and asks the game's sequence for the change, so the area unloads and loads as in play, a first visit's cutscene plays and a boss room starts its fight.
The Cutscenes tab lists the game's event scripts by name and starts one through the game's event manager.
Tested from Hyrule Field to Kakariko Village, the Forest Temple, Kokiri Forest in the child's time, the bottom of Lake Hylia, Volvagia's room, and the pads of two warp songs, four of them in one run, with Link walking afterwards; the Kakariko arrival cutscene started by name.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
With debug_menu = 1 (off by default; the Game tab has the switch) F9 opens a panel on the left edge in the
performance overlay's look, with the game in view beside it. ui/menu.cpp lays it out in the settings menu's place,
so its input and the game's blocked pad are the menu's own. Typed characters now reach the menu for its text fields.
Flags: the game's 11,292 on/off flags are read from its game data manager, and a click changes one through the
game's own function on the game's thread at its pad read (runtime/debug_tools.c dbg_tick), so the game applies it
at its next update as it does its own changes. The game knows a flag by the hash of its name only; the names shown
are found in the player's own event flow files, hashed and matched when the panel first opens (2,250 of them from
915 files in 0.2 s), and none is kept in the code. World: Link's position, and a speed factor from 0.05 to 8 that
multiplies the step the runtime gives the game each frame (measured 0.50 at 0.5x). Memory: a search of the heap
for a value of 1, 2 or 4 bytes or a float (about 2 s), narrowed by equals, changed, unchanged, went up or went
down, with a value to set at a place or to hold there every frame.
Tested through the window's own messages: F9 opened it, a click on a flag set that flag in the game, text typed
into the filter narrowed the list, and F9 closed it; a scripted run set and held a value and put it back.
Teleporting, a free camera and starting cutscenes are not in it: writing Link's position, or every copy of it in
the heap, moved him back within three frames, so they need the game's own warp, scene-change and event functions.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
