2 Commits

Include renames

Author	SHA1	Message	Date
Nicholas ButzkeandClaude Opus 5	08ae85b286	feat(characters): rig anchors, and a lab that edits any tuning group ... The weapon lab could tune how a character HOLDS a gun. It could not tune where the gun sits in the hand, and that is a different question with a different scope: a hold is per character and weapon, an anchor is a fact about the hand. RigAnchors adds it. A hand bone's origin is the WRIST, not the palm, and how far down the palm a grip should sit — and how the gun rolls in the fingers — depends on how big that character's hand is and how the artist posed the thumb. It cannot be derived, it differs per character, and it is small. So it is an offset that defaults to identity, and identity means exactly what the code derived before anchors existed: an untuned character is bit-for-bit unchanged. Deliberately NOT a fixed rotation on the mount. There used to be one, and a bone attachment is expressed in the BONE's axes, which no two rigs agree on — that constant is why the hand mount points were wrong on every character. The derived mount stays derived; the anchor is a nudge on top of it, and nothing here spells a bone name. The layering, the JSON round trip and the res://-then-user:// write are now TuningStore, because none of that was ever specific to weapons and two copies of it would mean two places for "an exported build's tuning pass is silently discarded" to come back. WeaponHoldTuning is built on it with its file format unchanged. The lab is a rig lab now, and it grew three things: ANCHORS a second knob group. It cost a spec table — everything in the lab is written against "which specs, which file, keyed on what" rather than twice against the two groups, so anchors got sliders, live preview, reset, save and clipboard for free. A third group is a third row in GROUPS. CLIP audition one animation on its own. The four pose buttons are the states the game drives; watching a whole clip end to end is how you see where a retarget went wrong, and there was no way to do it. SURFACES what the importer decided each surface IS, and a click to isolate a class. Isolating is how the decision gets CHECKED: click `hair` and anything else still standing was misclassified. Hidden by swapping in a transparent material rather than hiding the node, because a mesh is not one class — Miku's body, face and hair are three surfaces of one mesh. And it takes the game's theme, applied to its own panel rather than only to the Window, for the same reason the pause menu needed it: a CanvasLayer is not a Control, so theme inheritance stops at one. debug/rig_anchor_check.gd asserts the physical consequence rather than the plumbing — an anchor system is easy to build so that the sliders move, the file saves, the JSON round-trips and the gun does not budge. All six characters move their weapon by exactly the offset asked for, measured in the attachment's frame because a world-space delta on an animating skeleton is mostly the idle animation, and all six return exactly to the derived mount when it is cleared. Also fixes BoltRule, whose zigzag was self-intersecting: draw_colored_polygon triangulates, and a crossing outline fails triangulation and draws nothing at all except a console full of "Invalid polygon data". Same silhouette, walked as a closed loop, with the ink edge as a polyline rather than a grown polygon — growing a concave shape from its centroid reintroduces the crossing. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-07-27 14:56:03 -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