ＡＣのメモリ解析のための覚え書き
ＡＣのメモリ解析のための覚え書き / ガレージのメモリ情報
戦闘時のメモリ情報01 / 戦闘時のメモリ情報02 / 戦闘時のメモリ情報03 / 戦闘時のメモリ情報04
注：このテキストも経津さんより頂いていたものをhtml化したものになります。各種調べものや改造コードの作成などで使わせてもらっています。
＜＜データの相互生成＞＞
ＡＣのメモリ管理は主にシステム画面とミッション、アリーナステージでそれぞれ全面的にメモリが書き換えられる。
つまり、システム画面中に割り当てられたメモリは戦闘ステージに移行する際にリセットされ戦闘中関連のメモリが上書きされるため、
ＰＡＲなどで恒常的に任意のアドレスに任意の数値を割り込ませると正常に動作しない場合がある。
なお、戦闘ステージやミッションではそれぞれのステージで戦闘中の動作関連のメモリが割り当てられるアドレスが異るため、
メモリを解析の際は一定のステージに固定して行う必要がある。
メモリの割り当てられるおおまかな構成は以下のとおり。
システム画面 ガレージ関連
パーツパラメータ関連
他戦闘画面 ＜リプレイや再戦で維持されるもの＞ 戦闘ステージデータ
各パーツの描画・挙動パラメータ
弾グラフィック関連
他
＜リプレイや再戦時にリセットされるもの＞
戦闘中の機体動作関連（座標・速度・角度・ＡＰ・安定性・機体サイズ・被弾サイズ他）
戦闘中の機体構成（運動性能・機体構成・各火器管制他）
他
読み込み中のメッセージと共に上記の「システム画面」と「戦闘画面」の継続情報が参照され、それを元にＣＤから再度読み込まれて生成される。
したがって、戦闘中にデータを書き換えてもごく一部の継続されるデータ以外はすべてリセットされる。
＜＜再現性テスト＞＞
アリーナ戦は元となるアセンブルデータの他に１Ｐ側のキー操作のみを記憶している。つまりＣＰＵは常に条件分岐で処理されている。
これを利用して再現性の確認テストを行うことができる。
リプレイのために記録されている内容 ・自機の各フレームの入力履歴 リプレイ開始時（現在読み込み中）に
生成される対戦ステージや各機体データ・両者の機体運動性能、機体システム、火器管制の各データ
どの対戦ステージでも常に同じアドレスに生成される。
・対戦ステージに関する各データ（両者の開始位置、ＡＰ、安定性、当り判定、状況他）
対戦ステージによって異るアドレスに生成される。
※リプレイ開始時に生成される各データはメモリ上のアセンブルデータや
選択している対戦ステージ情報を参照しており、リプレイのたびに新しく読み込まれる。対戦開始時に読み込まれ、
対戦からリプレイにわたって引き継がれるデータ・アセンブルデータ以外の基本的な構成データ（機体パーツの形状や特性、弾グラフィックごとの各特性等）
※対戦ステージの地形情報や機体パーツの形状、弾速など、パーツパラメータとして
独立して設定されて生成される運動性能や攻撃力等を除いた基本的なデータは
アリーナ対戦開始時にメモリ上によみこまれ、再びシステム画面にもどるまで新たに読み込まれず引き継がれる。この仕様により、対戦開始直後に両者の機体データを書き換えることで、異る武器や運動性能を与えてまったく同じ入力を再現することができ、
解析したデータがどのように処理されているのかや、パーツごとに性能が異るかどうかなどを調べることができる。
ただし、リプレイ中に両者の位置関係に対戦時と異る変動を与えたり、ＣＰＵロジックに異る分岐条件を与えた場合は、ＣＰＵが対戦時とは別の行動をとるようになる。
ついでにランカーメイキング利用法
・「ＦＬＹ ＦＲＥＱ」を“０”にした四脚・タンクの運動性能を“０”にすると、開幕位置で釘付けにできる。
・ロックと射撃のロジックのみを与えた状態の四脚は同じ速度の四脚で開幕後に左平行移動を行うと状況が変わるまで双方平行移動をしつづける。
・水平方向への速度は振幅があるので正確な速度調節は機体実サイズを変更して限界速度で調整した方がいい。
・被弾判定サイズに手を加える場合、運動するとリセットされてしまうためキーコンフィグデータを無効化するといい。
・「ＦＬＹ ＦＲＥＱ」を“０”にした重量二脚はブースト速度を“１”、ブースト消費を“０”にすると速度“１”でブーストしつづける。ブースト“０”にすると歩く。
ほかにもいろいろ、アイデア次第。
＜＜内部タイマー＞＞
内部でフレームをカウントしているアドレスがあり、フレームを監視して時間を実測する場合に必須。
検索方法は旋回最大速度を“１”にして左旋回し、機体角度の増加量（つまり１フレームで１増加する）と同じ増加量のデータをサーチする。
１づつ増加させられれば他のものでもかまわない。ちなみに該当するアドレスは複数あるが、タイマーとして利用する分にはどれでもかまわない。また、スローモーションで動きを観察したい場合でもミサイル大量発射などで処理落ちさせると一部の処理をスキップするようになるため、
正確に測れなくなる場合があるので注意。フレームレートを変更させればいいんだろうけどいまのとこ調べてない。入力後の動作計測はポーズ状態でタイマーをリセット（１００程度がいい、小さすぎると再度開幕動作になってしまう）し、
目的動作の入力をした状態からポーズ解除がやりやすい。
＜＜各データセット配列、検索方法＞＞
○パーツパラメータデータセット（システム画面）
各パーツパラメータが与えられているデータセットで、戦闘に移行する際にはこのパラメータを参照して戦闘中の機体データを生成する。
ただし、戦闘からシステム画面へ移行する際には再度ＣＤから読み込まれて生成されるため、戦闘前に設定したものはリセットされる。
なお、戦闘中の地形データ群が当てられるアドレスと同じ範囲に設定されているためＰＡＲで強制介入しつづけると地形のポリゴンが飛ぶなどの問題が発生する。ガレージやＳＨＯＰなどで確認できるパーツパラメータを確認できるが、表示されない隠しパラメータも含む。ただし、大きさやグラフィック関連のデータは含まない。
検索方法は戦闘中からシステム画面へ移行した際に各パーツの値段を３２ｂｉｔデータサーチすると得られる。
・ヘッドパーツ
・コアパーツ
・アームパーツ
・ウェポンアームパーツ（種別を含む）
・レッグパーツ（種別・待機ＥＧ・旋回加速度・旋回速度・射撃体勢時加速度及び速度・ダミー移動速度を含む、脚部カテゴリごとに固有となるデータは含まず。）
・ジェネレータパーツ
・ＦＣＳパーツ（各サイトサイズ・各ロック速度を含む ※Ｍロック速度は含まず）
・ブースターパーツ
・武器パーツ各パーツの重量やＥＧなどは戦闘に反映されるため戦闘中の重量をコントロールする場合にはこのデータを変更するのが最も容易な方法。
戦闘中のメモリデータでは再計算された異る扱われ方をするので重量と運動性能の関係を調べる場合にはいったんシステム画面を経由してリセットしたほうがいい。※パーツパラメータは上記の値段を検索キーとして得られるアドレスと分離してパラメータデータ群を形成しているものがある。
例えば射撃武器のパラメータは値段で検索した場合には、値段、重量、最大ＥＧ、等が得られるが、これとは別の場所に
弾ＩＤ、サイトタイプ、戦闘中の名称、弾数、Ｅ消費、弾単価、射程、ロック数、発射間隔、タイプ、攻撃力が一群で格納されている。
（これはＲＦ／Ｅの射程２２０００あたりで検索すれば見つかる）
○機体運動性能データセット（すべて１６ｂｉｔ）
戦闘中に実際に機体運動性能に反映される値群。
検索方法は戦闘中に右手武器残弾のデータサーチ（１６ｂｉｔ）を行い、そのアドレスから「２３２ｂｙｔｅ」さかのぼることで上昇加速度のアドレスを得られる。
機体運動性能データセットは機体構成及び火器管制データセットと並んで配置され、その後に敵のデータセットが同じ順列で配列される。
また、自機上昇加速度のアドレスから２３８Ｂｙｔｅ後方に敵機上昇加速度のアドレスがあり以降自機と同じ配列でデータが配置されている。
・０
・０
・０
・レーダーもしくはレーダーサイト関連の数値１
・レーダーもしくはレーダーサイト関連の数値２
・上昇加速度
・上昇最大速度
・空中水平加速度
・空中水平最大速度
・地上ブースター加速度
・地上ブースター最大速度
・旋回加速度
・旋回最大速度
・射撃体勢時旋回加速度
・射撃体勢時旋回最大速度
・射撃衝撃耐性
・「「 用途不明な値 」」
・０（戦闘中に変化）
・０（戦闘中に変化）
・０（戦闘中に変化）
以下、機体構成データセットへ続く
運動性能データセットは戦闘開始時に生成され、リプレイの際はリセットされて再び生成される。
戦闘中の機体性能データ関連はステージに関わらず同じアドレスに生成される。システム画面では割り当てられている数値は意味をなさない。各数値が実際に有効となる値は
空中の加速度及び最大速度は垂直方向と水平方向で分離しており、相互依存性はないと思われる。
空中水平方向と地上でのブースター速度は相互依存関係にあり、かつＸ軸とｙ軸も相互に依存する。
これらに与えられる数値はおそらく機体構成データセット内の数値と対応して上昇加速度は２倍、上昇最大速度は２００倍、
空中水平加速度および地上ブースト加速度は１４倍、空中水平最大速度及び地上ブースト最大速度は１４０倍の値となる。旋回加速度と旋回最大速度は機体構成データセット内の対応数値よりも低い。
射撃体勢旋回関連は射撃体勢をとる度に機体構成データセットの該当レベルを参照して再生成される。
射撃衝撃耐性は数値が小さくなるほど耐性が強くなり、「ＳＰ−ＳＡＰ」と脚部安定性、有効重量に依存。用途不明な値は有効重量に比例し、機体構成データセットの該当レベルの４倍の値で最低値は“１２８”。
変更しても機体挙動に影響を与えないため用途は不明である。
※ 機体構成データセット内にこれらの数値に対応した“６４”と“５０”を上限とした値（８ｂｉｔ）があるが、その数値は実際の戦闘には反映されない。
○機体構成データセット
機体アセンブル関連、運動性能レベル、エネルギー管理関連、キー設定他。戦闘中に反映されるデータであるが、
運動性能レベル（射撃体勢旋回性能レベルを除く）は書き換えても実際の運動性能には反映されない。
検索方法は戦闘中に右手武器残弾のデータサーチ（１６ｂｉｔ）を行い、そのアドレスから「９８ｂｙｔｅ」さかのぼることで
このデータヘッドのアドレスを得られる。
配列は以下の通り（１６ｂｉｔで示す、８ｂｉｔのものは同じ行で並べてリスト）
・データヘッド（用途不明）
・視点（詳しくは不明、“４４”がデフォルト、“４５”でコクピットビュー）
・常に“０”（８ｂｉｔ），ミッションモード（８ｂｉｔ）
・上昇加速度レベル（８ｂｉｔ），上昇最大速度レベル（８ｂｉｔ）
・空中水平加速度レベル（８ｂｉｔ），空中水平最大速度レベル（８ｂｉｔ）
・地上ブースト加速度レベル（８ｂｉｔ），地上ブースト最大速度レベル（８ｂｉｔ）
・旋回加速度レベル（８ｂｉｔ），旋回最大速度レベル（８ｂｉｔ）
・有効重量レベル（８ｂｉｔ），コア迎撃確率（８ｂｉｔ），
・コア迎撃範囲（８ｂｉｔ），常に“０”（８ｂｉｔ），
・ジェネレータ容量
・ブースト消費
・待機時エネルギー回復速度
・レッドゾーン容量
・稼働時エネルギー回復速度
・ブレード発動時エネルギー消費
・レーダーサイト深度（サイトの範囲。レーダー範囲は運動性能データセット内）
・最大ＡＰ
・実弾ダメージ係数（８ｂｉｔ），エネルギーダメージ係数（８ｂｉｔ）
・機体安定レベル（８ｂｉｔ），ミサイル表示機能（８ｂｉｔ）
・マップタイプ（８ｂｉｔ），レーダーサイトタイプ（８ｂｉｔ）
・常に“０”（８ｂｉｔ），不明値でアセンブルによって変動（８ｂｉｔ）
・ＣＰＵタイプ（８ｂｉｔ），コアパーツＩＤ（８ｂｉｔ）
・レッグパーツＩＤ（８ｂｉｔ），ヘッドパーツＩＤ（８ｂｉｔ）
・アームパーツＩＤ（８ｂｉｔ），ブースターパーツＩＤ（８ｂｉｔ）
・右腕武器ＩＤ（８ｂｉｔ），左肩武器ＩＤ（８ｂｉｔ）
・右肩武器ＩＤ（８ｂｉｔ），ブレードＩＤ（８ｂｉｔ）
・ノイズキャンセラー＆バイオセンサー（パターン代入）
・不明
・不明
・不明
・キーコンフィグ
・キーコンフィグ
・キーコンフィグ
・キーコンフィグ
・キーコンフィグ
・キーコンフィグ
・キーコンフィグ
・キーコンフィグ
・キーコンフィグ
・キーコンフィグ
・キーコンフィグ
・キーコンフィグ
・不明値（脚部アセンブル等で変動）
・不明値（脚部アセンブル等で変動）
・不明値（脚部アセンブル等で変動）
・不明値（脚部アセンブル等で変動）
・不明値（脚部アセンブル等で変動）
・不明値（脚部アセンブル等で変動）
・不明値（脚部アセンブル等で変動）
・不明値（８ｂｉｔ），常に“０”（８ｂｉｔ）
・ブレード関連不明値（８ｂｉｔ），常に“０”（８ｂｉｔ）
・ブレード攻撃力
・ブレード衝撃（８ｂｉｔ），常に“０”（８ｂｉｔ）
・不明値（８ｂｉｔ），
・
・
○火器管制データセット
火器管制データセットはブレードを除く各武器ごとに一連のデータセットを構成しており、右手武器、左肩武器、右肩武器の順に並んでいる。
該当武器を装備していない場合は全て“０”、両肩武器は左肩武器として扱われる。
検索方法は戦闘中に右手武器残弾のデータサーチ（１６ｂｉｔ）を行い、そのアドレスから「１８ｂｙｔｅ」さかのぼることで火器管制データヘッドのアドレスを得られる。
配列は以下の通り（１６ｂｉｔで示す、８ｂｉｔのものは同じ行で並べてリスト）
・データヘッドで常に“０”（８ｂｉｔ），武器パーツの装備数（８ｂｉｔ）
・武器カテゴリＩＤ（８ｂｉｔ），弾ＩＤ（８ｂｉｔ）
・不明値（射出位置などの設定？）
・不明値（射出位置などの設定？）
・不明値
・不明（８ｂｉｔ），射出モード（射撃武器のみ）ｏｒミサイルロック速度（ミサイルの場合のみ）（８ｂｉｔ）
・エイミング動作モード（８ｂｉｔ），リコイルモード（８ｂｉｔ）
・ロックガイドタイプ（８ｂｉｔ），常に“０”（８ｂｉｔ）
・弾数
・残弾数
・エネジードレイン
・ロック距離
・射程距離
・１次ロック 縦角度
・１次ロック 横角度
・２次ロック 縦角度
・２次ロック 横角度
・ロックスピード
・最大ロック数（８ｂｉｔ），リロードタイム（８ｂｉｔ）
・攻撃タイプ（８ｂｉｔ），常に“０”（８ｂｉｔ）
・攻撃力
・衝撃（８ｂｉｔ），不明（８ｂｉｔ）
・以降不明
・
射撃武器の射出モードとミサイルのＭロック速度アドレスを共用しており、射出モードは射出する弾の発射モードや発射数などをコントロールする、
値によってはリロード０も真っ青なトンデモ連射が可能。ミサイルロック速度はどういうわけだかＦＣＳのパラメータにはなく、
戦闘時にこのアドレスに配置されるが、検証した限りではＦＣＳに固有な値をとり他のアセンブルやミサイルの種類などには影響されない。エイミング動作モードはうでや上半身などの動きの種類、リコイルモードは発射時の動きやリコイルの有無の設定。
ガイドタイプやサイトの形状やガイドレールの表示。
エナジードレインは射撃時のエネ消費で実弾系も代入されるが消費しない。
攻撃タイプは実弾系かエネルギー系などのタイプＩＤで、無属性や特殊効果攻撃などもこれに含まれる。
（エネルギー系“３９”、実弾系“２３”、ジャマー“８７”、焼夷“１５１”）
○弾速の検索方法例
弾速の測定は実測でもできますが、パーツの数が多いのでデータから抽出する方法を考えてみました。
いくつか検証してみた結果射撃した直後に弾がまだ消滅していない状態で弾に関するパラメータを変更しても移動中の弾には反映されないことが判ったので、
マップ上に存在する弾それぞれが射撃の瞬間に弾の移動処理や攻撃に関わるデータを持っており、その中に弾速が含まれると仮定してみます。なお実測する場合には、弾は弾速の距離おきにしか表示されないのでリロード“０”にした状態で連射するとちょうど弾速の間隔に弾が並ぶように表示されることが利用できます。
んで、適当な位置に表示されている弾が機体のエンカウントで消える瞬間の位置と一つ前の弾が同じようにエンカウントで消える瞬間の位置の差が弾速になります。
位置は機体座標から抽出するのが簡単です。ただ拡散するタイプの武器は射撃フレームでの飛翔距離も前後に散るため正確に実測できません。ほかには結果論的な測定方法ですが攻撃判定が維持される実際の射程距離が必ず弾速の倍数となるという仕様になっていることから、
市街地あたりで敵を釘づけにして（タンク等の運動性能を０にする）パラメータ射程距離を変更しながら実際ダメージが発生しうる射程距離が変動する境界を探すという方法もあります。
例えばＲＦ／Ｅの実射程が変動する境界が“２１６００”と“１８９００”なので弾速が“２７００”と特定できます。
１箇所境界を調べてリロード０連射で上空などから幾つ弾が表示されているかを確認することでも特定できます。いずれにしても全ての武器を一つづつ調べるのは手間がかかるので、できるだけ検索で絞りこみやすい弾速をもつとおもわれるＲＦ／Ｅの速度を特定して
おおもとのデータ群にアプローチを試みます。
以下はその手順の一例です。
（１）ランカーメイキングで非武装の機体を作成（通常ランカーの弾を撃ちきらせても可）
マップ中で移動処理中の弾のデータを検索により発見することが目的なので、自分の射撃する弾以外がマップ中に存在しないようにします。
ＰＳＡＣではステージによってそれぞれのメモリが割り当てられるアドレスが異るので固定したほうがいいでしょう。
また、ＡＣテストやミッションではデータの配置や弾などの処理行程が対戦ステージとは異っているようなのでオススメできません。
（２）現在の残弾から火器管制データセットを検索し、「攻撃力」を確保。
最も簡単に任意の値を設定できる攻撃力を起点にします。
衝撃は８ｂｉｔなので検索の起点にするには絞り込む余地が少ないのでここでは攻撃力を採用しました。
（３）攻撃力に１６ｂｉｔの個性的な任意の数値（例えば１２３２１）にセット。
検索で絞り込みやすいように他に使われていなさそうな値を代入します。９９９９や１６の倍数などは絞り込みにくいです。
大抵の場合大きい値ほど絞り込みやすいことが多いです。
（４）単発の射撃を行い、弾が消滅する前にセットした攻撃力を検索。マップ中で移動処理中の弾のデータを確保。
結果論ですが弾速はｘｙｚ軸それぞれに分配されて目的のデータ群に格納されています。つまりｘ軸に平行に射撃することで
ｘ軸のみに分配されるため弾速と同じ数値が得られます（最初はデータ群を見つけてから試し撃ちしてデータ構造を調べましたがここでは割愛します）。
ｘ軸に平行に開幕するステージ（多分すべてのステージがそうなっている）で、一切動かずにかつロックせず（ロック距離を“０”に固定しておくと楽）に射撃して、設定した攻撃力を検索します。
以下も結果論ですが、弾の移動処理のデータ群は弾１発づつにそれぞれ割り当てられますが、マップ中に１発しか弾が無い場合には常に同じアドレスに当てられます。
複数の弾があると後ろへ団子のようにつながって割り当てられていきますが、１発目が消滅すればその後に撃った弾がその場所に割り当てられます。
したがって、敵弾があると目的のアドレスが占有されてしまうので注意が必要です。
またこの結果、一回の検索で目標が絞り込めない場合には攻撃力を変えて繰り返すことで絞り込みが可能です。参考までにＭＡでの対象のデータ群の構造は以下の通り（全て１６ｂｉｔ）です。弾速付近以外は細かく調べていません。
・
・
・弾寿命（ｆ）
・不明
・不明
・攻撃力
・衝撃
・カテゴリ内ＩＤ
・不明
・ｘ軸速度
・ｚ軸速度（ｘ軸速度）
・ｙ軸速度（ｚ軸速度）
・（ｙ軸速度）
・
・前後に描画関連のデータ群があります。
各軸速度はどういうわけか精密予測武器及び肩キャノンは１６ｂｉｔ下流へずれて代入されています（カッコ）。
※ほかには弾速の遅いものを選んで前述したタイマーと弾寿命（１ｆに１減少する）を起点に検索する方法もあります。
※余談ですがブレード光波の移動処理もにたような構造のデータを当てられる（アドレスは射撃武器とは異る）ているので
同じような手順で検索できますが、ＬＳ−１０００Ｗの空中攻撃力はしっかり設定値の３倍になっています。
（５）移動処理中の弾のデータ内から弾速を抜き出す。
ｘ軸に平行に射撃できている場合にはｘ軸速度が弾速とほぼ同等と考えてかまいません。場合によっては他の軸速度に僅かに分配されてしまい
どうしても１〜２程度ずれてしまう場合もあるかと思いますが、この手のパラメータは多くの場合きりのいい数値か１６の倍数等の値となっていることが多いです。
たとえば“８９８”だったら“８９６”か“９００”の可能性が濃厚でしょう。“４４８”であれば１６の倍数なのでそのままが正しいと思われます。そして全てのパーツを一つづつ調べるのは手間がかかるし、拡散タイプはランダムに分配されてしまうので正確な弾速が得られず、
弾速の他にも有用なパラメータが一群をなしているという期待もあるので参照もとのデータを調べるべく絞り込み検索に有利なできるだけ弾速の速いＲＦ／Ｅの弾速を抽出します。
（６）システム画面から戦闘画面で変化したアドレスから任意の弾速を検索
システム画面では弾速はメモリ上に割り当てられていないため、そこから戦闘画面へ移行した後にＲＦ／Ｅの弾速“２７００”に変化したアドレスを検索します。
ゲーム開始前からの変化で検索してもある程度絞り込めますが件数がだいぶ増加してしまう場合があります。ＰＳＡＣの場合は幸い“２７００”という数値は数個しかヒットしないので楽に特定できます。“９００”などは結構多いので
数十件ヒットしてしまいます（弾速のあとは散開角度０が入るので３２ビットで検索すると数個になります）が、その検索結果内に目的のアドレスがあるかどうかはそれを変更して射撃すれば判ります。
極端には検索結果を一括して例えば“１００”にしてしまって該当武器を射撃して弾速が遅くなればその中に必ずあるということになりますが、
残念ながら値を変更するとクラッシュしてしまう場合があり、弾速のデータ付近に他にどんな値があるかも事前に判っていないため
特定するにはある程度しらみつぶし的な作業が必要になります。もしクラッシュしないようなら１回の操作で対象を１／２に減らせるので楽に見つけることができます。
（７）イモヅル式に発見。
対象の弾速がみつかれば他のパーツの弾速はその一群の中にデータセットを形成して順番に配置されています。
大抵の場合には同じような構造と考えていいと思います。ＰＳＡＣでは弾ＩＤという形で順列を暗に示してくれているので比較的容易に他の弾速を特定することができます。
確証はありませんが別シリーズでも似たような手順で弾速を調べることができると思います。
○弾グラフィック関連のデータセット及び配列。
武器関連のデータの扱い。
（１）ガレージでの武器アセンブル。設定されているパラメータは攻略本とほとんど同じ。
戦闘に移行する際にこのデータと各パーツパラメータ及びＣＤを参照してそれぞれのデータセットが生成される。
（２）機体構成データセットの武器。（戦闘中は変更しても反映せず）
（３）火器管制データセット。弾ＩＤ及び各武器の設定（上記の火器管制データセットを参照）
（４）機体挙動関連のアセンブルデータ。（アドレス不明のため未調査）
（５）個別の武器データ関連。弾ＩＤから系列ごとのデータを参照。
例えば弾ＩＤ“２５”の場合には２０系データセット内の５番目に配列されたデータセットを参照。
暫定的に弾ＩＤと表現しているが実際には火器管制データセットで設定されているのは「武器ＩＤ」でその武器ＩＤが実際の弾データを参照している構造になっている。
射撃武器の場合には武器ＩＤと弾ＩＤに順列の違いが無いため同じものとして説明できるが、ミサイルの場合には順列が異るので注意。（詳しくは未調査）
（６）弾系列ごとのデータセット。各弾の描画関連のデータが戦闘に移行する際に生成される。弾速、拡散角度、色、グラフィック種別、爆風ＩＤ等。
（７）各弾ＩＤが参照する爆風関連のデータ。爆風タイプ・継続時間・初期爆縮サイズ・速度・周期・威力減衰・エフェクト関連他。
（８）（６）の参照する描画関連のデータ。（構造が不明なため未調査）
以上のように各武器のパラメータは参照先が細かく分岐しており、調べても意味のないものや構造が不明のものが多いので（３）と（６）で十分。
（６）〜（８）のデータセットは不明なデータ群や０の羅列を挟んで一群をなしており配列は以下のとおり
・０の羅列
・不明なデータ群
・「「０系」」
・不明なデータ群
・「「キャノン」」（チェーンガン・実グレ・Ｅグレ及び敵専用？、他の弾は２０系〜６０系に配置）
・描画関連（この辺は変更すると弾や爆風の描画がにバグる）
・０の羅列
・描画関連
・０の羅列
・描画関連
・０の羅列
・不明なデータ
・「「６０系」」
・０の羅列
・「「９０系・７０系」」
・０の羅列
・「「２０系」」
・０の羅列
・不明なデータ
・「「４０系」」
・０の羅列
・不明なデータ群
・「「ミサイル」」
・「「爆風」」
・０の羅列
・「「機体データ」」（機体構成データセットとほとんど同じ構造、変更しても戦闘中には反映しないが未調査）
・０の羅列
不明なデータ群や描画関連は調べてない。
そしてそれぞれのデータセットの検索方法は以下の通り
○０系データセット
精密射撃武器のみ他の系列とはやや離れた位置に配列されており、前後に構造不明なデータ群を持つ。
戦闘移行後に３２ｂｉｔで“８３２３７７２”をデータサーチ、１６ｂｉｔに変換した“７００”“１２７”が０系の二番目ＩＤ１（ＭＧＡ１）の弾速及び拡散角度（０系先頭は拡散角度が０のため３２ｂｉｔでは７００で検索することになりヒット数が多すぎるので）。
０系の配列データ長は弾一種類につき“２８Ｂｙｔｅ”で連続配置されている。
○２０系データセット
戦闘移行後に３２ｂｉｔで“２５１０１００８”をデータサーチ、１６ｂｉｔに変換した“７２０”“３８３”が２０系の三番目ＩＤ２２（ＨＧ１等）の弾速及び拡散角度（２０系先頭は拡散角度が０のため３２ｂｉｔでは８００で検索することになりヒット数が多すぎるので）。
２０系の配列データ長は弾一種類につき“４０Ｂｙｔｅ”で連続配置されている。
○４０系データセット
戦闘移行後に３２ｂｉｔで“７８６４７６８”をデータサーチ、１６ｂｉｔに変換した“４４８”が４０系先頭のＩＤ４０（Ｓロケ等）の弾速。
４０系の配列データ長は弾一種類につき“３６Ｂｙｔｅ”で連続配置されている。
データ配列には拡散角度を含まない、また弾速から弾速アドレスから“２３Ｂｙｔｅ”の位置に爆風ＩＤ（８ｂｉｔ）がある。他は調べていない。
○６０系データセット
戦闘移行後に３２ｂｉｔで“２０９８０５２”をデータサーチ、１６ｂｉｔに変換した“９００”“３２”が６０系三番目のＩＤ６２（ＸＣ６５）の弾速及び拡散角度（６０系先頭は拡散角度が０のため３２ｂｉｔでは９００で検索することになりヒット数が多すぎるので）。
６０系の配列データ長は弾一種類につき“２４Ｂｙｔｅ”で連続配置されている。データ構造（１６ｂｉｔ）
・弾速
・散開角度
・弾グラフィック幅
・弾グラフィック種別
・不明
・“０”
・不明
・不明
・Ｒレッド値（８ｂｉｔ），Ｇグリーン値（８ｂｉｔ）
・Ｂブルー値（８ｂｉｔ），常に“０”（８ｂｉｔ），
・不明
・不明
不明値は調べていない
○７０系・９０系データセット
戦闘移行後に３２ｂｉｔで“４１９４３７４”をデータサーチ、１６ｂｉｔに変換した“７０”“６４”が７０系先頭のＩＤ７０（爆雷）の射出速度及び不明値。
７０系の配列データ長は弾一種類につき“２８Ｂｙｔｅ”で連続配置されている（３パーツ分）。
９０系のアドレスは上記ＩＤ７０の射出速度から“４４Ｂｙｔｅ”前方、値“２００”はＩＤ９０（機雷）の射出速度。
９０系の配列データ長は弾一種類につき“２２Ｂｙｔｅ”で連続配置されている（２パーツ分）。９０系配列
・初速
・加速度（※負の値をとる）
・判定サイズ
・振幅
・爆風ＩＤ（８ｂｉｔ），常に“０”（８ｂｉｔ）
・寿命
・判定発生カウンタ
・ｘサイズ
・ｚサイズ
・ｙサイズ
爆雷データは操作して分かりやすく反映できる値が多いので結構面白い。
初速は発射速度、加速度は初速から各フレームで加速する値で実際には減速するためマイナスの値をもつ。（２５４，２５５）で“ー１”けっこう無理やりっぽい。
判定サイズは確証はないが恐らく円柱。振幅は上下垂直運動の幅のようだ。爆風ＩＤは８ｂｉｔ。
寿命は発射から自動爆破までの時間（ｆ）、判定発生カウンタは射出後にエンカウント判定を開始するまでの時間（ｆ）。
サイズは各成分で単位は不明、元の値はそれぞれ“１２８０”おそらく移動処理をするために速度値の単位に換算してある。つまり距離の６４倍。
２パーツ目は敵専用爆雷。
７０系配列
・初速
・不明
・寿命
・発射数
・散開角度
・不明
・Ｒレッド値（８ｂｉｔ），Ｇグリーン値（８ｂｉｔ）
・Ｂブルー値（８ｂｉｔ），爆風ＩＤ（８ｂｉｔ），
・０
・以下着弾エフェクト
○キャノンデータセット
戦闘移行後に３２ｂｉｔで“２０９７６５２”をデータサーチ、１６ｂｉｔに変換した“５００”“３２”が肩キャノン系先頭のＩＤ０（ＣＮ３５）の射出速度及び発射反動。
尚、検索で同値が複数ヒットするがほとんど一連のデータ群。
肩キャノン系の配列データ長は弾一種類につき“６Ｂｙｔｅ”で連続配置されており、弾グラフィック関連は他の系列に分散配置されている。
・弾速（１６ｂｉｔ）
・発射反動（１６ｂｉｔ）
・連射フラグ（８ｂｉｔ、“０”で連射不可、“１”で連射可）
・不明値（８ｂｉｔ、ＧＮ２３０のみ固有値をもつ）
○ミサイルデータセット
戦闘移行後に３２ｂｉｔで“３９３２２１０”をデータサーチ、１６ｂｉｔに変換すると“５０”“６０”となる。それぞれミサイルＩＤ１（小ミサ）の推進寿命と弾薬寿命。
ミサイルのみ火器管制データセットに設定された弾ＩＤとは順列が異る。実際には火器管制データのＩＤが個別武器関連のデータセットを参照し
そこからさらにミサイルデータセットを参照するという構造になっている。火器管制データセットでは参照先のＩＤ指定のみ、
武器関連のデータセットで射出角度や初速等の設定していると推測され（未調査）、このミサイルデータセットで弾頭の運動性能や描画関連のデータを配置している。
配列データ長はミサイル一種類につき“４０Ｂｙｔｅ”で連続配置されている。
ミサイルデータセットの構造
・推進寿命（１６ｂｉｔ）
・弾薬寿命（１６ｂｉｔ）
・尾グラフィック種類（１６ｂｉｔ）
・尾グラフィック太さ（１６ｂｉｔ）
・弾グラフィック種類（１６ｂｉｔ）
・弾頭推進光（１６ｂｉｔ）
・加速度（１６ｂｉｔ）
・最大速度（１６ｂｉｔ）
・旋回速度（１６ｂｉｔ）
・以降描画関連（色・エフェクト等）
・
推進寿命は弾頭が推進できる限界時間で単位はフレーム。寿命後は自由落下する。落下中もエンカウント判定を維持する。
弾薬寿命は推進開始から自爆までの時間。推進寿命より短い場合には推進中に自爆、長い場合には自由落下中に自爆する。
尾グラフィックの種類はおそらくテクスチャの指定。
尾グラフィックの太さは幅のみの指定。もともと立体ではなく平面。
弾グラフィックの種類は弾頭の形状指定。別に生成されているグラフィックデータの参照先と思われる。
弾頭推進光は弾頭後部のブースターの発光の強さ。したがって推進中のみ適用される。
加速度はフレームごとに弾頭の向いている方向に加速される値。尾の長さはこの値に比例する。
余談だが推進寿命末期には推進煙が弱くなり瞬きながらきえてゆく。加速度が実際に弱くなっているかは不明。
最大速度は弾頭速度の上限値。水平と垂直方向の速度は独立しているかは未確認。
旋回速度はフレームごとに弾頭が旋回できる最大の角度。単位は内部角度で“５１２”で実際の４５°に相当する。
また現在位置ではなく予測位置へ旋回する、これは弾頭の速度を極端に遅くすると移動目標のはるか前方へ旋回することでも確認できる。
なお、推進末期は旋回しなくなると思われる（未確認）。
描画関連はエフェクトの種類やその色。色の指定はＲＧＢごとに８ｂｉｔ（上限２５５）で指定。
爆風ＩＤは参照する爆風データセットの配列順のＩＤ。
○爆風データセット
戦闘移行後に３２ｂｉｔで“６５５７４９０”をデータサーチ、１６ｂｉｔに変換すると“３８９０”“１００”となる。
この“３８９０”が爆風ＩＤ１（光波ブレ等）のヘッダで８ｂｉｔに変換して“５０（爆風タイプ）”“１５（継続時間）”。
爆風は各弾データのグラフィック種が個別に参照しているデータで、爆風の処理関連のパラメータが格納されている。
配列データ長は爆風一種類につき“４６Ｂｙｔｅ”で連続配置されている。
爆風データセットの配列（詳しくは調査していない）
・爆風タイプ（８ｂｉｔ）
・継続時間（８ｂｉｔ）
・爆縮開始サイズ（１６ｂｉｔ）
・爆風速度（１６ｂｉｔ）
・周期速度（３２ｂｉｔ）
・威力減衰値（１６ｂｉｔ）
・威力減衰値（１６ｂｉｔ）
・以降描画エフェクト関連
爆風タイプは詳細不明、ほとんどの爆風が“５０”に設定されているが設定例のない数値にすると着弾と同時にフリーズするので
おそらくなんらかのＩＤ（ＩＤ関連は参照先が存在しないとフリーズする）。
継続時間は爆風が発生している時間で単位はフレーム。
爆縮開始サイズは爆風発生時の爆風球体の初期サイズで単位は不明。ここからいったん爆縮し半径が０に達すると膨張へ転ずる。
爆風速度は発生直後の爆風の初速で単位は不明（弾速などとは異る単位）。
爆風の速度は最終的に周期速度に収束するため発生直後の爆風の爆縮膨張速度に関係する。したがって爆風速度が早いほど結果的に爆風半径は大きくなる。
周期速度は爆風が膨張と収縮を繰り返す周期で単位は不明。値と周期は反比例しており大きいほど周期速度が遅くなり、
設定されている継続時間の間この周期にしたがって膨張と収縮を繰り返す。したがって周期速度が早いと結果的に爆風半径は小さくなり遅いと半径が大きくなる。
威力減衰値は詳しくは不明。係数なのか種類設定なのかも解っていない。値によっては攻撃力が０の弾でも爆風の１撃であらゆる機体を撃破する。
爆風関連のデータの調査は爆風半径を調べることを目的としていて、設定値が距離に換算できないことがわかったので詳しくは調査していない。
したがって一部で説明されている爆風レベルというパラメータは存在せず、距離という単位で説明できない。
○戦況関連データセット
戦闘中にＡＰ、安定性、機体座標、速度値、機体サイズなどが格納されているメモリ周辺のデータ配置。
検索は現在ＡＰで探す場合はモニタ表示数値の４倍、天井が高いステージであれば空中から落下して
最大速度に達したあたりで最大落下速度“９６００”をキーワードに。
なお、垂直方向には速度振幅はないが水平方向には速度に振幅が発生するので注意。
バイト値はデータ同士の間隔、間は不明なので省略。あとに続いてＣＰＵもしくは２Ｐ機、構造は同じ。
データの配列は以下のとおり（すべて１６ｂｉｔ）。間のものは詳しく調べていないがいろいろ発掘できるかも、適当に代入すると空中で宙返りしたりロック状態が変わったりする。
つまりプログラム状はＡＣは横になることができるらしい。
・機ｙ座標
・機ｚ座標
・機ｘ座標
・０
・０
・旋回角度
＋２２ｂｙｔｅ
・機体実半径
・機体実全高
＋２６ｂｙｔｅ
・常に“０”？（８ｂｉｔ），動作ＩＤ（８ｂｉｔ）
・動作関連 不明（８ｂｉｔ），常に“０”？（８ｂｉｔ）
＋４４ｂｙｔｅ
・機体被弾半径
・機体被弾半径
・動作カウンタ
・動作関連不明知（動作カウンタ稼働時と空中で“１”それ以外で“０”他不明）
＋９２ｂｙｔｅ
・ｙ軸速度
・ｚ軸速度
・ｘ軸速度
・硬直カウンタ
＋１４２ｂｙｔｅ
・現在ＡＰ
・最大ＡＰ
・機体安定性
・
続ＣＰＵデータ
座標軸はｘ軸が北、ｙ軸が東方向が正の値となる水平方向、ｚ軸は下向きが正の値となる垂直方向。座標は水平が機体中心、垂直が円柱底面（接地時は“ー１”）。
速度と同じ扱いをうけるものに下にある速度値以外に、この座標が１ｆ間に変化した量をモニタしているらしい。二脚系通常歩行からのブースト適用時はそこから速度値に換算される。
また衝撃加速度と被弾側の機体の挙動の相互関係は速度値ではなく座標の変移になっている（ブレード衝撃で確認）。
旋回角度はｘ軸正方向（北）が０、一周で４０９６、直角で１０２４。
機体実サイズは戦闘中変化しない。ブレードホーミングの追跡起点がこの円柱の中心。大きくすると二脚系でも着地せずに連続へにょ可能。
また、各機体の限界速度の元データとなっており戦闘中にこれを変更すると限界速度が増大する。解析時の速度調整にはこれが便利。
地形や障害物とのエンカウントはこちら。
動作ＩＤは現在の動作状態を格納するアドレス。通常歩行やブースト、着地硬直、ジャンプ予備動作などなど。
動作関連は調べていない。多分動作ＩＤの補助的な役割。
機体被弾サイズは開幕時は機体実サイズと同じ、開幕後移動などを行うと運動特性マニで示した数値に変化、それ以降は二脚系の射撃姿勢を除いて変化せず。
射撃、ミサイルの予測基準。機体同士のエンカウントはこちら。動作カウンタは規定動作の際に０からカウント、動作終了後０に戻る。つまりカウンタを監視すると動作の要求時間がわかる。
通常歩行、着地硬直、ジャンプ予備動作、ブレホ、地上ブレードなど。
動作関連不明値は上記の動作カウンタ稼働時に１が代入されるが空中でも１で、地上や停止時は０。不明。
速度は運動性能値の加速度にしたがって与えられる速度値のアドレス。ここに速度を代入すると次のフレームでその数値にしたがって座標が変わる。
入力後２ｆにこのアドレスに数値が代入される。したがって入力・代入・反映という手順をとるので速度が関わる処理は操作から
反映までに２ｆある（入力ｆは厳密には前のｆで入力操作でついで受理となるので、ただし連続動作が可能なものは入力ｆが前動作の最後のｆになるので１ｆスキップされるっぽい）。
あたりまえだけどこれが最短だよね。どうして内部タイマーから２ｆ遅れるのかきがつかなかったね。
旋回速度独立したアドレスではなく各絶対軸に一定の割合の数値を配分しているようだ。ｘ軸速度とｙ軸速度に旋回速度値を加算して代入し、
垂直速度に同旋回速度値の１／６を代入？。なんでこれで旋回と移動が競合しないんだ？
硬直カウンタは着弾した瞬間に算出された硬直時間が代入されカウントダウン。最大５で０になったフレームで硬直が解除される。
二脚系も算出される数字が代入されるが、地上にいると１ｆ後に０にリセットされる。
ＡＰはモニタ表示の４倍。４おきにしか数値をとらない。誤差のときは４の倍数以外とも思ったが違った。最大ＡＰはレッドシグナルに関係するかな？
機体安定性に代入される数値は６．２５きで最大１５９３だけど任意の数値でも反映されるため衝撃２５５まで無効化できる。０で完全無効化。