Tears of the Kingdom · 09

Zuggle の技術原理

整理・修正版

基本情報

  • 発見者:Zvleon
  • 発見日時:2023年5月16日
  • 主な効果:複数の装備の攻撃判定(hitbox)や装備効果を異常な形でリンクに重複させ、武器の攻撃力や盾の効果などを積み重ねる。

核心定義

Zuggle(ザグル)は、装備 actor の EquipmentUserComponent における ActorLink の状態と、actor 層の計算依存関係(calculation dependency)の状態が同期しなくなった結果である。装備はもはや正常な装備欄の装備ではなく、「ドロップ中 / スマグル」の状態でもないが、リンクへの計算依存だけは残り続けるため、異常な状態のまま付着し続け、セーブのロードやシーン切り替えを経ても保持され続ける。

簡単に言うと、ゲームは本来「ある武器を装備する」という出来事を、2つの場所に同期して記録する必要がある:

  • Menu 側:メニュー、インベントリ、現在の装備データ。
  • World / actor 側:シーン内の実体としての装備 actor、およびそれとリンクとの間の計算上の連結。

正常に装備を捨てたり、切り替えたり、解除したりする際は、この両方が同時に更新され、きれいに片付けられるはずである。Zuggle が発生するのは、これらのデータの同期が完了しなかった場合である。

正常な流れ vs. Zuggle の流れ

通常、武器・弓・盾を装備すると、その装備は EquipmentUserComponent 内の ActorLink を通じてリンクに接続される。

装備が捨てられたり、切り替えられたり、解除されたりする際、ゲームは理論上、以下のことを同期して完了させる必要がある:

  1. インベントリデータ(GameData)を更新する。
  2. 現在の装備欄の状態を更新する。
  3. 古い装備の ActorLink を削除または置き換える。
  4. 装備 actor のリンクに対する計算依存関係(calculation dependency)を解除する。

Zuggle が発生するとき、ActorLink、装備状態、ドロップキューの更新タイミングがそれぞれずれる。データの一部がすでに削除、上書き、あるいは処理完了していたとしても、装備 actor のリンクに対する calculation dependency だけが残り続けることがある。

これが、Zuggle を単純に「インベントリのズレ」や「drop キューに詰まっている状態」として片付けられない理由でもある。Zuggle を成立させている本質は、帳簿上の状態はすでに変化しているのに、actor 層の依存関係だけが残り続けている点にある。

マップザグルが形成される時系列

以下ではマップザグル(Map Zuggle)を例に説明する。装備が捨てられても、リンクとの連結はすぐには解除されない。まず PouchMgr のドロップキューに入り、捨てられた装備の連結が一時的に保持される。

  1. マップを開く前に、クイックメニューから現在の装備を捨てる。
  2. すぐにメニューを開き直し、別の装備に切り替える。
  3. メニューを閉じてマップを開き、装備の切り替えとドロップのリクエストが別々のタイミングで処理されるようにする。
  4. さらにインベントリから現在の装備を捨て、2回分のドロップリクエストを後続処理に入れる。

この過程によって、インベントリデータ、現在の装備状態、そして PouchMgr が一時保持している装備の連結の間にズレが生じる。後続のドロップ処理が、一時保持中の装備と現在の装備を同一のものと判定した場合、ゲームは正常な解除や削除の処理を飛ばしてしまうことがある。

最終的に「複数の装備がリンクへの calculation dependency を保持したままなのに、EquipmentUserComponent には有効な ActorLink が1つしか残っていない」という状態が形成される。これがマップザグルである。

4つのシステムそれぞれの状態

システムZuggle 発生時の状態
GameData(インベントリ/メニュー)装備がすでに切り替えられた、捨てられた、あるいは現在の装備ではなくなったと認識している
PouchMgr(ドロップキュー処理)ドロップリクエストの処理が完了している、または判定失敗によりインベントリへ差し戻されている
EquipmentUserComponent現在の装備欄の ActorLink がすでに削除、上書き、または別の装備を指すよう変更されている
actor 層 dependency装備 actor のリンクに対する calculation dependency が残り続けており、同期して解除されていない

mPendingDrop:Zuggle の現れ方を決める鍵となる値

dt-12345/zuggle のリバースエンジニアリング資料によると、zuggle された装備には DynamicEquipmentComponent 内にブール値があり、仮に mPendingDrop と呼ばれている。これは「この装備が現在もドロップ待ちの状態かどうか」を示すもので、Zuggle 後の現れ方に影響する。

mPendingDrop装備の挙動型
trueほぼすべての外部からの状態変更リクエストを無視し、ドロップ系のコマンドのみ受け付けるスタティックザグル(標準型)
falseドロップリクエストを拒否するが、他の装備状態の変更は引き続き受け付けるダイナミックザグル

※ 訂正:以前の整理ではこの2つの挙動を逆に書いていた。正しい内容はこの表を基準とする。

Zuggle と Smuggle の違い

状態の性質一言での定義
Smuggle ドロップ/装備の処理がまだ進行中 装備は active drop / smuggle relation を保持したままで、システムはそれをまだドロップ中の装備として扱っている
Zuggle ドロップ/装備の処理はすでに終了、上書き、または見失われているが、依存関係は片付いていない メニューと装備欄の帳簿上の状態はすでに変化しているが、装備 actor のリンクに対する calculation dependency が同期して解除されていない

簡単に言うと:

Smuggle が捉えているのは「ドロップ中」という段階における矛盾であり、Zuggle が捉えているのは「ドロップ/装備の処理がすでに終わった、または上書きされた」後にも依存関係だけが残り続けているというズレである。

※「active/終了済み」は整理する際の分かりやすさのための表現であり、元データにおける正式な用語ではない。

一言でまとめると

Zuggle の本質は、「装備を捨てる、あるいは切り替える」という一見単一に見える動作を、同期が完了しない2本の経路に分裂させてしまうことにある:

  • Menu / GameData / PouchMgr という「帳簿上の状態」の経路。
  • EquipmentUserComponent / actor dependency という「実体の依存関係」の経路。

帳簿上の状態がすでに処理、上書き、または終了しているのに、実体としての actor のリンクに対する calculation dependency が同期して解除されていない場合、システムには「メニューや装備欄ではもう正常に認識されないが、ワールド側では依然として異常にリンクへ付着し続けている」装備が残ることになる。

そして mPendingDrop が、この残留した装備がスタティックザグルとダイナミックザグルのどちらに近づくかを決定する。