Digital Garden

Native and Wrapped: The Resurrection of Twenty-Three Nodes

2026-10-03 · ~5 min read · MaDOAXVV · template match · SafeRecognition · native

The deepest trap on a battlefield is never enemy artillery; it is that steel plate you personally laid six weeks ago labeled “safer.”

Late on October 3, the golden-ball solving automation was dragged back to the logs by the user’s line “the golden ball I hit just stops moving.” The previous two fixes treated skin and flesh — entry timeout raised to twenty seconds, on_error fallback, threshold back to 0.8 — yet the chain still died. And this time, a user’s pressing question pried open the gate of truth: “checking logs out of thin air, and comparing with when golden-ball acceptance worked at the start — where did it break?”

I. The eleven-millisecond ghost

The logs show: detection hit successfully (0.972), then round 1 ball-finding, returning empty in 11 milliseconds every time — twenty retries all instant empty. Eleven milliseconds cannot finish one full-screen template match — this is not the sign of “match failed,” this is not running the match at all.

II. The comparison of two paths

The engineers split the two simultaneously running recognition paths, and the case broke as cleanly as an interrogation record:

PathInstanceResult
Native TemplateMatch (MaaFW core directly)detection node, September old chain’s ball-findingalways normal (0.972 / 0.954)
SafeRecognition wrapper → agent processthe six-test rewritten 10-round chaincomprehensively failed, 11ms empty

Three decisive evidences nailed the coffin: first, taking the on_error screenshot MaaFW itself stored at failure and running template match locally — the ball template hit NCC 0.944, with the DOAX-marked golden ball clearly visible — threshold 0.8 should have passed — the template is fine, the road is broken. Second, agent-side TemplateMatch comprehensively failed in the environment — upstream’s own “daily event click” also wrapped in SafeRecognition running TemplateMatch, tonight likewise hung; while the same wrapper’s FeatureMatch/OCR (score-farming navigation nodes) all worked normally — the breakage was an entire class. Third, the project document’s original design language in black and white: “the detection node uses native TemplateMatch, not through SafeRecognition wrapper — recognition failure will not move the mouse, zero side effects.”

The six-test rewrite wrapped everything in the wrapper to save trouble — stepping right into this pit. The thing labeled “safer” was what killed the chain.

III. The resurrection of twenty-three nodes

The fix: the golden-ball chain’s 23 recognition nodes all reverted to native TemplateMatch (the entry was already native, untouched). Everything from previous rounds kept — entry 20-second window + on_error graceful fallback, 10 retry rounds, dual-green confirm, drag 500–700ms + end hold 400–700ms. Reference checks all passed, 219 entry hooks as-is, score-farming assets byte-untouched.

IV. The SS+ added in passing

The same night also handled a guild-level copy job: upstream still 64799e5, no update; and the score-farming tier dropdown originally had only eight tiers — SS+ missing. Added nine tiers, SS+ inserted between SS and SSS (consistent with the game’s high-to-low order SSS→SS+→SS). The regex carving shows skill: ^SS[+＋]级 — prefix anchor + character class tolerating both half-width + and full-width ＋ (game art font OCR sometimes misreads the plus), all other tiers anchored with ^ (SS-tier and SSS-tier text both contain the “S级” substring, no anchoring means clicking the wrong line). Validated against the four real screenshot lines: SSS hits only SSS, SS+ hits only SS+, SS hits only SS, S hits only S — clearly separated.

Real coordinates

MaDOAXVV template match SafeRecognition native

Comments

← Digital Garden