この記事は、英語 wiki （LAST EDITED BY Artyom Zuev, 2024年6月2日）を基に加筆・修正したものです
この記事は公式記事を翻訳したもので、便宜的な補助資料として作成されました。最新の情報は原文を参照し、原文と訳文に矛盾があれば原文に従ってください。訳文の誤りや矛盾により生じるトラブルや損失について一切の責任を負いません。
翻訳： @ichihito_ohi、2024年6月20日
¶ 概要
このページでは、 Phantom Brigade における mod システムの設計について詳しく説明します。 Mod 開発者を対象としています。 Mod のインストール手順や一般的なガイドラインをお探しの場合は、上位階層の Modding ページ を参照してください。
¶ Mod システム
設定ファイルが公開されているデータ駆動型構造のおかげで、 Phantom Brigade は常に直接改造することができます。インストール先フォルダ内のファイルを変更することで、シナリオ変更、装備のバランス再調整、新しい機体やローカライズの追加などは可能です。しかし、この改造アプローチにはいくつかの問題と制約があります：
- アプリケーション・ディレクトリの中身を改造する必要があります。それにより、アップデート時やファイル検証時に mod が消失したり、一部のユーザー・アカウントが mod にアクセスできなくなったりするなどの問題が発生します。
- 同じ設定項目を変更する複数の mod をインストールすることが不可能です
- ゲームロジックを改造することができません
- その他様々な問題の原因（mod の優先順位を制御できない、 mod とは直接関係のない大量のデータを複製する必要性、など）
この新しい mod システムはこれらの問題すべてを解決するための試みです。これは、改造可能な他の人気 Unity ゲームの mod システムの設計にかなり近いものです。 Mod 開発を初めるには、 AppData/Local/PhantomBrigade/Mods フォルダを開いてください。バージョン 1.1 以前のゲームでは追加の手動セットアップ（Mods フォルダと Settings/mods.yaml の手動作成）が必要でしたが、現在は必要なくなりました。
フォルダが見つけられない場合、あなたの PC で Windows エクスプローラーの設定がフォルダを非表示にしている可能性があります。詳細は次の web ページを参照してください。Windows の隠しファイルと隠しフォルダを表示する - Microsoft サポート
または、メイン・メニューの MOD タブで「ローカルモッド」ボタンを押すとフォルダが開きます。
Mods/MyMod1、 Mods/MyMod2 …のように mod は別々のフォルダにします：
親ディレクトリ配下の mod フォルダの例。
それぞれの mod フォルダには、 mod の内容について基本的な情報をゲームに伝える metadata.yaml ファイルが必ず必要で、これにより読み込みと mod 管理 UI の描画が可能になります
- 識別子
- バージョン
- 含まれるコンテンツの種類（詳細は後述）
- 互換性のあるゲームのバージョン（例： "1.0" や "1.1.2"）
- 名前
- 説明
上記フィールドをすべて備えた metadata.yaml の例。
メイン・メニューでは、 mod フォルダ内で検知された mod をすべて確認できます：
メイン・メニューの MOD タブの例。いくつかの mod が有効になっている。
ゲームは起動時に mod を適用します。 Mod をインストール、無効化、再有効化した場合は、ゲームを再起動して影響を確認する必要があります。
¶ Mod コンテンツ・タイプ
Mod には異なるコンテンツ・タイプを含めることができます。これらは mod フォルダ内でサブフォルダとして分けられ、その存在は metadata.yaml 内で宣言します。対応するコンテンツ・タイプは時間を経て拡張され、設定やローカライズ、画像などが含まれます。
¶ Config overrides （設定上書き）
- Metadata フラグ：
includesConfigOverrides - フォルダ：
ConfigOverrides/
これは、 Configs フォルダを直接編集するのとよく似た、最も単純な種類の mod コンテンツです。
- Configs フォルダの階層構造を
Mods/[ModName]/ConfigOverrides以下に複製すると、ファイルを置き換えたり新しく追加したりできます。 - そこに配置するファイルはゲームからコピーした
.yamlファイルを改造した物である必要があり、まったく同じ場所に配置する必要があります。 - 変更内容は、ゲームの初期化時だけではなくデータベースが読み込まれるたびに挿入されるため、後々のデータベース読み込みや複数回のデータベース読み込みなどにも耐えられます。
- 例えば、新しい武器を
Mods/[ModName]/ConfigOverrides/DataDecomposed/Equipment/Part_Presets/my_new_weapon.yamlに追加するとゲームはそれを読み込みます。 - 別の例：独自バージョンのグローバル設定ファイルを
Mods/[ModName]/ConfigOverrides/Data/Settings/simulation.yamlに配置すると、ゲームはそのバージョンのグローバル設定を使用した状態で起動します。 - 制限：
DataとDataDecomposedフォルダの内容のみ対応しています。Configsの中には他にもファイルがありますが、現時点ではこの mod コンテンツ・タイプで改造することはできません。 Config overrides を用いた mod 適用は PB/Configs ディレクトリのファイルを直接改造するディスク操作ではなく、DataLinkerおよびDataMultiLinkerデータマネージャーの読み込み段階における挿入操作です。ですが、通常みなさんが改造したいであろうファイルは上書き可能です―それ以外のファイルはごく少数で改造には適していません。（古いバイナリファイル、現在のデータベースシステムより前から存在する使われていない設定など）
¶ Config edits （設定編集）
- Metadata フラグ：
includesConfigEdits - フォルダ：
ConfigEdits/
このコンテンツ・タイプを使うと、複数の mod による同一ファイルの改造やアップデート時のファイル構造変化に耐性のある、よりきめ細やかな改造が可能になります。
- 表面上は config overrides に似ています： Configs フォルダの階層構造を
Mods/[ModName]/ConfigEditsに複製して、既存のパスおよびファイル名と一致するように.yamlファイルを配置してください。 - ただし、これらのファイルの中身は異なります。内部的には、これらのファイルは構造が異なります。同じパスに同じ名前の設定ファイルそのものを複製する代わりに、変更リストを格納します。 Config edits を使用すると、削除を要求するだけでなく、さらにエキサイティングなことに、同じ名前の設定ファイルについて個別のフィールドや項目を編集できるようになります。
- これは設定 mod の大きなゲームチェンジャーとなるでしょう。改造における大きな弱点のひとつは、同じファイルを改造している異なる mod 間の衝突や、開発者がゲームを更新するたびにファイルを抽出して改造したコピーを更新し続ける必要があることです。例えば、本作の
simulation.yamlには何百ものパラメータが含まれており、物理シミュレーション設定の部隊サイズや戦利品生成の倍率など何かしらを変更するため、様々な mod がこれを改造しようとするでしょう。 - 通常、すべての変更を手動で統合して別の合作 mod としてまとめる必要がありました―同じファイルを変更する複数 mod を共存させる方法は他にありませんでした。本機能なら、ある mod が
squadSizeと呼ばれる行を改造する一行だけのsimulation.yamlファイルを持ち、また別の mod が複数フィールドの変更を指示するsimulation.yamlファイルを持つということが可能です―そしてすべての変更がシームレスに統合されます。まるで本作の設定のすべての項目やフィールドをそれぞれ個別の.yamlや個別のフォルダのように扱えるようになり、非常に的を絞った変更が可能になります。 - もうひとつの良い例が、私たちの #phantom-modding チャンネルでもよく話題に挙がる部隊サイズの変更リクエストです。この機能を使わないと、それにはゲーム中の全シナリオひとつひとつとシミュレーション全体設定ファイルのコピーを管理する必要があり、これは良い方法とは言えませんしそれらのファイルに関連し得る無数の mod を邪魔してしまいます。 Config edit 機能を使えば、部隊サイズ mod は他の多くと競合しなくなり、開発者が新しいリリースでシミュレーション設定やシナリオを編集しても mod を更新する必要がなくなります。
Config edits の形式は比較的単純です。
- 対象の設定ファイルをゲームから削除するには
removedをtrueに設定してください。（例えば、あなたの mod が武器の部品を置き換え、既存の武器をゲームから削除する必要がある場合） - 対象の設定ファイルにおいて細かな変更をおこなうには、
editsフィールドに記入してください。- 他の設定ファイルに見られるシリアル化された
List<T>と同じように、必ず各行を-で始めてください。 - 必ず各行をクオーテーションマークで囲んでください。例：
- 'hidden: true'これにより行内の任意の場所で予約文字 [1] が使えるようになります。
- 各編集はコロン
:で分割された二辺で構成されます―左辺が パス 、右辺が 値（バリュー） です。- 最上位フィールドの場合、パスはフィールド名だけです。例えば、
squadSizeという名前の最上位フィールドを3という値に改造するには、次のように入力します：- 'squadSize: 3' - 他のフィールドと入れ子になっているフィールドもあります―これに到達するには、パスに全ての階層（ステップ）を含め、ピリオド
.で区切ってください。―例えば、1層の入れ子になったフィールドの改造はこちら：- 'customPlayerSlot.spawnTagsUsed: true' - フィールドの名前が辞書型のキーやリスト型の番号 [2] の場合でも指定できます。例：
- 'states.no_hostiles.visible: false' # no_hostiles は辞書のキー - 'unitChecks.0.value: 1' # 0 はリストの番号！
- 最上位フィールドの場合、パスはフィールド名だけです。例えば、
editsフィールドは辞書型ではないので、同じパスについて複数回編集を繰り返すこともできます。例えば、tagsコレクションを一度改造（何かを削除するなど）した後でもう一度改造（何かを追加するなど）しても、まったく問題ありません。
- 他の設定ファイルに見られるシリアル化された
- 現在、解析できる変数の型は以下のものに限られています：
string,bool,int,float,Vector2,Vector3,Vector4- 文字列（string）型フィールドの場合、右辺の値はそのまま使用されます。
- ブール（bool）型の場合、
trueとの等価を用いて使用されます。 - 浮動小数点（float）型や整数（int）型の場合、 C 仕様書の
int.TryParseやfloat.TryParseで想定されている文字列書式を参照してください。例を挙げると6や8.62などです。 - ベクトル（各種Vector）型の場合、浮動小数点（ float ）型に準拠した既定数の float をカンマで区切って括弧で囲んだものが想定される書式です。例を挙げると
(3.1, 4, 7.2)などです。 - ただし、すべての場合で解析が必要になるわけではありません。例えば、ある型の新しいインスタンスで参照フィールドを埋めるなど、フィールドを_既定値_で埋めたいだけの場合はどうなるでしょうか？
!d（"default" の d）が専用の予約キーワードです。以下のように使用します：- 'customExitBehaviour: !d'
- 通常のフィールドの場合、以下の処理に対応しています：
- 指定した新しい値で上書きする
- 'field: 7' # 'field' という名前のフィールドを 7 で上書き
- 指定した新しい値で上書きする
List<T>の場合、以下の処理に対応しています：- 指定した新しい値で上書きする
- 'list.4: 7' # 'list' という名前のリストの4番を 7 で上書き - 指定した番号に新たな値を追加する：
- 'list.0: 7 !+' # リストの一番最初に値が 7 の項目を挿入 - 'list.8: 7 !+' # リストの8番に値が 7 の項目を挿入（それ以上項目がある場合）または一番最後に挿入（項目が8個未満の場合） - 指定した番号を削除する：
- 'list.3: !-' # 3番の項目を削除
- 指定した新しい値で上書きする
HashSet<string>の場合、以下の処理に対応しています：- 値を追加する：
- 'tags: context_facility !+' # ハッシュセット 'tags' に文字列を 'context_facility' の挿入を試行 - 値を削除する：
- 'tags: context_fort !-' # ハッシュセット 'tags' から文字列を 'context_facility' の削除を試行
- 値を追加する：
Dictionary<T>の場合、以下の処理に対応しています：- 指定した新しい値で上書きする
- 'dictionary.existing_key: true' # 辞書 'dictionary' のキー 'existing_keyin' に対応する値（バリュー）を 'true' で上書き - 新しい項目を追加する：
- 'dictionary.new_key: true !+' # 辞書にキー 'new_key' と対応する値 'true' の挿入を試行 - 項目を削除する：
- 'dictionary.existing_key: !-' # キー 'existing_key' に対応する項目の削除を試行
- 指定した新しい値で上書きする
- 対応している操作タグの全リスト：
!+- 新しい項目を追加!-- 項目を削除!d- 既定値に設定（参照型の場合 - null でない新規インスタンス）!n- null に設定
- 対応操作は今後時間をかけて拡張されていきます。ただし、 config edit system に大きな変更を加える必要がある場合（複雑なデータタイプを解析する機能が必要な場合など）は、 config edits の前にライブラリ mod を使用して必要機能の実装から始めることを検討してください。
- 重要な制約事項（今後のリリースで対処予定）：
Colorフィールドの編集に対応していない- すべての編集にそれぞれパスを入力する必要がある
- オブジェクト全体の一括宣言のような、複数行の編集に対応していない
¶ Libraries （ライブラリ）
- Metadata フラグ：
includesLibraries - フォルダ：
Libraries/
これは、C#/Unity が依存する編集可能な中間言語（IL; interpreted language）によって可能になる非常に強力なタイプの mod コンテンツです。ゲームロジックにパッチを適用し新たなコードを実行できるライブラリをロードできる機能です。
- この機能の一部は、人気のあるライブラリである Harmony で利用可能になっています―すでに私たちは Harmony を使ってきましたが、それは Unity Editor の UI にパッチを適用するなど内部用に限られていました。
- ライブラリ mod の作成に興味があるプログラマーの方は、 Harmony documentation をご一読ください。
- Mod システムは
Mods/[ModName]/Libraries/MyLibrary.dllのような Libraries フォルダ内のアセンブリをすべて検出しようとします。 - 次に、そのアセンブリから型を取得して
ModLinkという特殊なクラスを継承しているクラスを探します―見つかった場合、インスタンス化され、データが入力され、特殊なエントリーメソッドが呼び出されます。 ModLinkは mod 製作者にエントリーポイントを提供します。OnLoadメソッドのオーバーライドを宣言して、任意のコードを実行できます。 Mod のメタデータすべて（作業ディレクトリ、どの mod を操作しているか、他に何の mod がロードされているか）および Harmony patcher オブジェクトにアクセス可能で、 PB 内のコードを改造できるようになります。
新規ライブラリの一般的な立ち上げ方法は以下の通りです：
- Visual Studio Community や Rider などの .NET 統合開発環境（IDE）で、 クラスライブラリ (.NET Framework) プロジェクトを作成して、ターゲットフレームワークに .NET Framework 4.7.2 [3] を指定します。
- 参照に以下のものを追加してください：
0Harmony.dllは、 Harmony web サイトの 2.1 リリース をダウンロードしてください（Phantom Brigade の今後のリリースで上層の Manage フォルダに直接含められる可能性があります）Assembly-CSharp.dll、Assembly-CSharp-firstpass.dll、System.dll、UnityEngine.dllは、インストールフォルダ（例：PB/PhantomBrigade_Data/Managed/）から入手してくださいEntitas.dllは、インストールフォルダから入手してください
ModLink.csファイルを作成してください- その中で、すべてを独自の名前空間でラップしてください。
ModTestのような、metadata.yamlのidフィールドと一致する名前が理想的ですnamespace ModTest {} ModLinkを継承するクラスを宣言してください。例：namespace ModTest { public class ModTestLink : ModLink {...} }- このクラス内で、以下のシグネチャ（署名）を用いて
OnLoadのオーバーライドメソッドを宣言してください：public class ModTestLink : ModLink { public override void OnLoad (Harmony harmonyInstance) {...} } - 必要に応じて、この開始位置を起点に独自のロジックを実装してください。例えば、
metadataフィールドにアクセスして作業ディレクトリやどの mod がこのライブラリを読み込んでいるかなどの情報を取得したり、ModManager.loadedModsにアクセスして他の mod と連動したり、任意のゲーム内クラスにアクセスしたり、メソッドに渡されたHarmonyオブジェクトを用いて独自のパッチ処理手順を実行したりすることができます。
- このクラス内で、以下のシグネチャ（署名）を用いて
Patchesというプレーンクラスを宣言してください- そのクラス内で、必要な数のサブクラスを Harmony のパッチ属性と共に宣言してください [4] ：
public class Patches { [HarmonyPatch (typeof (PhantomBrigade.GameController), MethodType.Normal)] [HarmonyPatch ("Initialize")] public class ModPatch { public static void Prefix() {...} public static void Postfix() {...} } } OnLoadのオーバーライドを宣言してその中でbase.OnLoad (harmonyInstance)の呼び出しをコメントアウトしない限り、自動的に上記のパッチがすべて適用されます。
- そのクラス内で、必要な数のサブクラスを Harmony のパッチ属性と共に宣言してください [4] ：
- その中で、すべてを独自の名前空間でラップしてください。
- .dll をビルドして、 mod の Libraries フォルダに配置してください
- シナリオの機体を設定するロジックに入り込み機体の生成方法を変更することができます。データコンテナでの逆シリアル化コードの挙動をオーバーライドして、 AI に伝える武器効率について変更することも可能です。どんなメソッドでも前処理、後処理の追加や完全な置き換えが可能です。限界はありません。 Rimworld、 Oxygen not Included、 KSP やその他の Unity 製ゲームでロジックを変更したり新しいシステムを実装したりしている mod のほとんどが同様の原理で動作しています。
¶ Textures （テクスチャー）
- Metadata フラグ：
includesTextures - フォルダ：
Textures/
このコンテンツ・タイプを使うと、既存のテクスチャーを上書きしたり使用可能なテクスチャーセットを拡張したりすることができます：
- テクスチャーを
Mods/[ModName]/Texturesに配置してください。 - フォルダがゲームに認識されない場合、それはスキップされます。（ゲームが検知するフォルダとその内容例については
PhantomBrigade_Data/StreamingAssets/UIを参照してください） - ゲームが対象のフォルダに対して定義する要件にテクスチャーが合致しない場合、それはスキップされます。（必要な形式を確認するには
StreamingAssets内のテクスチャーを調べるか以下を参照してください） - 同じ名前のテクスチャーが（対象のフォルダで）既に読み込まれている場合、それは置き換えられます。それまでに同じ名前が存在しなかった場合、新しいテクスチャーとして登録されます。
- 現在対応しているフォルダ：
Textures/UI/OverworldEvents- 全体マップ（オーバーワールド）のイベント UI に使われる画像（（
Configs/DataDecomposed/Overworld/Eventsフォルダ）DataContainerOverworldEventのstepsにあるimageフィールドで制御されます） - 解像度は必ず 1024x512 にしてください
- アルファ・チャンネルは含めず、必ず非透過画像としてください
- 全体マップ（オーバーワールド）のイベント UI に使われる画像（（
Textures/UI/OverworldEntities- 全体マップ（オーバーワールド）の存在（エンティティ） [5] 情報 UI に使われる画像（（
Configs/DataDecomposed/Overworld/Entitiesフォルダ）DataContainerOverworldEntityBlueprintのimageフィールドで制御されます） - 解像度は必ず 512x256 にしてください
- アルファ・チャンネルは含めず、必ず非透過画像としてください
- 全体マップ（オーバーワールド）の存在（エンティティ） [5] 情報 UI に使われる画像（（
Textures/UI/PilotPortraits- パイロット写真に使われる画像（基地でパイロットを編集するときにプレイヤーに制御されます）
- 解像度は必ず 256x256 にしてください
- アルファ・チャンネルをスキップ、または非透過画像とすることが可能です。（カメラ・フィード全体を覆う従来の 2D ポートレート用。）あるいは、アルファ・チャンネルを含めることも可能です。（半透明のオーバーレイ用。）
Textures/UI/Sprites- UI で使用する画像
- 最大解像度は 256x256 ですが、それ以下の任意の解像度にも対応しています。（例： 31x79px）
- アルファ・チャンネルを必ず含めてください
¶ Localization Edits （ローカライゼーション編集）
- Metadata フラグ：
includesLocalizationEdits - フォルダ：
LocalizationEdits/
このタイプのコンテンツペイロードによって、ローカライゼーション・データベースにテキストを追加できるようになります。 Confgs/Data や Configs/DataDecomposed のデータファイルにプレイヤーが目にするテキストが含まれることはまれ（今後さらにまれになるでしょう）ですが、これはそのような方法でテキストを格納するとローカライゼーションや容易なテキスト改造の可能性が妨げられるためです。ゲーム内テキストのほとんどは最終的に、 Configs/Text 内のローカライゼーション・データベースに格納され、言語別のバージョンに分割される予定です。ただし、これは mod にひとつの問題を引き起こします―新しいアイテムを追加し、そのテキストが本体データ設定に含まれていない場合に、どうやってプレイヤーが目にするテキストを追加すれば良いのでしょうか？
例えば、新しいスラスター・サブシステムを追加する場合、それに名前と説明文をつけたいはずです。しかし、ゲームがローカライゼーションに対応したため、名前と説明文はサブシステムの設定ファイルからは取得されません―ゲームは internal_aux_thruster_mod のようなサブシステムの名前を取り、 internal_aux_thruster_mod__name や internal_aux_thruster_mod__text のようにローカライゼーション・キーを決定し、それらのキーを用いてロードされた言語の適切なテキスト領域からテキストを取得しようとします。（例： Configs/Text/English/Sectors/equipment_subsystems.yaml）このテキスト領域を改造する機能がないと、ユーザー向けの名前・説明文を新しいアイテムにつけることができません。
このタイプのコンテンツをどのように使うかは上記のスクリーンショットで抜粋していますが、念のため、手順を踏んで概要を示します：
- あなたの mod が
ConfigOverrides\DataDecomposed\Equipment\Subsystemsにinternal_aux_thruster_mod.yamlという新しい設定ファイルを含んでいるとします。そのようなファイルは元のゲームには存在しません―つまり、新しいアイテムであり、改造された物ではありません。ゲームはそれにテキストを表示できません。 - 他のサブシステムがゲーム内でどのようにローカライズされているか例を見てみましょう。簡単な方法がふたつあります：
- あなたが dotPeek や Rider のような中間言語（IL）解析ソフト（デコンパイラ）をお持ちで、ゲームのコードベースを開く方法をご存じならば、対象となるデータベースクラスの
ResolveTextメソッドを読むことで、それぞれのアイテムについてどのテキスト領域でどんなテキスト・キー・パターンが使われているかわかります。 - または、 Notepad++ や Sublime Text のようなエディターを使いゲームのインストールフォルダにある
Configs\Text\English\Sectorsでinternal_aux_thruster_hotrodのような既存のサブシステムの名前を探すことで、そのようなテキストがどのファイルに格納されていて、どのようにテキスト・キーが構成されているかを見ることができます。 - Mod の
ConfigOverridesフォルダと同じ場所にLocalizationEditsという新しいフォルダを追加してください。英語ローカライゼーションに追加したい新規の文字列ふたつ（名前と説明文）を宣言しているファイルをそのフォルダのequipment_subsystemsのテキスト領域に追加してください。それは、あなたが調べたようにサブシステム用のテキストがここに格納されているからです。 - すべてを正しいフォルダに配置して
includesLocalizationEditsフラグを mod のメタデータに含まれば、完了です―新しいアイテムがプレイヤー用のテキストをゲーム中で表示するようになります！
内部的には、ゲームが言語データベースと言語ごとに登録されたキーを読み込むたびにローカライゼーション設定が適用されます。つまり：
- 言語を再読み込みしても、変更は適用されます
- 言語を切り替えても、変更は適用されます
- 他の mod を介して読み込まれた複数のローカライゼーションや非公式ローカライゼーションにも対応することができます―例えば、
MyMod\LocalizationEdits\English\equipment_subsystems.yamlファイルを作成してプレイヤー向けの英語テキストを追加する一方で、二番目のファイルMyMod\LocalizationEdits\Japanese\equipment_subsystems.yamlを作成して日本語ローカライゼーションに対応することができます。または、ある mod 向けの特定言語ローカライゼーションを含む別の拡張 mod を作成することもできます。
例：このアイテムはゲーム本体には存在せず mod で追加されたものですが、スクリーンショットで示されているように、独自の名前と説明文がゲームで適切に表示されています。
¶ Localizations （ローカライゼーション）
- Metadata フラグ：
includesLocalizations - フォルダ：
Localizations/
このコンテンツ・タイプを使うと、ゲームに新規ローカライゼーションを追加することができます。一般的な原理は以下の通りです：
- ゲームのインストールフォルダ
Configs/Textから公式の英語フォルダ English をMyMod/Localizationsにコピーして、ローカライズする言語に名前を変更してください。例：MyMod/Localizaions/French - そこに含まれるファイルのテキストをすべて翻訳してください
- ローカライゼーションを含む mod が読み込まれると、ゲーム設定ウィンドウに新しい言語設定が表示されてローカライゼーション言語を切り替えることができるようになります。
yaml ファイル上での翻訳作業が困難な場合は、有志が制作した yaml/csv 変換ツールの利用をご検討ください。
GitHub - ichihito-ohi/PhantomBrigade-Translation
特記：
- ローカライゼーションシステムの対応範囲を確認するために、ローカライズされるテキストすべてを異なる色とランダムな文字列に置き換えて表示するコンソールコマンドがあります。
> data.toggle-localization-debug - ゲームのどの部分がローカライゼーション・データベースのどの部分を使用しているかを確かめるには、 ILSpy や dotPeek のような中間言語解析ソフトを使用し、ゲームのインストールフォルダから
Assembly-CSharpを開いてDataContainerクラスを継承しているファイルで ResolveText という名前のメソッドを探すことをお勧めします。ゲーム内データベースの大部分はこのようなメソッドでテキストのローカライズを処理しており、それを読むことでローカライゼーション・キーがどのように生成されてデータ・キーの中からどのように使われているかわかるようになるでしょう。これは上述のローカライゼーション編集 mod においても役立ちます。
¶ その他
ゲームログに注意してください―何らかの問題が起きた場合に mod マネージャーから多くの情報が含まれていたり、すべて上手く動作した場合に読み込みが成功したことを確認したりすることができます。接頭辞 "Mod Manager" がついたメッセージをログの一番初めに向けて探してください。ログを表示するには、 Shift + F11 を押すか、アプリケーションのデータフォルダにあるログファイルを開いてください。
Mod の開発中は、 AppData/Local/PhantomBrigade/Settings フォルダの debug.yaml にある developerMode を有効化して、追加オプション、デバッグ情報、コンソールコマンドにアクセスできるようにすると役に立つ場合があります。
開発者モードまたは mod が有効なゲームからのバグとクラッシュの報告は BYG に処理されないことに注意してください。
リストの番号（index）は0から始まる ↩︎
https://docs.microsoft.com/dotnet/core/tutorials/library-with-visual-studio ↩︎
移動基地，敵施設，パトロール部隊など ↩︎