2 Commits

Include renames

Author	SHA1	Message	Date
Nicholas ButzkeandClaude Opus 5	2efc21b18d	feat(menu): PLAY is one press, and the level cards are photographs ... Reaching a game was Singleplayer → pick a level. Reaching a multiplayer game was Multiplayer → Host Game → wait → pick a level → wait, and the gamemode dropdown had exactly one entry which set a string nothing read. PLAY now starts the last map and mode played, and says which — "Akiba Crossing • Deathmatch" under the button, so pressing it is a promise rather than a leap. Everything else on the home screen is a detour from that, which is the right shape for a menu: the common case is a button, not a path. Hosting is one press and lands in the lobby already hosting; the lobby puts map, mode, players and start on ONE screen; Enter connects, so typing an address does not then require reaching for the mouse. This is the lesson HoYoverse published about Zenless Zone Zero's first months more loudly than anything else they have written. Their postmortem on the TV mode names three complaints — it took too long, it sat between the player and the combat, and there was too much of it early — and 1.2 removed it from the story entirely rather than shortening it. Time spent BEFORE the thing the player came for is not neutral, it is a cost. The cards were a two-stop gradient generated from two colours in a meta file, whose hover state was `use_hdr = true` — not a visible change on any of them. They are photographs now, shot by debug/map_preview_capture.gd, which took three attempts to get right and each attempt is a comment in the file: - framing each map from OUTSIDE by merging every VisualInstance3D's AABB produced five tiny dioramas floating on a table, and one solid black rectangle. That is a minimap, and a minimap is not a photograph. - standing at a spawn point fixed three maps and left two black: fps_blockout is genuinely dark and most of its spawns face an unlit wall, and procedural_arena builds its geometry at runtime so no fixed offset is reliably inside it. - so the tool now RENDERS several vantages and scores each result — mean luminance times its standard deviation, because brightness alone picks the empty sky and variance alone picks a high-contrast corner of a dark room. Their product picks a photograph. A black rectangle passes any check that only asks whether the camera ended up somewhere sensible. Also fixed, and caught by looking at the screenshot: the selected mode chip was unreadable. Its glyph is ink on volt, and the theme gave every button a 5 px INK outline — an ink glyph inside an ink outline is not outlined, it is five pixels fatter, and on a small chip that is a solid blob. Button labels now carry no outline at all, which is the same reasoning debug/ui_contrast_check.gd already encodes: an outline separates a glyph from a backdrop it cannot beat alone, and a label on a solid chip does not have that problem. The chips keep their heavy ink border, so nothing about the drawn look changes. `current_gamemode` is normalised on the way in, because it used to hold a display string and six callers still pass one. An unrecognised id compares unequal to GameMode.GUN_GAME and would silently disable that mode's weapon issuing — half a mode is worse than none. The menu's background character is the player's OWN skin holding their weapon, rather than the box-and-capsule mannequin that stood there before. spawn smoke 0, game modes 30/30, movement 11/11, contrast 108/108, HUD layout PASS, weapon holds 0, dances 0. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-28 12:40:50 -04:00
Nicholas ButzkeandClaude Opus 5	26f7c2c622	feat(ui): one high-voltage theme, and pick your character from the escape menu ... The theme was a comic one — cream paper, ink borders, papaya. It is now a charged one: near-black violet, hot papaya, and a lightning yellow spent nowhere except the instant a button is pressed. Chips are cut with two sharp corners and two round ones on a diagonal, which is as close to a skew as a StyleBoxFlat gets and is the difference between a button that reads calm and one that reads fast. BoltRule draws the motif itself, struck a third of the way along its rule rather than centred, so it reads as something that HIT the line. The pause menu was 900 lines of hand-rolled UI that never referenced UITheme at all, so it rendered in Godot's default grey. It now applies the theme — and applies it to its own root Control, not only to the Window, because a Control inherits from its nearest Control ANCESTOR and this screen hangs off a CanvasLayer, which is not one. That was invisible at first: the parts built with UITheme.title() carry their own overrides and looked right next to a list and a button that did not. And it now has a Character screen. The roster on the left, the character themselves on the right, turning — a name in a dropdown is not a character selection screen. The preview is a real SkinnedPlayerModel in its own world, so it shows exactly what will spawn: the same cel look, the same per-class outlines, the same cloth and hair on springs. Selecting applies immediately; there is nothing destructive to confirm, and applying on selection means the character behind the menu changes as you arrow the list, which IS the comparison. PlayerMovementController.set_skin() is the supported way in. Both halves of a skin change are easy to do by halves — `synced_skin_id` is what REMOTE peers rebuild from, and only their _process watches it, so setting the property alone would change everyone else's view of you and not your own. Checked rather than asserted. debug/character_picker_check.gd walks the whole roster and proves each entry loads a skeleton, animations, a surface table and body surfaces — and that the skeleton is MOVING, because the clip name is a variable this class sets on itself and reads "Idle" just as happily when nothing is ticking. debug/ui_capture.gd and debug/roster_capture.gd photograph the screens and every character, which is how three things were found that no assertion could see: the theme break above, a preview showing the back of the character's head, and a turntable that carried on from the last character so the third one you looked at was side-on. Known and not fixed here: momo's idle pose is wrong — arms overhead and a pinched waist. Her rig, not the picker; every other character is correct. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-27 14:46:14 -04:00