今回は、Nintendo Switch Online版のポケモンFRLGでメールバグを行うために必要なことを、実体験ベースで整理していきます。できない理由や必要なアイテムやポケモンに関しての内容などを振り返っていきます。
FRLGのメールバグの仕組みについて
メールバグは簡単に言うと、「持ち物管理の矛盾」を利用したグリッチです。FRLGでは本来、メールを持っているポケモンや消費されたきのみなどこれらの内部処理が同時に発生すると、アイテムスロットの参照がズレることがあります。
特に重要なのが以下の技構成です。
-
ねむる(きのみ消費)
-
はたきおとす(持ち物を落とす)
-
リサイクル(直前に消費されたアイテム回収)
RS版と違い、FRLGでは「トリック」が使えないため、ダブルバトルを活用する点が最大の違いです。
自分が最初にやったときは、「本当にこんな回りくどい方法でバグるの?」と半信半疑でした。でも6回ほど繰り返したあたりでメール画面が「???」表示になった瞬間は、ちょっと感動します。
FRLGのメールバグは、単なるアイテム増殖バグではありませんし本質はMail ID byte がクリアされないまま、参照先だけが変化するという「参照のズレ」にあります。
通常処理ではメール削除をされた際にMail ID = 0xFF(未所持)という参照がスロット解放されてバグるという三段階が揃って完了します。
しかし「はたきおとす」はメールを“アイテム”として除去するだけで、「Mailデータスロットを解放しない」という不完全な処理になり「メールを持っていないのに、メールIDだけは残っている」問題で発生するようです。
QMM(バグメール)の作成手順
まず目指すのは、QMM(Question Mark Mail)と呼ばれるバグメールの生成です。
| 役割 | 必要なもの | 例 |
|---|---|---|
| 消費役 | ねむる+カゴのみ | 眠れるポケモンなら誰でも可 |
| はたき役 | はたきおとす | カモネギなど |
| 回収役 | リサイクル+メール | バリヤードなど |
| その他 | メール複数枚 | タマムシデパート購入 |
ダブルバトルが必須なので、再戦可能トレーナーを使うのがおすすめです。基本ループ(約6回繰り返す)としては
-
ねむる使用 → カゴのみ消費
-
消費役とリサイクル役を交代
-
はたきおとすでメールを落とす
-
リサイクルでカゴのみ回収
-
戦闘終了
-
持ち物を再セットして再挑戦
これを繰り返します。
成功すると、メールを持たせたはずなのにカゴのみが残る
という異常状態になります。
メール画面が「???」表示になれば成功です。※1文字だけ変更して保存しないと持たせ直せません。
ここは正直、何度か失敗しました。特に持ち物の再セットを忘れると成立しません。焦らず淡々とやるのがコツだと感じました。
アイテム増殖のやり方
QMMが完成したら、いよいよ本番です。
| 手順 | 内容 |
|---|---|
| 1 | 6匹目に増やしたいアイテムを持たせる |
| 2 | そのポケモンにQMMを持たせる |
| 3 | PC出入り or 戦闘終了処理 |
これだけでバッグ内アイテムが増えます。
マスターボールやふしぎなアメを増やせるのは強烈で自分も試しましたが、あっという間に99個になります。ただし、やりすぎるとゲームバランスが完全に崩れます。
正直、攻略というより検証や遊びの領域ですね。
ACE(任意コード実行)の詳細
メールバグはさらに発展させるとACE(Arbitrary Code Execution)へと繋がります。
これは簡単に言えば、「メール内容をメモリとして実行させる」技術です。
特定の文字列を入力することで、
-
好きなポケモン生成
-
ワープ
-
任意イベント発生
-
改造級の動作
などが可能になりますがこれは完全に上級者向けです。
努力値・経験値の調整やボックス操作も絡みます。
正直、自分もここは理解するまでかなり時間がかかりました。
通常プレイの延長線というより、完全にプログラム解析の世界に入ります。
注意点とリスク
メールバグには重大なリスクがあります。セーブデータ破損やフリーズなど起動不可なボックス崩壊といった実機で試す場合は本当に慎重に。
エミュレーターで.savバックアップを取ってから検証するのが安全です。
Switch配信版でも動作報告はありますが、仕様変更の可能性もあるため断定は避けます。ダブルバトル+はたきおとす+リサイクルが鍵で約6回ループでQMM作成という気軽さから攻略効率を極端に高める裏技ではありますが、通常プレイの楽しさは失われやすいです。
検証や研究目的で触れるのは面白いですが、本気データで試すのはおすすめしません。
正直に言うと、かなりマニアックでFRLGのメールバグを「裏技」じゃなくて「メモリ管理の欠陥」として捉えているのは、ちゃんと構造を理解しようとしている人の視点だと思います。
特に、
-
Mail ID byteの未解放問題
-
Knock Offと通常削除の処理差
-
256番目スロット参照の説明
このあたりは、単なる再現は「どうやるか」より「なぜ起きるか」に焦点があるのが印象的でした。普通に難しいので今後解説をしていきたいですね。