公式esmのクリーニングをする際、Dawnguard.esmだけはRemove ITM recordsを2度実行する必要がありますよね。何故この手順を踏まないとクリーニングし切れないんでしょう？
Undelete and Disable Referencesを実行することで、新たなITM Recordsが発生するのだと思っていましたが、どうもそれだけではないようです。
探ってみると、「微妙に胡散臭いオブジェクト」1個と、「かなり胡散臭いオブジェクト」2個が見つかりました。これが原因で二度手間になっているようです。
＜前編＞では、クリーニングの流れもまとめておきます。具体的なクリーニングの作業手順ではないですが、Dawnguard.esm特有のクリーニングを知らない人は、最初の章だけ読んでおくと役立つかもです。それ以降は構造調査の話になります。
クリーニング手段そのものを知りたい人は別記事にて。
Dawnguard.esmをクリーニング
まず最初に、一般的な手順(だと思います)によるクリーニングの流れです。他のDLCでも同様です。
１．Remove ITM recordsの実行
Skyrim.esmを上書きしてるものの、何も変更していないレコードを削除します。背景緑で表示されます。
完全にマスターファイルと同一(Identical To Master 略してITM)レコードなので、Dirty Editsと判断して削除されます。残しておいてもいいこと無いです。
1回目のRemove ITM recordsで、Dawnguard.esmから630個が削除されました。
残りレコードは差し引き97397個。
２．Undelete and Disable Referenceの実行
"Deleted"フラグのついたセル内オブジェクト(RefIDが振られた物)に対して実行されます。
"Deleted"を"Initially Disabled"に変更します。削除せず残し、オブジェクトを地中深くの見えない所に沈めます。もしこのオブジェクトが何かに参照利用されたとしても、削除されずに残っている為、エラーのリスクが低くなります。
実行すると、Dawnguard.esmのUndeleted対象は82個です。削除されたNavmeshも見つけてますが、これを復活させるとトラブルが起こりかねない為、warningだけで放置されてます。
Undeleteでも、オブジェクトが無くなってITMレコード化したセルブロックを削除する場合があるようです。ログを見ると、Remove ITM終了時とUndelete開始時でレコード数の勘定が合わないことがありますが、この為だと思います。
全てじゃないので何か条件がありそうなのですが･･･そこまでは知らないです。
３．Remove ITM records(2度目)
これがDawnguard.esm特有の作業です。最後に2回目のRemove ITM recordsを実行すると、更に6個が削除されます。Dawnguard.esm以外は2度目のRemove ITMは不要です。
総レコード数は、差し引き97390個。
これで終了です。ファイルサイズのハッシュは以下の通り。
この手順でクリーニングすることが多いと思います。
2度目のRemove ITM recordsは何故必要になる？
2度目のRemove ITMで、新たに6個が削除されますが、そもそも何でこんなことになるんでしょう？
冒頭に書いた通り、2種類の胡散臭いオブジェクトがあることに起因しています。前編では比較的マシな方について書いていきます。
Dawnguard.esmで削除されたCOCMarker
Undelete実行前のDawnguard.esmです。ただの屋外セルを見ています。
0000713Bのセルに、00023C63のCOCMarker(COCでスポーンする目印)があります。新設オブジェクトではなく、Skyrim.esmに対する上書きです。
これがちょっと面倒なことしてまして。一見ただDeleted化してるだけなのですが、よく見ると削除と併せて面倒なことをしています。"Cell"の所に注目です。
これ、元々は別のセルに配置されてるCOCMarkerですね･･･ わざわざ移動してから削除してるようです。
そして元のセルである0000711Bには、新しいCOCMarkerが配置されています。
流れとしては、
- 711Bに置かれていたSkyrim.esmのCOCMarkerを、713Bに移動
- 713Bに移動したCOCMarkerを削除
- 元の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を実行すると、この２つがDirty Edits判定により削除されます。
2回目のRemove ITM records実行後です。Sub-Blockごと削除されました。
(20160912訂正) 画像ミスの差替え。
以上が、2回目のRemove ITM recordsで削除される6個のうちの2個になります。Undelete and Disable Referencesの結果として、新たなDirty Editsが発生し、2回目の実施で削除されたということです。この2個は･･･です。
次回は残りの4個についてまとめます。こっちの方は、正直意味解らない位に怪しいです。
