獣戦機隊が初登場するシナリオで合流前にシナリオをクリアしてしまうと、いきなりダンクーガに合体した状態で自軍に参入する通称「ダンクーガバグ」はご存知の方が多いと思います。この手のサイトを調べている方々は既に知っている知識ではないかと思いますが、この原因は「獣戦機隊が味方増援として登場するイベント発生時にイベントフラグ00E1を立てて合体不能にしているが、増援イベント前にシナリオクリアしてしまうとこのフラグを立てる処理が成立しない」という部分にあります。本来であればこういう重要なフラグはシナリオ開始時の1ターン目、または戦闘マップに入る前のブリーフィング中にでもイベントフラグ00E1を立てる処理を入れておくべきだと思うのですが…。  これを避けるにはバイナリ改造以外の手段では結局のところ獣戦機隊が登場するイベント発生を待つしかなく、また、こうした味方増援関連のイベントに関してはマップ上イベントで処理をしている場合とシナリオ開始時に処理をしている場合の二通りがあり、これは担当されたプログラマーの方それぞれ（恐らく複数人で作業されたと思いますので）の癖が出ているのかもしれません。イベント関連のデータを修正する際や自作シナリオを組み立てる際には、こうした部分をある程度統一した形にしておくと管理が楽なのではないかと思います。

 チャムやリリスなどの妖精、複数乗り機体のサブパイロットの精神ポイント（以下、SP）は一般パイロットとは別枠のWRAM領域で管理されており、この仕様領域は常に固定です。また、サブパイロットとメインパイロットの両方の扱いを受ける分離・変形機体のパイロット（=ゲッターチーム、ザンボットチーム、獣戦機隊、コンバトラーチーム）はそれぞれメインパイロットの時には通常パイロット用のSP管理領域を、サブパイロットの時にはサブパイロット用のSP管理領域を使用するという面白い仕組みになっています。また、スーパーガンダムや各種地球製スペイザーと合体した状態のグレンダイザーのサブパイロットのSPはサブパイロット用のSP管理領域を使用せず、通常パイロット用のSP管理領域を使用します。なお、WRAMの使用量を節約する目的なのかサブパイロット用のSP管理領域には最大SPを管理するという概念が存在しないようで、各マップでそのサブパイロットが最初に精神コマンドのウィンドウを開く際に「該当するサブパイロットIDとレベルから最大SPを算出しつつ現在SPを書き込む」という手法が採用されています（通常のパイロットは7E18E5で現在SP値を、7E18E6で最大SP値を管理しています）。それまではFF（255）の固定値となっており、精神コマンドウィンドウを開くまではこの数値は変動しません。WRAMにおけるサブパイロットの固定SP管理領域は以下の通りとなっています。 7E153D サブパイロットの現在SP値（チャム） 7E153E サブパイロットの現在SP値（エル） 7E153F サブパイロットの現在SP値（ベル） 7E1540 サブパイロットの現在SP値（リリス） 7E1541 サブパイロットの現在SP値（シルキー） 7E1542 サブパイロットの現在SP値（メリー） 7E1543 サブパイロットの現在SP値（竜馬） 7E1544 サブパイロットの現在SP値（隼人） 7E1545 サブパイロットの現在SP値（弁慶） 7E1546 サブパイロットの現在SP値（レミー） 7E1547 サブパイロットの現在SP値（キリー） 7E1548 サブパイロットの現在SP値（宇宙太） 7E1549 サブパイロットの現在SP値（恵子） 7E154A サブパイロッ...

 前回は搭乗フラグ設定の解析と変更について論じてきましたが、色々と推論を立てて関連するサブルーチンを書き換えてみたところ、ようやくSRAMの65人目以降に登録されたパイロットがマップ上に表示されるようになりました。これで何とかパイロットや機体のいわゆる「64体の壁」は突破できたのですが、SRAMに記録されるデータはともかくWRAMに読み書きされる各種データの拡張に関して依然不具合が残っています。これは以前にも触れた話ですが、マップ上では出撃している自軍と敵軍の合計64体までをチェックすればいい反面、出撃準備画面では拡張した65体目以降のパイロットや機体のデータをWRAM上で展開できるようにしなければならないのです。  セーブデータに使用される通常SRAM領域の確保の問題に関しては、既に限界反応の領域を使用した武器一括改造システムを導入すれば副産物として空き領域となった武器改造値記憶部分を転用する事で80体、または96体のパイロットと機体を登録・確保する事ができるという事が判明していますので、出撃準備画面でパイロットや機体のデータを閲覧したり強化パーツの付け替え、機体の乗り換えなどをしなければ問題ないのですが、とはいえいくら何でもそんな事は不可能なのでこれを解決しなければなりません。  WRAMの領域は大きくないためあまり大掛かりな構成変更はできず、またWRAMの代わりに追加SRAM領域を使用すると中断データが正常に使えなくなってしまうという弊害が生まれます。その点を鑑みるとやはり変更するのであれば出撃準備画面で各種データを処理する際に使用するWRAMを拡張SRAM領域に肩代わりさせるしかなさそうです。問題はSRAMの拡張を行って追加領域でデータを処理する場合、そのプログラムが実機できちんと作動してくれるかどうかですね。  とりあえず今回作成しているパッチ（仮に「シナリオ分岐補完パッチ」とでも呼んでおきます）ではむやみに新たなシステムは採用せず、既に完成しているゲッターチーム、コンバトラーチーム、獣戦機隊、ザンボットチームの仕様変更システムでパイロットと機体の登録数の11体分削減が実現できていますので、これを活用してやりくりしていくつもりです。今のところ他にやりたい事と言えば、エレとシーラの二人を両方とも救出してそれぞれのルートで...

 パイロットがどの機体に乗っているかどうかについてはパイロット側のデータではなく機体側のデータで管理しているのですが、この管理方法がやや特殊（パイロットのSRAM登録番号の倍数+フラグ管理用に80hが加算されるという仕組み）のため、そのままではSRAMへ登録できるパイロット数を65人以上にできません。仮にフラグ管理用の数値を60hにできれば理論上は80人まで、40hにできれば理論上は96人までパイロットを登録できるので、これが実現できるのであれば何とかしたいところです。  そこでこれを実現するために少し解析をしてみたところ、機体にパイロットが搭乗している状態を示す数値である「80」を変更する事自体は可能になりました。しかしこれを「60」や「40」に変えてしまうと機体に搭乗しているパイロットがマップ上に出撃・配置できなくなってしまう（敗北条件になるパイロットが配置されない場合は即ゲームオーバーになります）という不具合が発生してしまいました。まだ詳細について解析していないのですが、マップ上に配置される機体の搭乗フラグだけでなく配置判定に必要なフラグの設定も一緒に変更しないと出撃させても配置されないようなのです。あまり有用な解析ではないかもしれませんが、パイロットの登録人数や機体の保持数を64体以上に増やせれば強制廃棄イベントを少しでも減らせますので、折を見てこの処理についてもより詳細に解析していきたいところです。