From 1b75bb9229336b560e8e7e2194634031f865ef1f Mon Sep 17 00:00:00 2001 From: sganggs Date: Wed, 7 Oct 2026 18:55:27 +0800 Subject: [PATCH] =?UTF-8?q?feedback6:=20DESIGN=20=C2=A726.14=20(every=20op?= =?UTF-8?q?erator=20at=20full=20potential,=20from=20the=20R21P=20stream's?= =?UTF-8?q?=20draft)=20and=20=C2=A726.15=20(Esc=20in=20the=20=E8=87=AA?= =?UTF-8?q?=E9=80=89=20picker);=20the=20=C2=A726=20intro=20lists=20both=20?= =?UTF-8?q?and=20the=20owner's=20full-potential=20decision=20(no=20host=20?= =?UTF-8?q?setting)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - docs-consistency / docs-paths 31 / 31. --- docs/history/0.2.1.md | 91 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 89 insertions(+), 2 deletions(-) diff --git a/docs/history/0.2.1.md b/docs/history/0.2.1.md index 4bed37d8..c7bef917 100644 --- a/docs/history/0.2.1.md +++ b/docs/history/0.2.1.md @@ -11,13 +11,13 @@ landing on a teammate's half of a shared field → §26.1; 联防 back on the ro the bond lists → §26.3; a consumable on a full carrier → §26.4; the 外勤医疗 Touch → §26.5; 凋亡 and stored charges → §26.6; 贾维's 拉普兰德 → §26.7; .gitignore → §26.8; enemy flyers over raised tiles → §26.9; enemy animation states → §26.10; battle messages while the browser prepares a battle → §26.11; the 频次 器物 and leader summons → §26.12; the -bond strip's collapse arrow → §26.13. +bond strip's collapse arrow → §26.13; every operator at full potential → §26.14; Esc in the 自选 picker → §26.15. Decisions of the owner: 2026-10-07 — a 突袭 member may land on a teammate's half when both halves of the field are taken (the two-helper 联防 field, the Final Assault / Hidden Core pair field), replacing part of §25.18.1; 乌尔比安's S3 【移动】 keeps his own board (§26.1); 联防 plays on the round's battlefield again, from the owner's knowledge of the official mode and a tournament video (§26.2, withdrawing §25.6.4); 0.2.1 within hours of the report; every operator at -full potential (pending, the R21P stream); the 自持有 bonus, multi-language voices and the title particles are not in +full potential, no host setting (§26.14); the 自持有 bonus, multi-language voices and the title particles are not in 0.2.1. ### 26.1 突袭 may land on a teammate's half when both halves are taken (the owner's decision of 2026-10-07) — `sim/battle/players.js onFieldBoard`, `content/bonds/addon/battle.js raidTile` @@ -427,3 +427,90 @@ here to avoid a conflict on that one-line paragraph): 盟约详情的「成员 - **Now**: a bare chevron (‹ open, › folded), transparent, at 55 % opacity (80 % when folded), full opacity and mint on hover / keyboard focus; the 44 × 44 touch target stays as an invisible hit area and the name is the aria-label (展开盟约 / 收起盟约). Tests: `test/ui/bond-collapse.e2e.test.js` (SP_E2E, 2). + +### 26.14 「当前全体干员为无潜能，与官方实现不符」 (GitHub #252 by SpiritedAwayCN, PR #255 by SpiritedAwayCN — a host slider, not taken): every operator fights at FULL potential (潜能 6) — the owner's decision of 2026-10-07 — `tools/build-data.mjs OPERATOR_POTENTIAL / withPotential`, data/chess.json / backups.json / tokens.json, data/i18n/*.json + +- **Seen**: every operator fought at potential 1 (no potential): 刺玫 (tier 1, E1 Lv55) ATK 413 / cost 17 where the + official panel reads 435 / 15; 砾's redeploy 18 s instead of 16, the gift 5★ (至简 …) 80 s instead of 70; every + 「天赋效果增强」 step missing (刺玫's 土壤基肥改良 108 % instead of 111 %, …). The data build picked every candidate at + potential rank 0 and added no `potentialRanks` attribute step. +- **Official**: the season's chess records (activity_table act2autochess `charChessDataDict` `status`: evolvePhase, + charLevel, skillLevel, favorPoint 0, equipLevel) carry no potential field; a tournament video (bilibili BV1FTowB2EzP, + 02:36, linked in #252) shows 刺玫 at ATK 435 / cost 15 — exactly her E1 Lv55 413 / 17 plus her potentials 攻击力+22 and + two 部署费用-1. In the official game a player's own potential applies (RushFTK in #252: 0 信赖, potential from the + account; an operator not owned — potential 1; the shop rows' `backupCharPotRank` is 0 except 宴 / 野鬃 1). The owner's + decision of 2026-10-07: everyone at full potential, no host setting (PR #255's 1–6 slider is not taken). + **Summons**: a token's own character has no `potentialRanks`, but its talent candidates carry `requiredPotentialRank` + mirroring its owner's 「天赋效果增强」 (夕 潜能 5 → “小自在” 化境 15 → 18 层; 凯尔希 潜能 5 → Mon3tr 不毁重构 3.5 s / + 1400 — PRTS 凯尔希 天赋 "潜能增强=5 … 晕眩3.5（+0.5）秒…1400（+200）点真实伤害", X 模组 3 级 4 s / 1700; 望 潜能 3 → 棋子 + +1 持有 / 部署; 麦哲伦 → 龙腾 22 s; 鸿雪 → 打字机 −20 % / −25 % 5 s; 伺夜 → 狼群 200 DEF ignore; 风丸 → 纸偶 ×2.75; …). + So a summon picks its candidates at its owner's potential and takes none of the owner's attribute steps (ATK / cost / + redeploy belong to the owner entity). +- **Now**: `OPERATOR_POTENTIAL = 5`. Every chess (normal and elite), every 补位 / 自选 unit form (`buildUnitForm`) adds + every `potentialRanks` attribute modifier to the interpolated attributes before rounding (`withPotential`: all + ADDITION — COST, RESPAWN_TIME, ATK, MAX_HP, DEF, MAGIC_RESISTANCE, ATTACK_SPEED; another kind is reported, none + exists) and picks talent / trait / module-talent candidates at rank 5 (`bestCandidate(…, potRank)`). Summons + (`tokenVariant`, tokens.json and backups.json `tokens`, `tokenTalentDeckBonus`) pick theirs at the owner's rank; the + band's map characters and stage devices stay at 0. The 17 原型干员 stand-ins (预备干员 char_600–607, char_608–615, + 领主·Sharp) have no potential ranks: unchanged. Nothing else reads potential: no skill or trait candidate of the + season's operators carries a `requiredPotentialRank` > 0, skill levels never depend on it. + JSON compare (old vs new build): only potential-driven fields moved — chess.json 256 of 266 records (all but the + four DIY slots and 盟约·辅助干员, which has no potential ranks; stats cost 256, + respawnTime 200, atk 176, def 16, maxHp 14, res 12, aspd 6 — `statsBase` the same; 275 talents and 140 talentsBase + entries, 27 module talent changes: bb + desc), backups.json (the 71 owned picks' three forms — none of the 17 + stand-ins: cost, atk, respawnTime, hp / def / res / aspd, talents, module talent changes; 8 of 38 summons: Mon3tr, + 龙腾.F / L / A, 打字机, 结构性原理 talents, 望's 棋子 deploy limit 6 → 7 / holding 7 → 8 / count 7, 多萝西's 共振装置 + count 8 → 10), tokens.json (5 summons' talents: “小自在”, 海嗣, 纸偶, 狼群, 防护单元); + every other data file byte-identical. The data translations (data/i18n/en / ja / ko / zh-TW) are rebuilt + (`tools/build-i18n.mjs --offline`): only the talent texts that carry the new numbers. Spot checks: 刺玫 435 / 15 / + 66 s and 111 %; 格雷伊 ASPD 100 → 106 (攻击速度+6), 崖心 / 伊内丝 +8; 砾 16 s, 至简 70 s, 野鬃 60 s (two 再部署时间-10秒: + #252 said 70 for the gift 5★ — true for 至简; 野鬃 has two such steps). The 干员调配 局内数值 and the detail card read + the records (statsBase + module attr, shared/loadoutRecord.js), so they show the new numbers unchanged in code. + One kit read a number from a talent text that now carries the potential step: 望's stock cap, 「最多拥有7枚」 at + potential 0, reads 「最多拥有8（+1）枚」 — `op-wang.js` matched `/最多拥有(\d+)枚/` and fell back to 7, so with 7 棋子 to + start she sat at the cap (阻回, no S1 / S2); the pattern now skips the step (8 = the 棋子's holding, deckStack 8). The + other kits that parse talent texts (多萝西 「最多拥有10个」, 娜仁图亚 「偷取触发2次」, 傀影 「攻击力各+10%」, 伺夜 「至多3只」) + read numbers that carry no step; skill texts have no potential steps. +- **Consequences worth knowing** (the data's, nothing assumed): 多萝西's 共振装置 stock at a deployment is 10 at full + potential (潜能 5 「第一天赋效果增强」) — her trap limit without TRP-X is 10, so the kit's 阻回 (no SP while the stock is + full) holds from her deployment until a trap is spent (TRP-X: limit 13, no change); 望 sends 7 棋子 (TRP-X 8); 史尔特尔's + 余烬 lasts 9 s; 琳琅诗怀雅's 破财消灾 revives to 80 %. One official-data quirk surfaces: 重岳's FGT-Y stage 3 potential + candidate (battle_equip_table uniequip_003_chyue) keeps `prob` 0.23 while its text reads 「25%（+2%）」 (damage_scale + 1.75 → 1.8 does move) — the sim follows the blackboard, as for 嵯峨's SOL-Y before (op-saga.js), so that one form rolls + 23 % and every other form 25 %. +- [ASSUMED] none beyond the owner's decision (full potential for every player and every operator, including the + 自选 picks, whose official potential would be the account's). +- Golden: moves almost everywhere, as a data change of every operator must — roster 49 / 49, bonds 46 / 46, + fields 22 / 22, matches 18 / 18, diy 133 / 138, standins 0 / 10. Unchanged: the 10 stand-in battles and the four + prototype 自选 battles diy-135…138 (the 原型干员 have no potential ranks), and diy-012 (twelve 夜莺 pieces that are + never hit, never redeploy and deal no damage, so her cost / RES / redeploy steps never show; her talents do not + move). Spot checks, the parent data against the new one tick by tick through the golden scenario path + (diy-110 / diy-111, 望's battles, also move with her cap fix): roster-001 and roster-020 part + at tick 1 on 角峰's HP (生命上限+250: 2770 → 3083 and 5961 → 6634 with the board's HP bonuses), bond-arcaneShip-high at 4.73 s and diy-001 at 3.70 s on an enemy's HP (a hit of a higher + ATK). Every moved battle's first differing snapshot hash is in its first 10 game seconds except one bond battle + (20–30 s) and ten 自选 battles (10–100 s): a later hit or redeploy; the matches part at rounds 1–8 through those + battles (battle results, then the bots' boards). +- Tests: test/full-potential.test.js (new, 6 tests — every one fails on the parent data): 刺玫 435 / 15 / 66 s and her + talent; the other potential kinds and #252's redeploy times; every chess, 自选 form and stand-in form re-derived from + the raw keyframes plus the potential steps; every chess talent = the last candidate unlocked with requiredPotentialRank + ≤ 5; summons at the owner's potential (PRTS Mon3tr numbers) without the owner's attribute steps; the loadout record + (局内数值 / detail card), 自选 / 补位 compositions and a battle unit (刺玫 base ATK 435, cost 15, 66 s). data.test.js's + independent re-derivation now adds the potential steps (and re-derives respawnTime too); the spot checks and the kit + tests that hard-coded potential-0 numbers carry the full-potential numbers (each from the data and the test's own + formula; no check loosened): 205 tests in the 71 自选 kit test files (op_*), 21 elsewhere (data / backups / i18n-data, + chess kits, summons, 史尔特尔 余烬 9 s, 望's hand of 7, …); op_wang's S1 / stock / S3 tests fail on the parent kit (the + stock cap). Full `node --test`: 5114 / 5114 pass (the first run on the new data: 233 failures in 87 files, two of them + timing tests that failed under load only and pass alone). + +### 26.15 Esc in the 自选 picker closes only the picker (GitHub #284 by Xinglan233, idea from PR #286) — `screens/diy.js DiyPicker`, `screens/loadout.js` + +- **Seen**: in 干员调配 → 自选编队, one Esc with the operator picker open closed the whole overlay and went back to the + lobby (5阶 and 6阶 slots, also from the picker's search field), while the picker's 取消 and × close only the picker and + the 导入 dialog's Esc closes only itself. The overlay's capture-phase key handler gave way only to a `.modal`; the + picker is a `.diy-pick` section without key handling of its own. +- **Now**: the picker registers its own capture-phase Esc handler that acts as 取消 (the draft is dropped, the saved + picks are untouched) and gives way to a `.modal` over it (the 导入 dialog); the overlay's handler skips Esc while a + `.diy-pick` is open. The next Esc closes the overlay as before. +- Golden: unchanged (interface only). Tests: test/ui/diy.e2e.test.js — a real-server browser test that needs no art: + Esc closes the picker of a 5阶 slot, then of a 6阶 slot from its search field, the overlay and its four slots stay, + sp.pref.diy is unchanged, and a second Esc closes the overlay; it fails on the parent.