あまり知られていない不具合ですが、SFC版第3次スーパーロボット大戦のガザC（MS形態）のユニットグラフィックはよく見ると上の写真のように左足（足を交差させている可能性があるので本当は右足かもしれませんが）の踵が欠けてしまっています。これはEXのディアブロのように画像データが壊れているのではなく、画像データを表示させるためのタイルデータのサイズ指定ミス（タイルNo.0Eの16x16サイズ表示指定の部分が8x8サイズ表示指定になっている）によるものなので、これを正常な状態に表示できるように修正してみました。これによる「本来の」ガザCのグラフィックは、以下の写真のようになります。  そんなに変わっていないようにも見えますが、よく見比べてみると左バインダーの下側に踵のようなものが表示されるようになっているのが確認できると思います。調べてみたところ、どうやら当時のSDガンダム関連商品で使用されたイラストが元になっているらしく、伝説のRPG「ガイアセイバー」のガザCもほぼ同じような感じのポーズでした。SDガンダム世代ではないのでこの辺り事情には詳しくないのですが、きっとデザイン料を浮かせるためにバンダイの各関連企業で同じ原画を使い回していたのでしょうね。需要があるかどうか分かりませんが、グラフィック修正用のパッチを作成しました。以下のURLからダウンロード可能です。元々のソフトに存在するバグなのでパスワードは設定していません。 https://ux.getuploader.com/retrogamelaboratory/download/51  第3次に関してはこれから大々的に調査する予定はありませんが、今回の調査でEXと同じ手順を踏めば各種グラフィックやパレット、タイルパターンなどの変更・追加ができる事が判明しましたので、気が向いたら機体やパイロットの追加、シナリオのイベントコードの調査などを実施するかもしれません。容量や仕様的には正直なところ第2次Gをどうこうするよりも簡単だと思いますので、時間に余裕があればシナリオ上では真のルートとされるクワトロ加入→ガトー救助→月面ルートでNPCとしてアクシズで登場するに留まるメキボスとグレイターキンを正式に自軍ユニットとして使用できるように変更したり、アフリカルートで鉄甲鬼を説得して仲間に加えるイベント...

 お待たせしました。「BGMパイロット基準化パッチ」に「BGM継続パッチ」の機能を付与したパッチを公開しました。戦闘BGMのID判定を第4次S以降のスタンダードとなったパイロット基準に変更しつつ、機体BGMのID設定が12以上の場合はボス属性と判定して機体に設定されたBGMを優先して再生します（パイロットのBGM設定IDが12以上だった場合は通常の判定を行います）。また、戦闘終了後もマップ上でBGMが流れ続け、次の戦闘BGMが前回の戦闘BGMと同じIDであればそのままBGMが切り替わらずに継続します。以下のURLからダウンロード可能です。 https://ux.getuploader.com/retrogamelaboratory/download/87  テストプレイでは特に不具合はありませんでしたが、「パイロットBGMの優先順位は常に青軍（NPC含む）→その他の色の軍」、「赤軍と黄軍が戦闘する場合は機体BGMがボス属性でない限り必ず先攻側のパイロットのBGMが流れる」、「機体のBGM設定が12以上（ボス属性）の場合は常に上位ID側の機体BGMが再生される」という三点が気になる方はご利用をお控え下さい。ファイル解凍のパスワードは「c+p*yTe(&|9Bn5)a」です。

 竜馬・隼人・弁慶の仕様変更の際に調査したのは「特定の機体に乗っているパイロットの一時IDを強制的に変更する事は可能か」というものでしたが、逆に「特定のパイロットが搭乗している場合にのみ機体の一時IDを強制的に変更する」という作業ができないかどうか調査してみました。結論から言えば可能です。例えば、特定のイベントをこなした後のカミーユがZガンダムに搭乗している場合にのみマップ上で機体IDを通常のZガンダムからウェイブライダー突撃やハイパー化ビームサーベルを搭載した機体（ハイパーZガンダム）に変更したり、シーブックがF91に搭乗していて気力が130以上ある場合のみ分身攻撃や物理分身が可能な別ユニットのF91（フルスペックモードF91）に差し替えるなんて事も割と簡単に実現できます。ただし、この要素を入れても一部のガンダム系のパイロットと機体を優遇するだけになってしまいますので、絵面でのインパクトはあるかもしれませんが実装するかどうかは微妙なところです。そもそもこの時期のウィンキースパロボはガンダム系がかなり優遇されていますので、やはりこれ以上ガンダム系を優遇するよりも各種スーパーロボットが活躍できる要素を優先する方がやや有意義な気がします。作業自体は決して高い難易度ではありませんので、この辺りのアイデアの導入の可否は、バランスを考慮しながらの調整になるでしょう。

 第4次スーパーロボット大戦では実体剣や銃火器のグラフィック表示が「機体毎に予め設定された別途グラフィックを呼び出して所定の位置に武器を表示させる」という仕組みになっている（スーパーロボット大戦FではPCのゲームのように機体のグラフィックファイルの後ろに連番の紐付け画像ファイルを設定する事で対応しています） の ですが、この仕様ですとこれ以上グラフィックを追加する事ができません。そこで、断空剣の仕様を参考に写真のような「機体のグラフィックのスプライトシートに武器のグラフィック（ビルトラプターなのでコールドメタル・ナイフを用意してみました）を混在させておき、所定の攻撃の際に武器を持たせる」という追加アニメーションスクリプトを作成しました。武器グラフィックを呼び出した後は従来の実体剣アニメーションと同じように敵機に接近し、斬撃を繰り出します。  この方式にする事でパレットデータは機体のパレットをそのまま使用可能になり、グラフィックサイズの小さな機体であればスプライトシートの工夫次第で複数の武器を書き込む事もできそうです。例えばゲッター1やダイモス、ハイパーライネックなどの武器グラフィックが存在しない機体のスプライトシートにゲッタートマホークや双竜剣やオーラソードのグラフィックを書き込み、スクリプト中のアニメーション設定で共通のタイルパターンによる表示を設定しておけば一つのスクリプトで複数の機体に武器を表示可能となる寸法です。問題点は使用するタイルパターンと機体グラフィックの位置関係、そして既存の機体にこれを適用するには一旦スプライトシートを取り出して再配置する必要があるという事です。そうなると一番大きな機体のグラフィックに基準を合わせてタイルパターンを作る必要があり、不自然にならないような持たせ位置を何度も確認する必要があるのが悩みどころです。時間はかかりますが、少しづつ作業を進めていく予定です。

 いずれもゲーム進行には影響がないものの、数点の武器アニメーションで確認できるバグや不具合を修正するパッチを公開しました。初期ROM、後期ROMの両方で使用可能です。以下のURLからダウンロード可能です。元から存在する不具合のため、今回はパスワードは設定していません。 https://ux.getuploader.com/retrogamelaboratory/download/73  修正できる内容は以下の通りですが、普通にプレイしていれば特に気にならないものばかりです。 実体剣で切り払いが発生すると、切り払われる側の実体剣の画像が乱れる。 先攻側の断空剣が回避されると、後攻側の武器のSEが再生される。 計都羅睺剣で切り払いが発生すると、発生後の剣の表示位置がおかしくなる。 ドリルテンペスト使用時に、被攻撃側の背景画像が攻撃側の背景画像になる。  実体剣の切り払いバグと断空剣のSEバグは特定の条件下（実体剣バグは大型の実体剣の場合のみ、断空剣バグは破壊光線やファンネルなど特定の武器と重なる場合のみ）で発生するので、あまりバグを修正する意味はないかもしれませんが、よろしければご利用下さい。

 発売から今に至るまで特に話題になっているものではないのですが、第4次スーパーロボット大戦のダンクーガの断空剣のアニメーションには「後攻側が破壊光線やファンネルなどの武器を選択している場合、先攻側の断空剣が回避されるとSEがおかしくなる不具合」というものがあります。先攻側の断空剣による攻撃を回避されると、後攻側の攻撃アニメが開始されるまでは破壊光線のSEを少し高くしたようなノイズ音が鳴り続けますが、フリーズするような事はなく普通にゲームは続行されます。どうやら原因はSEに使っているチャンネルのオーバーフローによるものらしく、リザーブ中の後攻側の武器のSEと相手に近づく際の移動SEに使用する波形データが被ってしまっているようです。ビームサーベルや格闘などの他の接近戦用武器アニメーションでは後攻側の画面に切り替わる際に移動SEを消しているのですが、どういう訳か断空剣の場合は移動SEの消去命令が存在しない作りになっています（迫力を出したかったのではなく、単純なスクリプト記述ミスの可能性が高そうです）ので、画面が切り替わる際に移動SEを消去するスクリプトを追加すればこの不具合は解決できると思います。

   少々時間がかかりましたが、予定通りリアル系の主人公の機体をビルトラプターに差し替えました。これもジガンスクードと同様、当初はできれば時間節約のためGBA版OGのグラフィックをそのまま流用したかったのですがサイズが大きかったり色合いが第4次の既存の機体の画像の雰囲気に合わないので断念しました。  それはさておき、 初出のGBA版初代OGではこの機体に限らずPTの固定武器としてやたらと「格闘」が実装されていましたが、たぶん誰も使わないと思いますのでOGS同様に格闘はオミットし、接近戦はコールドメタル・ナイフ、中距離戦はマシンガンまたはショットガン、遠距離戦ではアンダー・キャノン（ハイパービームライフルという名前はちょっと違和感があるので、今回は「（機体の）下側」という意味のアンダーではなく「相手を制圧する」や「包囲下に置く」という意味でのアンダーと捉えてアンダー・キャノンにします）で戦う典型的なリアル系の機体にする予定です。  もちろんビルトラプターの特徴である変形も可能で、FT形態では下の写真のような感じになります。設定ではビルトラプター自体がMSよりも小型の機体なので、胸部のコックピットハッチや背中の翼を基準に変形状態を少し小さなサイズのドット絵を用意してみたのですが、いささか小さすぎたような気もしますね。あまり気になるようであれば後で差し替えます。武装は原作通りホーミングミサイルと爆弾とアンダー・キャノンですが、爆弾が射程1で陸と海にしか攻撃できないとなると著しく使いにくい機体になってしまいますので、バトルマリンの爆雷のようにグレネード扱いのような有射程武器にする予定です。  これでようやく初期主人公機の差し替えが完了したのですが、余ったゲシュペンストはやはり本来の使用者であるギリアムが自軍に参加する際に搭乗できるようにしたいところですね（Mk-Ⅱはギリアム専用ゲシュペンストをデチューンした簡易量産型のような位置付けにしたいところです）。しかし現状では登録枠が「64体の壁」に阻まれてかなり厳しい状態なので、この辺りの問題も早めに解決していこうと考えています。

 RAM変更を一旦全て元に戻したうえで改めてテストプレイをしていますが、NPCが何度か戦闘を重ねると謎のフリーズ現象を起こしていました。原因を調査したところ「BGM設定パイロット基準化パッチ」に不具合があった事だと判明しましたので、取り急ぎ修正版を作成しました。大変申し訳ございません。以下のURLからダウンロード可能です。 https://ux.getuploader.com/retrogamelaboratory/download/66  修正内容は「NPCユニットの判別に使用するフラグ取得、及び取得データ反映と書き込みの設定ミスの修正」です。不具合の正体は、これにより最終的に累積した書き込みデータがRAMのオーバーフローを引き起こしてフリーズするというものでした。解凍パスワードは前回と同じですので、そちらの記事を参照願います。  修正ついでにデータの取得方法を若干変更し、オリジナルの第4次のBGM取得形式を参考にした「自軍かNPCが後攻側であれば常に自軍のBGM番号を取得し、そうでない場合は常に先攻側のBGM番号を取得する」という方式（自軍＝NPC>赤軍=黄軍）にしています（余談ですが、オリジナルのBGM継続パッチでは「NPC>自軍>黄軍>赤軍」という取得方法になっています）。このパッチ単体ではBGM継続パッチとの併用はできませんが、近日中に「パイロット基準化パッチ用にカスタマイズしたBGM継続パッチ」を公開予定です。もう少々お待ち下さい。

 マップ上にユニットを65体以上展開させた場合の不具合の原因が判明しました。結論から言うと、現状では一時断念せざるを得ません。HiROMの状態ではRAM容量（外付けRAMを含む）の不足でオーバーフローし、65体目以上のユニット情報が維持できないというのが不具合の原因でした。マップ上で展開しているユニットの情報はRAMの7E2000、7E4000、7E6000の各領域にリアルタイムで読み書きされているのですが、この単位が0080hのため0080*40（64体分）=2000hとなり、65体目以上の情報が維持できなくなってしまうのです。これがLoROMであればSRAM領域を1バンクあたりにつき4000ｈまで展開、最大で256Kbまで拡張できるので該当するデータを大容量化したSRAMに逃がして問題解決となるのですが、HiROMの場合は1バンクあたりのSRAM領域が2000ｈしか維持できないうえに128Kbが容量の限界となっています。多量のデータをSRAMで処理している魔装機神ではHiROMではなく従来のソフトによくあるLoROMという仕様（32MBLoRAM+32kbSRAM+SA-1チップとやや特殊ではありますが）を採用しているのはこの対策のためだと思われます。大容量のデータの場合はROM情報を特殊チップ仕様に変更してそちらで処理するという方法もあるらしいのですが、現状ではそれらしい資料が見つからず、これといってよい方法が見つかりません（一応リザーブRAM領域にデータを逃がすと正常に動くように見えるのですが、やはり維持できないのかだんだん動作が怪しくなり最後は突然ゲームオーバーになったりフリーズします）。魔装機神と同様にメモリマップをLoROMに変更する事も考えましたが、さすがに作業量を考えると厳しいものがありますので改善策が見つかるまで一時断念し、まずはSRAMに登録した増加ユニットの正常動作だけを目指す事にします。

 一時データの置き換えの仕様を変更する等して工夫した結果、とりあえずRAM拡張でユニットを96体までマップ上に展開できるようになったのですが、まだ動作が不安定です。現状ではいきなりマップ上から機体アイコンが消滅したり、敗北条件を満たさなくても突然ゲームオーバーになったり、フェイズ終了時に画面が乱れてフリーズしたりします。何に使用しているのか不明なRAM領域が一つあるので、それをうまく変更できていないのが原因だと思うのですが…。まあ元々そういう仕様でなかったものを無理矢理変更していますので、少しずつテストを繰り返してチェックするしか方法はなさそうです。  さて、ご存知の方も多いと思いますが、第4次スーパーロボット大戦では自軍登録できるパイロットと機体はそれぞれ64体まで、戦闘マップ上で展開できるユニット数は敵・味方の両軍を合わせて64体までと定められています（RAMが64体までしか展開できないようにプログラムを組んでいるため）。しかしマップ上で自軍のユニット（厳密には自分で操作できる自軍のユニット）を展開できる数も実は限られており、20体までしか出撃させる事ができません。厳密に言うと「マップ上では自軍の操作できるユニットのRAM上予約領域が定義されており、この枠が20体分しかない」のです。最終マップの「火星の決戦」ではこれをフルに使用するため選択母艦一隻+選択ユニット19体を出撃できますが、その他のマップではほぼ数体分の空きができていて、この部分にイベントで登場する自軍ユニットが書き込まれたり、ザンボット3やダンクーガやコン・バトラーVといった機体を分離させた場合のユニットを書き込むようになっています。ただし、空いている予約枠が足りないので分離できない事がほとんどです。出撃数を減らしてマップを開始するとこれらのユニットが分離できるようになっているのはこのためです。つまり、戦闘マップ上に展開できるユニットの数は「自軍が最大で20体、敵軍とNPCが合わせて44体」という事になります。敵軍やNPCの枠は特に固定されていないので、増援として登場したりすると撃破されて空欄になった枠に上位部分から書き込まれていきます（45体を超えた場合はどうなるのか未検証ですが、恐らくオーバーフローしてゲームがフリーズすると思います）。  そうなると自軍の出撃枠を増や...

 SRAMを大型化して外付けRAMに見立て読み込みデータや書き込みデータの容量を増やす試みを行っていますが、現状ではあまり上手くいっていません。とりあえず武器の個別改造とそれに付随するセーブデータを削除する事でパイロット・機体共に96体まで登録できるようにRAM内容を書き換え、当初の予定にあったインターミッション限定ではなくマップ上でもSRAMを96体まで参照できるように変更（これによって理論上はマップ上に自軍・敵軍を合わせて96体まで展開可能）、更にRAMの読み込みや書き込みの数量制限（64体までの制御）に関わるプログラムを調べられる限り調べて書き換えてみたのですが、主に強制出撃イベントを中心に不具合を起こしてしまいます。  SRAM上には参入した機体やパイロットがきちんと登録されているのですが65体目以降の機体に乗っているパイロットが出撃不能になったり、65人目以降のパイロットが登録されても出撃不能になったりする（インターミッションではパラメーター参照や乗り換え、機体改造やパーツ変更はできるのですが…）他、敵軍のデータをRAMに書き込む際に関しても一部できちんと書き込まれなかったり読み込まれなかったり、設定ルーチン通りの行動をしないなどの異常が見られます。また、外付けRAM領域に書き込まれる内容はどういうわけかメモリビューワーから確認する事ができず、いちいちバイナリエディタや外部のプロセスエディタでSRAMのファイルを見て確認する必要があります（一応SRAMには指定した場所にデータが書き込まれているのが確認できました）。単純にプログラム部分の書き換えミスだと思うのですが、やはり修正・改変しなければならない箇所があまりにも膨大なので厳しい状態であるのは事実です。また、予想通り中断データをセーブした後で最初から、あるいは通常のシナリオセーブデータをロードするとSRAMの内容が上書きされてしまい中断データの内容がおかしくなってしまいます。中断データに関してはエミュレーターであればステートセーブを利用する、実機のプレイであれば中断データのセーブ、または中断データのロードをできないようにする（一応これは解析によって可能となりました）しかないのが現状です。余談ですが三國志英傑伝は戦闘マップ上での中断セーブができない、SUPER三國志は一騎討ちモードでのセー...

 スーパーファミコンのSRAMを外付けRAMとして使用する場合のメモリマップの割り当てに関する詳細な資料が見当たらなかったので独自に調査してみました。今回はHiROMでのメモリマップで、対応するメモリの位置は以下のような内容（左：SFC本体側のメモリマップ上の位置、右：SRAM側のメモリマップ上の位置）になります。これを使う事はほとんどないと思われますが、何かの参考になれば幸いです。 ・8KB…306000～307FFF（0000～1FFF）のみ使用。 ・16KB…8KBまでの領域+ 　　　　　316000～317FFF（2000～3FFF）を使用。 ・32KB…16KBまでの領域+ 　　　　　326000～327FFF（4000～5FFF） 　　　　　336000～337FFF（6000～7FFF）を使用。 ・64KB…32KBまでの領域+ 　　　　　346000～347FFF（8000～9FFF） 　　　　　356000～357FFF（A000～BFFF） 　　　　　366000～367FFF（C000～DFFF） 　　　　　376000～377FFF（E000～FFFF）を使用。 ・128KB…64KBまでの領域+ 　　　　　386000～387FFF（10000～11FFF） 　　　　　396000～397FFF（12000～13FFF） 　　　　　3A6000～3A7FFF（14000～15FFF） 　　　　　3B6000～3B7FFF（16000～17FFF） 　　　　　3C6000～3C7FFF（18000～19FFF） 　　　　　3D6000～3D7FFF（1A000～1BFFF） 　　　　　3E6000～3E7FFF（1C000～1DFFF） 　　　　　3F6000～3F7FFF（1E000～1FFFF）を使用。

 ざっと解析してみたところ、自軍登録メンバーの数を65以上にするにあたっての課題点が見えてきました。以下にその課題点を列挙していきます。 各種データの計算用RAM領域。これに関しては足りない分をコーエーの作品に見られる大容量SRAMや特殊チップ搭載ROMのように「外付けRAM」で増量してそちらに読み込みデータを逃がして展開させればいいが、中断データのセーブ・ロードの際の内容を大幅に変更しないと実現が難しい。外付けRAMがSRAMだった場合はリセットしたり電源を落としてもデータが更新されるまで逃がした展開データが保持され続けるので、中断データがある状態で別データのプレイをするとSRAM領域のデータが更新されてしまい内容が消えてしまう（＝中断データが正常に再現されない）。特殊チップに展開する場合はリセットしたり電源を落とすと展開データ自体が消えてしまう。いずれにせよ、中断データにこの展開データを別領域にセーブ・ロードする処理を組み込む必要があり、作業量を考えると現実的ではない。 通常のセーブデータに保持できる内容はRAMでいうところの7E1000〜7E15D5まで。これより下の領域にセーブデータの内容を拡張しようとすると中断データに影響を及ぼし、やはり外部RAMへの展開データ拡張とセーブ・ロードの方式の変更が避けられない。 登録可能数を増やすとその分だけRAM各パラメーターの読み込み領域も増やさないといけない。通常は自軍・敵軍を合計して64体分で、これを超過するとRAMからデータがはみ出して不具合を起こすので一部パラメーターの分を丸ごと外部RAMに移す必要があるが、例によって中断データに影響を及ぼす。 MAP上では展開データ領域は自軍・敵軍で共用64体分を使用するが、インターミッションでは同じ領域を自軍のみで64体分を使用する。つまり、逆に言うとそれぞれで使用するRAM領域が違えばインターミッションで使用するRAM領域だけ増やせばいいという事になる（MAP上で自軍・敵軍を合わせて65体以上出現させなければいいだけなので）。  以上の内容から見えてくるのは「7E1000〜7E152Dまでに登録データ数を保持しつつ不要と思われる内容を整理してセーブデータ領域に空きを作り、この空き容量を使って残りの登録データ容量を拡張。そしてインターミッションでのパラメータ...

 変形する際の精神ポイント受け渡し処理も問題なく動作するようになり、ゲッターチームの登録数を1枠で収める仕様変更が完成しました。仕様の都合上、パイロットの名前を7E1088の自軍参加メンバーのIDから取得しているパラメーターリストではパイロット名がメインパイロットである竜馬で表示されてしまいますが、詳細パラメーターを参照する際にはきちんと7E17E5を参照するため、各形態担当のパイロット（隼人や弁慶）が呼び出されて各種パラメーターを確認する事が可能です。なお、マップ上での各種行動や変形後のパラメーター確認時、イベントによる強制変形などに関しては7E1088ではなく7E17E5の展開パイロットIDを参照しますので、特に不具合は発生しません。  前述の通り、リスト上の表示の仕様変更に関しては基本的にインターミッションが該当しますので、「ゲッターロボの各形態に応じて自軍参加メンバーの内容を書き換え、改造処理と同様に一旦画面データを読み込み直す処理を入れてセーブデータ上のパイロットそのもの（7E1088に登録されている竜馬のID）を隼人や弁慶に書き換え、インターミッション終了時にはユニットの変形を元に戻す処理と同様に隼人か弁慶だったら強制的に竜馬に書き直す」という解決策があるにはあるのですが、これによるイベント進行の不具合などが起きてしまう可能性が否定できないので今回は採用を見合わせています。  今回のゲッターチームの仕様改変に伴い、特定のフラグ成立時や特定のユニットに乗っている時だけ登場するサブパイロットを設定する事が可能になりました。例えば複数乗りダイターン、バクシンガーを除くJ9チームや龍虎王・͡虎竜王のように変形によってメインパイロットが入れ替わる機体が実現できるほか、08小隊のエレドアやゼオライマーの美玖のようなイベントでたまに離脱する特定機体専属サブパイロット、イベント仕様で3人乗りのZZガンダムやSガンダム（それぞれイベントフラグで精神コマンド要員呼び出しを管理する）、女性たち（とカツ）の霊が憑依した暴走カミーユなども再現可能です（但し、サブパイロットのSP管理用の空きRAM領域が必要になりますが…）。  さて、今後の予定ですが、機体の保持数を64体以上にできないか挑戦してみる予定です。元々の仕様の関係でパイロットに関して...

 パイロットと機体のRAM保持枠を1体分のままゲッターロボ各種の形態に連動してパイロットを切り替える仕様変更ですが、何とか一応は成功しました。機体に関しては改造値や強化パーツが各形態で共用となり、ゲッター1系であれば竜馬、ゲッター2系であれば隼人、ゲッター3系であれば弁慶が自動的にメインパイロット（自軍登録はゲッター1系と竜馬で固定）になります。パイロット面ではレベルと撃墜数が3人で共用（つまり竜馬で2機、隼人で1機、弁慶で2機撃墜すれば5機とカウントされます）、その他の各パラメーターとSP現在値は個々人で独立しており、精神コマンドリストは従来の竜馬・隼人・弁慶の順番で固定だったものから原作の合体パターン通り（ゲッター1系だったら竜馬・隼人・弁慶、ゲッター2系だったら隼人・弁慶・竜馬、ゲッター3系だったら弁慶・竜馬・隼人）の順番に変更されます。また、「ゲッターロボ系」として同系統の他の機体への乗り換えも可能（ゲッターロボ以外のテキサスマックやメカ胡蝶鬼などの非変形機体に乗り換えた場合のメインパイロットは常に竜馬となり3人分の精神が使用可能、逆にジャックやミチルなどがゲッターロボに乗った場合はジャックの場合ジャックとメリーの2人分、ミチルのような個人パイロットの場合は本人の精神コマンドが使用可能、パイロットは各形態に変形してもジャックまたは個人パイロットで固定）です。イメージとしてはスーパーロボット大戦AやDでのゲッター系パイロットに近くなったと考えて頂ければ問題ないかと思います。  さて、上記のような仕様に変更した後に序盤のテストプレイをしてみましたが、今のところ強制出撃などのイベント発生時にもこれといった不具合は今のところ発生していません。但し一つも不具合がないわけではなく、何らかの条件を満たすとパイロットが入れ替わる際に現在SP値が正常に入れ替わらず、変形を繰り返すと無限に精神コマンドが使えてしまう事があります。恐らく精神コマンドリストを並び替えなければこの不具合を防げると思うのですが、そうなると常に竜馬・隼人・弁慶の順に精神コマンドリストが表示されてしまうのが悩ましいところです。もう少し解決策を練ってみますが、上手くいかなければ「そういう仕様」として妥協するつもりです。

 RAM容量が足りていないため自軍データの保持が困難な本作ですが、ゲッターチームに関しては「3人各自が合体ユニットのパイロットと同様にRAM内に個別の参入データを保持し、変形の度にRAM内のパイロット・機体データ全ての参照領域をメインパイロットに入れ替える」という方式を採用しています。このため、RAM上には「ゲッターチーム3人分とゲッターロボ3形態分の自軍参入データ」、つまりパイロットと機体でそれぞれ3枠が保持されているのですが、これを通常の変形ユニットのように「メインパイロット（竜馬）とメインユニット形態（ゲッター1）のそれぞれ一体分だけを保持し、変形した時だけRAMの該当領域（マップ上であれば出撃パイロットID、インターミッションであれば参入パイロットID。但しインターミッションに関しては下手に変更しない方がいいかもしれません）を一時的に上書きする」するようにすれば自軍参入データをRAM上で1枠だけ保持すればいい事になります。  実際にこの仕様への変更が可能かどうかは未知数ですが、実現できれば実質的に自軍参入枠を2体分増やせる事になりますので、実現できるように努力するつもりです。