Skyrim箱庭DIY

MODによる固有の環境不具合は自分で直して快適ゲーム。CTDにさようなら。Do It Yourself!!

【Skyrim SE】eslファイルの構造と注意点



スポンサーリンク

久々更新。今更ながら『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のテクスチャを開くだけ)

 

『ロードオーダー202122』のMODだけ気に留めて下さい。他は、何かしらMODが入ってるんだろうな、位でOK。

SSEEditで見ると、こんな感じ。

TES5Editで見たテストMOD

ArmorMOD1.esp:Steel ArmorのArmorとArmor Addonをコピペしたオリジナル鎧。

ArmorMOD2.esp:Steel ArmorのArmorのみコピペ、Armor Addonはバニラと共用。

TextureMOD1.esp:File Headerだけ。

 

こんな鎧が追加されてます。 あ、MOD1にスペース入ってなかった・・・

espの実機確認

この時、8桁のForm IDは、以下のようになります。コンソールからアイテム欲しい時に打つ『Player.Additem 00013952』みたいなアレです。上位2桁のロードオーダー+MOD毎の6桁で決まります。

esmとespのFormID

プラグイン毎に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です。最上位のロードオーダーまで埋めてる人は少ないでしょうし、良案かと。

 

 

eslの構造

まず、従来のForm IDのおさらい。上位2桁がロードオーダーで、MOD毎に6桁で決まります。000000~FFFFFFですね。

esmとespのFormID

 

対してesl。上位2桁はFE固定となります。その次3桁がesl用ロードオーダー。000~FFFまでのロードオーダーが使える為、同時に使用できるeslの上限は4096個です。

よって、eslでMOD毎に使えるForm IDは3桁だけになります。更に制限があり、利用可能な範囲は800~FFF(2048個)となってます。それでも結構ありますけどね!

eslのFormID

 

FE000000~FEFFFFFFの拡大図。例の3つのMODをesl化すると、こうなります。

FE領域に配置されたeslのFormID

 

ゲーム内で見ると、別々のMODの鎧が、FEからの領域に統合されました!

FE領域で統合されたesl

両方とも従来のロードオーダーは『FE』ですが、次の3桁はesl用ロードオーダーなので、『000』と『001』になってます。

 

TextureMOD1.eslですが、顔面真っ白にするテクスチャをbsa化してます。これもeslでちゃんと読めてますね。

eslでロードされたテクスチャ

 

ちょっと解釈がメンドいかもですが、従来のロードオーダーの観点からだと、eslはesmの直後に配置されます。Lite Masterという位置付けだけに、esp後方への配置はできません

なんか中二病臭がたまらないですね、ライトマスター(w)

eslのロードオーダー

現実世界では全員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も使用中。

プラグイン255個環境

ロードオーダーFEに、また鎧MODを突っ込みました。中身はeslのとほぼ同じ。

 

eslのSteel Armorは、FE000800。espのもxx000800なので、FEでロードされるとFE000800になります。被りますね。

espとeslの競合

 

ゲーム上で確認。eslの方が潰されて、ロードオーダーFEのesp版が競合勝利しました。

espに潰されたFE領域

つまり、

 

ロードオーダーFEを使うespがあると、eslは競合で潰される

 

ってことですね。元のロードオーダーが低い為、espより立場が弱いです

 

eslによる上書きパッチ

※公式に『上書きパッチOK』とは明記されてないんですが、あえて『espをマスター指定しちゃダメだよ!』と注意書きされてる為、esmはOKだと読み取れます、多分。実際CKでesl変換かけてもエラー出ませんし、ゲーム上の動作もOKに見えます。ただ、一応自己責任ということでお願いします。

esmへの上書きパッチに関しては、独自オブジェクトじゃないので800~FFFに納まって無くてもOKです。

eslとespで、バニラのSteel Armorの上書きパッチを作ってみます。実験なので名前を変更するだけ。

eslによる上書きパッチ

上書きパッチなので、00013952のまま。既存オブジェクトなので、eslとはいえ『FE』にはなりません(変わったら上書きパッチじゃなくなっちゃいますね)。

 

つまりesm直後に読み込まれる為、eslはespに勝てないです。

ロードオーダー下位のesl

 

ゲーム上で確認。やはりespに潰されてます。上書きパッチとして運用するのは、さすがに厳しいですね。Game Setting位なら使えそうかも。

espに潰されたeslパッチ

 

マスター参照利用

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

CKによるesl出力

 

範囲外のForm IDがあると、エラー出ます。

FormIDの範囲エラー

 

マニュアル修正するか、CKから

File > Compact Active File Form IDs

を実行して納めてください。自動で変換してくれます。

CKでFormIDの自動修正

※自動変換を使うと、esp改変 > 再変換 をした際に、Form IDが変動する可能性があります(恐らく削除発生時にForm IDを詰める)。なるべく手動でForm IDを規定範囲に納めておいた方が良いと思います。

 

なんか『拡張子を書換えてesl化』という話もあるようですが、これヤバくないですかね? SSの例だとeslロードオーダー『001』のForm ID『111』となってしまう為、非常に危険だと思います。

 

ちなみにheaderだけのファイルですら、差分が有るようです。リネームで済ませるってのはどうなんでしょうね・・・。平気なのかもですが。

バイナリで見たeslとespの差分

 

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で潰れるリスクが高い)
  • 互換パッチ(ロードオーダー後方に置けないと意味が無い)

 

 

うまく使えば、プラグイン数節約に大活躍だと思います。

以上、おしまいです!