Difference between revisions of "De-Isolation Tutorial"
→Esmify (bit-flip) Method: Moved from ESP Mastering
imported>Dev akm |
imported>Haama (→Esmify (bit-flip) Method: Moved from ESP Mastering) |
||
| (14 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{FeatNom}} | |||
Normally, when people make changes to a plugin, they just open it up in the CS, make their changes and save. | Normally, when people make changes to a plugin, they just open it up in the CS, make their changes and save. | ||
| Line 36: | Line 31: | ||
* '''ESM Mastering'''. You can make the base (or "source") mod(s) into a master by converting it to an ESM. Both TES4Gecko and Wrye Bash provide functions to let you convert an ESP into an ESM. It works great for lots of things, especially new content that's not directly connected to the Tamriel worldspace. | * '''ESM Mastering'''. You can make the base (or "source") mod(s) into a master by converting it to an ESM. Both TES4Gecko and Wrye Bash provide functions to let you convert an ESP into an ESM. It works great for lots of things, especially new content that's not directly connected to the Tamriel worldspace. | ||
: | :However, masters generally should not modify other masters -- only plugins are supposed to modify masters. When one master directly modifies another master, problems can result, such as vanishing landscape. If you try to use TESCS to make a mod based on a master that modifies another master (especially worldspace changes), then you will very likely crash TESCS or encounter a bunch of "assertion errors" when you try to save your changes, leaving you with a plugin containing corrupt cell records. | ||
* '''ESP Mastering'''. You can trick TESCS into letting you work with plugins as if they were masters. This can be done using a fairly easy bit-flipping method in Wrye Bash or a more cumbersome bait-and-switch method (also using Wrye Bash). It works by temporarily turning an ESP into an ESM so TESCS will let you to establish dependencies on it. Once again, however, these solutions can be problematic when working with plugins that include cell changes, such as the official DLC plugins, usually resulting in "assertion errors" when you try to save your changes, leaving you with a plugin containing corrupt cell records. | * '''ESP Mastering'''. You can trick TESCS into letting you work with plugins as if they were masters. This can be done using a fairly easy bit-flipping method in Wrye Bash or a more cumbersome bait-and-switch method (also using Wrye Bash). It works by temporarily turning an ESP into an ESM so TESCS will let you to establish dependencies on it. Once again, however, these solutions can be problematic when working with plugins that include cell changes, such as the official DLC plugins, usually resulting in a crash or "assertion errors" when you try to save your changes, leaving you with a plugin containing corrupt cell records. | ||
* '''ESP Patching'''. This involves using TES4Edit to directly create an add-on "patch" plugin or using TES4Gecko to create a patch file based on the differences between the original and your changes. This works best when you're not adding any new content to the source originals (i.e., you're just altering values in existing records, such as giving all mudcrabs more health or making certain weapons do more damage). | * '''ESP Patching'''. This involves using TES4Edit to directly create an add-on "patch" plugin or using TES4Gecko to create a patch file based on the differences between the original and your changes. This works best when you're not adding any new content to the source originals (i.e., you're just altering values in existing records, such as giving all mudcrabs more health or making certain weapons do more damage). | ||
| Line 74: | Line 69: | ||
For example, if you wanted to add new enemies and dungeon levels to the Knights of the Nine DLC mod, then ESP Mastering is the way to go because you're adding a bunch of new content. If you just want to alter the existing enemies and dungeon levels in KotN, then ESP Patching is probably a better solution. | For example, if you wanted to add new enemies and dungeon levels to the Knights of the Nine DLC mod, then ESP Mastering is the way to go because you're adding a bunch of new content. If you just want to alter the existing enemies and dungeon levels in KotN, then ESP Patching is probably a better solution. | ||
=== Esmify (bit-flip) Method (Wrye Bash) === | |||
There are two ways to use [http://wrye.ufrealms.net/#WryeBash Wrye Bash] to make esp masters. The older way involves creating an esm copy of the esp, then building on top of that, and then, when done, editing the masters list of the mod to point back to the esp instead of the esm. (Oddly, the game itself allows esp-mastering -- it's only TESCS that objects to it.) | |||
'''Bait-and-Switch Method | The newer Wrye Bash approach doesn't make an esm copy of the mod, but instead flips a bit in the esp file that fools TESCS into treating an "esp" extension file as an esm. This is a bit less messy then the older approach -- but you have to remember to flip the bit back before you play. | ||
Having said all that, the process is actually quite simple: | |||
* If you want to add an esp master to the mod, then (in Wrye Bash): | |||
** Go to Mods tab, right click on the esp you want to act as master (e.g., Alpha.esp), and... | |||
** Select '''Esmify Self''' from the context menu. | |||
* Start TESC in the normal way, and include the esm'ified esp just like you include Oblivion.esm. | |||
** Note that since it's now an "esm" as far as TESCS is concerned, it will appear near the top of the the mod listing in TESCS. | |||
* Mod in the normal way, and save your new mod (e.g. Beta.esp). | |||
** If you've done things correctly, then Beta.esp will have both Oblivion.esm and Alpha.esp as masters -- and they'll both appear in blue text in the masters list for Beta.esp in Wrye Bash. | |||
** ''The blue text is a hint that the mod is still esm'ified!'' | |||
* Before playing, you need to convert the Alpha.esp back to an esp, so... | |||
** On the Mods tab, right click on Alpha.esp and select '''Espify Self''' (the command changes to match the esm/esp state of the mod.) | |||
** '''Or...''' On the mods tab, right click on Beta.esp and select '''Espify Masters'''. This is useful if the mod has more than one esp master. | |||
'''Additional tips:''' | |||
* If a mod already has esp masters then you can quickly flip all of them to esm state by using the '''Esmify Masters''' command. | |||
* In short, you only need to use "Esmify Self" when you're adding esp masters to a mod. If it's already dependent on them, just use the "Esmify Masters" and "Espify Masters" commands on the dependent mod (Beta.esp). | |||
* If you're modding and playtesting, You can actually use "Espify Masters" ''before'' quitting TESCS -- ''so long as you don't reload the esmified esps, TESCS will continue to think that they're esms!'' If you're doing this, be ''sure'' that when you load, esps are esmified -- if they're not, then TESCS will treat them like esps and your mod will be messed up. | |||
** Just to be safe, it's probably a good idea to make backups of your mod on a regular basis. You can do this manually, and/or you can take advantage of Bash's [http://wrye.ufrealms.net/Wrye%20Bash.html#FileCommands Snapshot and Backup] features. | |||
* Not all esps cooperate well with each other. E.g., Martigens Monster Mod defines a "GoldenSaint" editor id which conflicts with the "GoldenSaint" defined by the SI version of Oblivion.esm. You'll need to understand the mods involved and the nature of the particular conflict to know whether you can ignore such warnings or not. | |||
* Unfortunately, the "Espify/Esmify Self" command can't practically be used for editing esm files. While you will be able to load the .espify-self file as a plug-in, the bit will be flipped back on the first save, making it a true .esm file again. A second save will cause a crash, presumably because master files can't be set as active, and thus can't be saved. | |||
=== Bait-and-Switch Method === | |||
This solution is a bit more cumbersome than the bit-flip method. It uses SomePlugin.esm (note the ESM extension) while you're making changes as the "bait" (so TESCS will consider it a master) and then swaps it with SomePlugin.esp when you're done (the "switch"). | This solution is a bit more cumbersome than the bit-flip method. It uses SomePlugin.esm (note the ESM extension) while you're making changes as the "bait" (so TESCS will consider it a master) and then swaps it with SomePlugin.esp when you're done (the "switch"). | ||
| Line 97: | Line 115: | ||
Now you can go back and use the bait-and-switch method or the bitflip method to make all your other changes on the unsplit original, knowing that the result will end up with corrupted cells in it. Once you've got this version done, you can chop out the bad cells with TESsnip or a hex editor, change the file extension to .esu, and apply it as a TES4Gecko patch to the version with good cell data. | Now you can go back and use the bait-and-switch method or the bitflip method to make all your other changes on the unsplit original, knowing that the result will end up with corrupted cells in it. Once you've got this version done, you can chop out the bad cells with TESsnip or a hex editor, change the file extension to .esu, and apply it as a TES4Gecko patch to the version with good cell data. | ||
[[The_Elder_Scrolls_Construction_Set|TESCS 1.2]] seems to be a bit less forgiving about worldspace changes and may crash rather than letting you save a file with corrupted cell data as suggested here. If you run into this problem, you may be able to get around it using TESCS 1.0. | |||
== ESP Patching == | == ESP Patching == | ||
| Line 103: | Line 121: | ||
This works best when you're only changing existing records in another plugin. For example, if you want to alter the armored horses from DLCHorseArmor, this is the easiest way to do it. | This works best when you're only changing existing records in another plugin. For example, if you want to alter the armored horses from DLCHorseArmor, this is the easiest way to do it. | ||
=== Making | === Making an ESP Patch With TES4Edit === | ||
In the following example, we'll use SomePlugin.esp as the original mod and MyTweaks.esp to contain the de-isolated changes, also known as "overrides". | |||
* When you launch TES4Edit, it will popup a window showing your complete plugin load-order list. You can load everything, but this may be more than you really need. If you right-click anywhere in the list, you'll get an option to select none, which unchecks everything. Now you can just pick the plugin you want to alter. | * When you launch TES4Edit, it will popup a window showing your complete plugin load-order list. You can load everything, but this may be more than you really need. If you right-click anywhere in the list, you'll get an option to select none, which unchecks everything. Now you can just pick the plugin you want to alter. | ||
* | * Select SomePlugin.esp and click OK when you're ready. | ||
* Once it finishes loading, expand the tree listing on the left for SomePlugin.esp. | * Once it finishes loading, expand the tree listing on the left for SomePlugin.esp. | ||
* Now expand the tree further to expose the specific records you want to change, such as Creatures, Weapons, etc. | * Now expand the tree further to expose the specific records you want to change, such as Creatures, Weapons, etc. | ||
| Line 129: | Line 145: | ||
You can also create an ESP Patch using TES4Gecko and Wrye Bash. | You can also create an ESP Patch using TES4Gecko and Wrye Bash. | ||
This is a simple example based on the 1.31 version of Oscuro's Oblivion Overhaul. It describes a scenario where it makes a lot of sense to take advantage of mod "de-isolation" to preserve your changes in a separate plugin. | This is a simple example based on the 1.31 version of Oscuro's Oblivion Overhaul. It describes a scenario where it makes a lot of sense to take advantage of mod "de-isolation" to preserve your changes in a separate plugin. | ||
Consider this question: | Consider this question: | ||
| Line 135: | Line 151: | ||
''I'm thinking of changing Oscuro's Oblivion Overhaul to add the War Scythes (which were left out at the last minute before the release of OOO 1.3) to some of the leveled lists, but I also know that a new version of OOO is coming out soon. Is there any conceivable way to have the changes transfer over to the new OOO (1.32) when it gets released? Some creative way of merging the old and the new or something? I don't really want to go and take the time to make the changes if I'll just end up having to do them again when the new one comes out.'' | ''I'm thinking of changing Oscuro's Oblivion Overhaul to add the War Scythes (which were left out at the last minute before the release of OOO 1.3) to some of the leveled lists, but I also know that a new version of OOO is coming out soon. Is there any conceivable way to have the changes transfer over to the new OOO (1.32) when it gets released? Some creative way of merging the old and the new or something? I don't really want to go and take the time to make the changes if I'll just end up having to do them again when the new one comes out.'' | ||
Yes, there is a way. It's called de-isolation. This will keep your changes in a separate plugin so it won't be lost when OOO | Yes, there is a way. It's called de-isolation. This will keep your changes in a separate plugin so it won't be lost when the next version of OOO comes out. However, these instructions are fairly specific to OOO 1.31, which used one large ESP file. Since OOO 1.32 or later versions use a split ESM/ESP structure, an additional step to re-merge these files is necessary, creating a "merged master". To do this, you can use TES4Gecko's Merge to Master function to temporarily put everything back into a single file so you can work with it in the TESCS. | ||
Start by making a copy of OOO, called something like OOO_scythes.esp. As long as you're just altering things that already exist in OOO, make all your changes | Start by making a copy of OOO, called something like OOO_scythes.esp. If you're working with the OOO 1.32 merged master (as described above), then you must use Wrye Bash ''Copy to esp'' command to do this. As long as you're just altering things that already exist in OOO, make all your changes in OOO_scythes.esp using TESCS. If you need to add anything new to it, then hold back on making those changes until later in the process. | ||
Once you have the changes done, make a backup copy of your changed plugin just in case something goes wrong, then use TES4Gecko to ''Create Patch'' using Oscuro's_Oblivion_Overhaul.esp as the original and OOO_scythes.esp as the patch. This will create a new TES4Gecko patch file called OOO_scythes.esu. Now you can simply change the .esu extension to .esp and you're ready to move on to the next step. | Once you have the changes done, make a backup copy of your changed plugin just in case something goes wrong, then use TES4Gecko to ''Create Patch'' using Oscuro's_Oblivion_Overhaul.esp as the original and OOO_scythes.esp as the patch. This will create a new TES4Gecko patch file called OOO_scythes.esu. Now you can simply change the .esu extension to .esp and you're ready to move on to the next step. | ||
| Line 143: | Line 159: | ||
Alternately, you can use ''Display/Copy Plugin Records'' or ''Compare Plugins'' in TES4Gecko to Ignore everything except the changed entries. You can quickly Ignore large blocks of stuff by simply doing group-level ignores on record groups you know you don't need. When you're done, save the plugin, and you'll see all the Ignored entries vanish. | Alternately, you can use ''Display/Copy Plugin Records'' or ''Compare Plugins'' in TES4Gecko to Ignore everything except the changed entries. You can quickly Ignore large blocks of stuff by simply doing group-level ignores on record groups you know you don't need. When you're done, save the plugin, and you'll see all the Ignored entries vanish. | ||
Regardless of which method you used, you'll next want to fire up Wrye Bash, right-click OOO_scythes.esp, select ''Add Master'' from the context menu, and pick | Regardless of which method you used, you'll next want to fire up Wrye Bash, right-click OOO_scythes.esp, select ''Add Master'' from the context menu, and pick either "Oscuro's_Oblivion_Overhaul.esp" (if you started with OOO 1.31) or "Oscuro's_Oblivion_Overhaul.esm" (if you started with OOO 1.32). | ||
After doing this, re-select your mod, look in the dependencies window (small pane in lower-right of screen), and check to make sure the new master record was added. This will make your OOO_scythes.esp dependent on the Oscuro's_Oblivion_Overhaul.esp and will make your changed scythe records override the normal ones in that mod. | |||
When you play, you'll of course want to put your OOO_scythes.esp after OOO in the load order, but that's really all there is to doing it. | When you play, you'll of course want to put your OOO_scythes.esp after OOO in the load order (so its changes override the original), but that's really all there is to doing it. | ||
This way a single OOO_scythes.esp can, for example, be used with either the FULL or LITE versions of the Oscuro's_Oblivion_Overhaul.esp, and it will almost certainly be completely compatible with future versions of OOO -- only minor adjustments would be needed if future versions of OOO make new changes to those specific items (or the leveled lists you added them to), but at least you don't have to worry about changes anywhere else in OOO. | This way a single OOO_scythes.esp can, for example, be used with either the FULL or LITE versions of the Oscuro's_Oblivion_Overhaul.esp, and it will almost certainly be completely compatible with future versions of OOO -- only minor adjustments would be needed if future versions of OOO make new changes to those specific items (or the leveled lists you added them to), but at least you don't have to worry about changes anywhere else in OOO. | ||
Now, if you want to add some new content as well, and you want to make sure it doesn't have a problem when the next version of OOO comes out, then you' | Now, if you want to add some new content as well, and you want to make sure it doesn't have a problem when the next version of OOO comes out, then you must make sure the new content isn't accidentally given the same master relationship as the changes. In other words, you need to make sure that any new content is stored in the local modindex rather than the master modindex. Otherwise your new content will be "injected" into the master and could potentially collide with other new data added there by the mod author in an update. However, the details on how to deal with issues like this would be a good subject for another tutorial since it's a bit out of the scope of this article. | ||
One other possibility worth considering if you're only making changes and not adding anything new. Once you've finished making all your changes and chopping the plugin down to only include the records you changed, you can make it into a patch file. To do this, all you have to do is change the file extension to .ESU instead of .ESP. This allows TES4Gecko to recognize the file as a patch and you can use the ''Apply Patch'' function to add your changes back into OOO after the update is released. | One other possibility worth considering if you're only making changes and not adding anything new. Once you've finished making all your changes and chopping the plugin down to only include the records you changed, you can make it into a patch file. To do this, all you have to do is change the file extension to .ESU instead of .ESP. This allows TES4Gecko to recognize the file as a patch and you can use the ''Apply Patch'' function to add your changes back into OOO after the next update is released. | ||
== Credit == | |||
The original version of this article is located [http://devnull.devakm.googlepages.com/deisolation here]. | |||
[[Category:Tutorials]] | [[Category:Tutorials]] | ||