久々更新。今更ながら『esl』形式の新ファイルに関するメモ書きです。
Fallout4でたまに使っていたので調べていた所、Skyrim SEでも使ってるようなので、こちらに投下します(一応メインブログですし!)
やはり一長一短なので、構造と注意すべきことをまとめておきます。
なんとなくeslを使ってる人には、役に立つかも?
結構長いです。
eslとは?
『Light Master』fileという名称で、esmとespの中間の定義付けです。espよりロードオーダー低いのにマスター参照不可という、一見謎仕様。後述しますがちゃんと意味ありますし、メリットも大きいです。
ちなみに拡張子の由来は、
Elder Scrolls Master
Elder Scrolls Plugin
Elder Scrolls Light master
じゃないかと言われてるそうです。
eslの特徴
目玉は、最大4096個のeslファイルがロードが可能なことです。esm、espはとは別枠(*)なので、沢山MOD使えそうですね。CKで、espからeslに一発変換できます。
とはいえ既存のエンジンの中でやりくりしてる訳ですから、制約事項も多いです。詳しくは、構造を確認しながら見ていきます。
(*)完全な別枠では無いんですが、おおよそ別枠。以下、構造の所で詳しく記載。
従来のesmとespの構造
まずは従来のesmとespの具体例を見てから、eslの構造に入ります。
こんな感じでMODが入ってる状態を想定します。
00 Skyrim.esm
01 Update.esm
02 Dawunguard.esm
・
・
20 ArmorMOD1.esp(鎧1個だけのMOD)
21 ArmorMOD2.esp(鎧1個だけのMOD)
22 TextureMOD1.esp(bsaのテクスチャを開くだけ)
『ロードオーダー20、21、22』のMODだけ気に留めて下さい。他は、何かしらMODが入ってるんだろうな、位でOK。
SSEEditで見ると、こんな感じ。
ArmorMOD1.esp:Steel ArmorのArmorとArmor Addonをコピペしたオリジナル鎧。
ArmorMOD2.esp:Steel ArmorのArmorのみコピペ、Armor Addonはバニラと共用。
TextureMOD1.esp:File Headerだけ。
こんな鎧が追加されてます。 あ、MOD1にスペース入ってなかった・・・
この時、8桁のForm IDは、以下のようになります。コンソールからアイテム欲しい時に打つ『Player.Additem 00013952』みたいなアレです。上位2桁のロードオーダー+MOD毎の6桁で決まります。
プラグイン毎に6桁、000000~FFFFFF(計1677万個)の領域が割り当てられ、この範囲でForm IDを作ります(実際は全部使い切れないですが)。ロードオーダーは最大で00~FEなので、この000000~FFFFFFの領域が最大255個用意できる、ってことになります。
1オブジェクトにつき1個のForm IDを使うだけですから、とんでもなく大きいです。オリジナルの鎧1個作って、関連オブジェクトを作っても、数個~10数個程度で十分でしょう。鎧100個作っても、たかが知れてます。
そんな広大な領域の中、
- ArmorMOD1.espは2個だけ(ArmorとArmor Addon)
- ArmorMOD2.espは1個だけ(Armorのみ)
- TextureMOD1.espはForm ID未使用(bsaを開くだけ)
殆ど使ってないです。公式でも結構空いてますが、それにしてもこの少なさは勿体無いですね。255個しか無い枠の3個を、こんな無駄遣いで潰してるのですから。
従来構造の問題点と対策
上記のMODは、3つ合わせてもForm IDを3個しか使ってません。こういった省エネMODは結構多いです。つまり、
MOD1個に000000~FFFFFFなんてデカすぎ!
ってことなんですね。
互換性を維持しつつ拡張する為、Bethesdaが考えた(と思う多分)のは・・・
FE000000~FEFFFFFFを、小規模MODで分割利用すればいい!
という案。下の図の緑の領域を小分けします。
この緑の領域を分割利用するファイルがeslです。最上位のロードオーダーまで埋めてる人は少ないでしょうし、良案かと。
eslの構造
まず、従来のForm IDのおさらい。上位2桁がロードオーダーで、MOD毎に6桁で決まります。000000~FFFFFFですね。
対してesl。上位2桁はFE固定となります。その次3桁がesl用ロードオーダー。000~FFFまでのロードオーダーが使える為、同時に使用できるeslの上限は4096個です。
よって、eslでMOD毎に使えるForm IDは3桁だけになります。更に制限があり、利用可能な範囲は800~FFF(2048個)となってます。それでも結構ありますけどね!
FE000000~FEFFFFFFの拡大図。例の3つのMODをesl化すると、こうなります。
ゲーム内で見ると、別々のMODの鎧が、FEからの領域に統合されました!
両方とも従来のロードオーダーは『FE』ですが、次の3桁はesl用ロードオーダーなので、『000』と『001』になってます。
TextureMOD1.eslですが、顔面真っ白にするテクスチャをbsa化してます。これもeslでちゃんと読めてますね。
ちょっと解釈がメンドいかもですが、従来のロードオーダーの観点からだと、eslはesmの直後に配置されます。Lite Masterという位置付けだけに、esp後方への配置はできません。
なんか中二病臭がたまらないですね、ライトマスター(w)
現実世界では全員esmのすぐ後ろに居るけれど、仮想世界ではロードオーダーFEの領域で集結してる、みたいなイメージでどうでしょ?
これ、既にお気付きの人も居るかと思いますが。『分割利用』と書きましたが、実質的にeslでやってることは、小規模MODのマージと同じなんです。eslという小分け状態を集めて、on memoryでFE領域にマージしてる訳です。使い勝手の良い動的マージ、といった所ですかね。
eslの使用上の注意
使用にあたっての注意と、作成時の注意をメモ。
ロード可能なeslの数
最大4096個ですが、条件次第でロード上限数が減ります。Formを2048個使い切ったeslだと、おおよそ300個程しかロードできないとのこと(公式)。
eslで扱えるForm総数、もしくはロードオーダー1個あたりのForm数上限が、おおよそ60万個位なんですかね?
ロードオーダーの制限
前述の通り、esp後方への配置はできません。esm後方かつesp前方のみ。esl間のロードオーダー変更は自由です。
ロードオーダーFEとの競合
ロードオーダーFEまで埋まりきってる状態を作りました。大半はHeaderだけのダミープラグインですが。例の3つのeslも使用中。
ロードオーダーFEに、また鎧MODを突っ込みました。中身はeslのとほぼ同じ。
eslのSteel Armorは、FE000800。espのもxx000800なので、FEでロードされるとFE000800になります。被りますね。
ゲーム上で確認。eslの方が潰されて、ロードオーダーFEのesp版が競合勝利しました。
つまり、
ロードオーダーFEを使うespがあると、eslは競合で潰される
ってことですね。元のロードオーダーが低い為、espより立場が弱いです。
eslによる上書きパッチ
※公式に『上書きパッチOK』とは明記されてないんですが、あえて『espをマスター指定しちゃダメだよ!』と注意書きされてる為、esmはOKだと読み取れます、多分。実際CKでesl変換かけてもエラー出ませんし、ゲーム上の動作もOKに見えます。ただ、一応自己責任ということでお願いします。
esmへの上書きパッチに関しては、独自オブジェクトじゃないので800~FFFに納まって無くてもOKです。
eslとespで、バニラのSteel Armorの上書きパッチを作ってみます。実験なので名前を変更するだけ。
上書きパッチなので、00013952のまま。既存オブジェクトなので、eslとはいえ『FE』にはなりません(変わったら上書きパッチじゃなくなっちゃいますね)。
つまりesm直後に読み込まれる為、eslはespに勝てないです。
ゲーム上で確認。やはりespに潰されてます。上書きパッチとして運用するのは、さすがに厳しいですね。Game Setting位なら使えそうかも。
マスター参照利用
esl上の新規レコードは、いずれもFExxxxxxになる為、espからのマスター指定はできません(FFxxxxxxになってしまう)。
eslファイルの作成
作成時の注意です。
最初に、元になるespのForm ID(overrideでなくnew recordで作ったオブジェクト)が、800~FFFに納まってるかを確認します。超えてる場合はForm ID修正が必要です。SSEEditでマニュアル修正するか、何でもよければCKで自動修正可能です。
問題無ければ、CKからeslとして出力します。
File > Convert Active File to Light Master
範囲外のForm IDがあると、エラー出ます。
マニュアル修正するか、CKから
File > Compact Active File Form IDs
を実行して納めてください。自動で変換してくれます。
※自動変換を使うと、esp改変 > 再変換 をした際に、Form IDが変動する可能性があります(恐らく削除発生時にForm IDを詰める)。なるべく手動でForm IDを規定範囲に納めておいた方が良いと思います。
なんか『拡張子を書換えてesl化』という話もあるようですが、これヤバくないですかね? SSの例だとeslロードオーダー『001』のForm ID『111』となってしまう為、非常に危険だと思います。
ちなみにheaderだけのファイルですら、差分が有るようです。リネームで済ませるってのはどうなんでしょうね・・・。平気なのかもですが。
Editの制限
CKではeslをeditできません。espで変更かけてから、再度esl変換する必要があります。espのバックアップを忘れずに。SSEEditでは、eslのedit可能です。
eslの注意事項まとめ
- 最大4096個使えるが、構造(Form数)次第では数が減る
- esmの後ろかつespの前にしか置けない
- ロードオーダーFEのプラグインがあると、eslと競合する(eslが潰れる)
- eslによる上書き変更は、ロードオーダーが低い為espに潰され易い
- マスター参照利用不可
- esl作成時は、Form IDの範囲に注意(800~FFFしか使えない)
- 拡張子だけ書換えない方がいい(範囲チェック)
- CKではeslをeditできない
esl化に向いてるMOD&向いてないMOD
以上のことから、向き不向きの検討(全部は試してませんw)。
向いてそうなMOD
- bsaを使ったassetのみのMOD(Form IDを使わない)
- バニラ改変を伴わない小規模MOD(追加装備等、独自要素だけ)
- まず競合しなさそう、競合レコード削除で乗り切れそうなMOD(Game Setting等)
向いてなさそうなMOD(無理なMOD)
- Form IDが2048個を超える大規模MOD(仕様的に不可能)
- 多重競合が起きそうなMOD(NPC改変等、他のespで潰れるリスクが高い)
- 互換パッチ(ロードオーダー後方に置けないと意味が無い)
うまく使えば、プラグイン数節約に大活躍だと思います。
以上、おしまいです!