Difference between revisions of "De-Isolation Tutorial"

De-Isolation Tutorial (edit)

Revision as of 19:02, 17 July 2007

2,786 bytes removed , 19:02, 17 July 2007

rewrite

Anonymous user

imported>Dev akm

@@ Line 1: / Line 1: @@
+by dev_akm
-by dev_akm and Wrye
+'''UNDER CONSTRUCTION'''
-==Mod Isolation and De-Isolation==
+== Introduction ==
-Lets start with the confusing bit:
-* TESCS ''seems'' to allow you to make one esp dependent on another. When loading, you can turn on esps the same way you turn on esms, and their content will appear and be usable. But...
-* When you save your new plugin, TESCS will refuse to remember that the plugin was built on top of those other esps. If you then reload your newly created plugin, TESCS will then be lacking the internal references to connect it back to the esps you had loaded before, and you'll likely get lots of error messages and things generally won't work as desired. This is called '''Mod Isolation'''.
-* ''However...'' using external tools, it's possible to temporarily turn an esp into an esm. And having done that, TESCS will then allow you to establish dependencies on it.
-So, in short: the totally naive modder thinks you can make esps dependent on other esps; the more advanced modder thinks you can't; and the hyper-guru, master modders know that you can (with a little work). And here's how...
+Normally, when people make changes to a plugin, they just open it up in the CS, make their changes and save.
-==Esp Mastering with Wrye Bash==
+But this isn't always a good idea. Consider these scenarios:
-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.)
-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.
+# What if you have one large mod and want to offer several optional tweaks to various aspects of the main mod? Maybe it isn't a problem to have several versions on the first release, but how quickly are you going to get tired of repeating this process each time you update the main mod? Maybe you actually need the optional tweaks to be kept in separate add-on files?
-Having said all that, the process is actually quite simple:
+# What if you want to make tweaks to someone else's mod and you want to avoid having your changes wiped out by the next release of that plugin?
-* 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:'''
+# What if you want to use something from one of the official DLC mods? Distributing your altered version of an official plugin isn't a great idea, creating a binary patch (binpatch) for it is very cumbersome and prone to errors, and it's very likely that someone else may have the same idea (rendering your mods mutually exclusive).
-* 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.
-* The "Espify/Esmify Self" command is also useful for editing esm files. While TESCS will not ordinarily allow you to modify esm files, you can use the "Espify Self" command to turn them into esps that can be edited. However, there are limits on this -- not all files behave well when treated as esps (e.g. Oblivion.esm).
-== TES4Gecko and Wrye Bash (Somewhat Dated)==
+Mods based on Oblivion.esm don't have this problem because it's a '''master''' file (ESM). Multiple add-on plugins (ESPs) can alter it at the same time without any problems. Unfortunately, TESCS doesn't let you use plugins as masters, even though the game engine actually doesn't mind at all.
-'''Warning: The following section is rather dated, referring to and the older Bash Espify/Esmify command, and suggesting use of the "Add Master" command which is a bit dangerous. For simple esp-mastering, use the section above.'''
-Normally, when people make changes to a plugin, they just open it up in the CS and do it. But what if you want to avoid having your changes wiped out by the next release of that plugin? Here is a simple scenario where it makes a lot of sense to take advantage of mod "de-isolation" to preserve your changes in a separate plugin.
+== Mastering ==
+Many beginning mod creators get frustrated with TESCS because it seems to let you select Oblivion.esm and one or more ESPs in addition to your "active" file. The content from those ESPs will appear to be usable, but it's not. When you save your new plugin, TESCS will refuse to remember that your plugin was built on top of those other ESP files. If you then reload your newly created plugin, TESCS will then be lacking the internal references to connect it back to the ESPs you had loaded before, and you'll likely get lots of error messages and things generally won't work as desired.
+This behavior is known as '''Mod Isolation'''.
+Fortunately, there are several good strategies for how to get around this limitation. All such solutions involve either making your own actual master(s) or tricking the game into thinking you've got your own master(s). The latter technique is known as Mod De-Isolation.
+# '''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.
+: But masters should not modify other masters -- only plugins should 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), such as the official DLC plugins, then you will very likely 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. See [[ESP_Mastering|ESP Mastering]] for details.
+# '''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).
+Each of these methods will be explained in greater detail when this tutorial is completed. For now, here's one of the earliest methods.
+== ESP Patch De-Isolation Using TES4Gecko ==
+Here is a simple 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:
@@ Line 45: / Line 42: @@
 ''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 1.32 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 1.32 comes out. However, these instructions are fairly specific to OOO 1.31, which used one large ESP file (OOO 1.32 uses a split ESM/ESP pair).
 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 there. If you need to add anything new to it, then hold back on making those changes until later in the process.
@@ Line 65: / Line 62: @@
 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'll need to take a few more steps after this.
-The first thing to do, starting from where we left off, is to use TES4Gecko to split Oscuro's_Oblivion_Overhaul.esp into an ESM/ESP pair. This will create two new files, called OUTPUT_Oscuro's_Oblivion_Overhaul.esm and OUTPUT_Oscuro's_Oblivion_Overhaul.esp. The ESM created this way is clean and can safely be used in the CS since it only contains the new records added by OOO.
-First, rename the OUTPUT_Oscuro's_Oblivion_Overhaul.esm to Oscuro's_Oblivion_Overhaul.esm. Next, in Wrye Bash, use ''ESMify Masters'' to make your plugin dependent on Oscuro's_Oblivion_Overhaul.esm instead of the ESP. Now, launch the CS and select your OOO_scythes.esp as the active file. You'll get a few error warnings about missing targets, but it's safe to click "Yes to all" when see get this. It won't cause any problems.
-Proceed to add whatever new content you want, saving changes as you go. Once you're done, quit from the CS and switch back to Wrye Bash. Once again, use the ''ESPify Masters'' on your plugin to redirect its dependency to Oscuro's_Oblivion_Overhaul.esp and you're done!
-Now, if you know you're going to be adding some new stuff even before you start, then you can simplify the process a bit by using TES4Gecko to split OOO before making any changes. By using the OUTPUT_Oscuro's_Oblivion_Overhaul.esp as your active file in the CS, you can make all the changes and additions you want right there (you should probably rename it to OOO_scythes.esp first, though, just to be safe). Once you're done, you can then use the same process detailed above to Ignore the records you don't need. Since it will already be dependent on Oscuro's_Oblivion_Overhaul.esm, you don't need to do the ''Add Master'' step.
-You will still need to run the ''ESPify Masters'' command to redirect your dependency to Oscuro's_Oblivion_Overhaul.esp after you're done working in the CS. If you discover that you need to make a few more changes after testing in-game, don't forget to use the ''ESMify Masters'' command before opening your plugin back up in the CS.
+I'll get to that on the next update of this tutorial.
 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.