読者です 読者をやめる 読者になる 読者になる

Skyrim箱庭DIY

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

【Skyrim】Dawnguard.esmだけ特殊なクリーニングが必要になる原因究明<前編>

TES5EDIT 不具合対策


スポンサーリンク

公式esmのクリーニングをする際、Dawnguard.esmだけはRemove ITM recordsを2度実行する必要がありますよね。何故この手順を踏まないとクリーニングし切れないんでしょう?

Undelete and Disable Referencesを実行することで、新たなITM Recordsが発生するのだと思っていましたが、どうもそれだけではないようです。

探ってみると、「微妙に胡散臭いオブジェクト」1個と、「かなり胡散臭いオブジェクト」2個が見つかりました。これが原因で二度手間になっているようです。

<前編>では、クリーニングの流れもまとめておきます。具体的なクリーニングの作業手順ではないですが、Dawnguard.esm特有のクリーニングを知らない人は、最初の章だけ読んでおくと役立つかもです。それ以降は構造調査の話になります。

クリーニング手段そのものを知りたい人は別記事にて。

Dawnguard.esmをクリーニング

まず最初に、一般的な手順(だと思います)によるクリーニングの流れです。他のDLCでも同様です。

 

1.Remove ITM recordsの実行

Skyrim.esmを上書きしてるものの、何も変更していないレコードを削除します。背景緑で表示されます。

DirtyEdits

完全にマスターファイルと同一(Identical To Master 略してITM)レコードなので、Dirty Editsと判断して削除されます。残しておいてもいいこと無いです。

 

1回目のRemove ITM recordsで、Dawnguard.esmから630個が削除されました。

DirtyEditsの削除

残りレコードは差し引き97397個

 

2.Undelete and Disable Referenceの実行

"Deleted"フラグのついたセル内オブジェクト(RefIDが振られた物)に対して実行されます。

削除フラグ

 

"Deleted"を"Initially Disabled"に変更します。削除せず残し、オブジェクトを地中深くの見えない所に沈めます。もしこのオブジェクトが何かに参照利用されたとしても、削除されずに残っている為、エラーのリスクが低くなります。

InitialyDisbled

 

実行すると、Dawnguard.esmのUndeleted対象は82個です。削除されたNavmeshも見つけてますが、これを復活させるとトラブルが起こりかねない為、warningだけで放置されてます。

削除フラグをアンデリート

 

Undeleteでも、オブジェクトが無くなってITMレコード化したセルブロックを削除する場合があるようです。ログを見ると、Remove ITM終了時とUndelete開始時でレコード数の勘定が合わないことがありますが、この為だと思います。

アンデリートによるセルブロックの削除

全てじゃないので何か条件がありそうなのですが・・・そこまでは知らないです。

 

3.Remove ITM records(2度目)

これがDawnguard.esm特有の作業です。最後に2回目のRemove ITM recordsを実行すると、更に6個が削除されます。Dawnguard.esm以外は2度目のRemove ITMは不要です。

2回目のRemoveITMrecords

総レコード数は、差し引き97390個

 

これで終了です。ファイルサイズのハッシュは以下の通り。

クリーニング完了

この手順でクリーニングすることが多いと思います。

 

 

2度目のRemove ITM recordsは何故必要になる?

2度目のRemove ITMで、新たに6個が削除されますが、そもそも何でこんなことになるんでしょう?

冒頭に書いた通り、2種類の胡散臭いオブジェクトがあることに起因しています。前編では比較的マシな方について書いていきます。

 

Dawnguard.esmで削除されたCOCMarker

Undelete実行前のDawnguard.esmです。ただの屋外セルを見ています。

0000713Bのセルに、00023C63のCOCMarker(COCでスポーンする目印)があります。新設オブジェクトではなく、Skyrim.esmに対する上書きです。

Dawnguardで変更されるCOCMarker

 

これがちょっと面倒なことしてまして。一見ただDeleted化してるだけなのですが、よく見ると削除と併せて面倒なことをしています。"Cell"の所に注目です。

削除前に移動しているCOCMarker

これ、元々は別のセルに配置されてるCOCMarkerですね・・・ わざわざ移動してから削除してるようです。

 

そして元のセルである0000711Bには、新しいCOCMarkerが配置されています。

追加された新規COCMarker

 

流れとしては、

  1. 711Bに置かれていたSkyrim.esmのCOCMarkerを、713Bに移動
  2. 713Bに移動したCOCMarkerを削除
  3. 元の711Bには、Dawnguard.esmで新しいCOCMarkerを設置

となります。

Dawnguard.esmによる713Bのセルに対する変更は、削除に伴い移動してきたこのCOCMarkerのみです。つまり、わざわざ移動させずにその場で削除していれば、713Bのセルを汚さなくて済む筈です

 

Undelete and Disable Referenceによる修正

こういうケースのDeleted関係レコードにも、ありがたいことにUndeleteが対処してくれます。

実行すると、移動後に削除されていたCOCMarker(00023C63)は、移動せずに元のセルに残されます。その場で"Initially Disabled"に変更されました。

アンデリートで移動の取り消し

 

2回目のRemove ITM recordsの削除対象

COCMarkerのセル移動が無くなったので、713Bのセルに対する変更が無くなりました

移動先のセル変更無し

したがって、713Bのセル及びSub-Block(-6,0)はSkyrim.esmと全く同一であり、つまりITMレコード化しました。ここでRemove ITM recordsを実行すると、この2つがDirty Edits判定により削除されます

 

2回目のRemove ITM records実行後です。Sub-Blockごと削除されました。

(20160912訂正) 画像ミスの差替え。

2回目のRemoveIMTrecordsで削除

以上が、2回目のRemove ITM recordsで削除される6個のうちの2個になります。Undelete and Disable Referencesの結果として、新たなDirty Editsが発生し、2回目の実施で削除されたということです。この2個は・・・です。

次回は残りの4個についてまとめます。こっちの方は、正直意味解らない位に怪しいです。