Difference between revisions of "Creating Large Worldspaces"

m
Fixed typo.
imported>UDUN
imported>Falchya
m (Fixed typo.)
Line 29: Line 29:
When working on worldspaces 4 quads or larger, you should convert the worldspace to a [[Glossary#E|.esm]] regardless of how you intend to release that mod. There are two reasons for this. 1, by using a .esm which just has .esp files merged into it, you always retain a backup of the worldspace at the last point of merging, so if you screw up something horribly while heightmapping, you don't have to start from scratch (should still make backups of those .esm files). 2, due to limitations in the CS and your system, working on too many cells can lead to severe instability and/or frequent crashing. The more cells a worldspace has, the more it needs to load into memory while you're working on it. .esp files larger than 40mb (8 quads) usually cannot be loaded in the CS without some sort of error popping up. Even if you are only using 4 quads for your worldspace and plan to release as a .esp, you will still want to use a .esm during creation just so that you can take advantage of the benefits of this format.
When working on worldspaces 4 quads or larger, you should convert the worldspace to a [[Glossary#E|.esm]] regardless of how you intend to release that mod. There are two reasons for this. 1, by using a .esm which just has .esp files merged into it, you always retain a backup of the worldspace at the last point of merging, so if you screw up something horribly while heightmapping, you don't have to start from scratch (should still make backups of those .esm files). 2, due to limitations in the CS and your system, working on too many cells can lead to severe instability and/or frequent crashing. The more cells a worldspace has, the more it needs to load into memory while you're working on it. .esp files larger than 40mb (8 quads) usually cannot be loaded in the CS without some sort of error popping up. Even if you are only using 4 quads for your worldspace and plan to release as a .esp, you will still want to use a .esm during creation just so that you can take advantage of the benefits of this format.


When testing your .esm, always have it loaded in the 01 index so that extra steps (in particular moving worldspaces and removing vwd references from trees) aren't needed in order to get an idea of what the terrain really looks like. If you don't know how to do this, you may wish to take a few moments with [Oblivion Mod Manager] or WyreBash to learn how to manage your load order. If placing your .esm in the 01 index interferes with other mods, you may just want to create a new character with only your worldspace active and just cheat your way to this space.
When testing your .esm, always have it loaded in the 01 index so that extra steps (in particular moving worldspaces and removing vwd references from trees) aren't needed in order to get an idea of what the terrain really looks like. If you don't know how to do this, you may wish to take a few moments with [Oblivion Mod Manager] or Wrye Bash to learn how to manage your load order. If placing your .esm in the 01 index interferes with other mods, you may just want to create a new character with only your worldspace active and just cheat your way to this space.


For a particularly large worldspace, you have no option other than using .esm format for release, and will need to make adjustments related to this as far as connections, quests, and LOD data is concerned.  
For a particularly large worldspace, you have no option other than using .esm format for release, and will need to make adjustments related to this as far as connections, quests, and LOD data is concerned.  
Anonymous user