Difference between revisions of "Creating Large Worldspaces"
→Notes
imported>Bruneauinfo |
imported>Bruneauinfo (→Notes) |
||
| Line 129: | Line 129: | ||
====Notes==== | ====Notes==== | ||
*For either custom or recycled regions you | *For either custom or recycled regions you should consider doing some small test patches (4 cells 2x2) with that region to see how it will texture and place things. Once you have a region to your liking, remove it and all objects generated by that region within the same CS session, and move on to testing the next region. '''DO NOT SAVE YOUR MOD WITH ANY GENERATED ITEMS IN YOUR WORLDSPACE AT THIS TIME, ALWAYS CLEAN BEFORE SAVING'''. Before defining actual region borders, save your mod, open it with TES4Gecko, and remove any entries which refer to edited cells. Merge this region mod so that the settings are contained within your .esm and can be reverted to later. Make a backup. Now, start a new .esp for your region borders. Only define the region borders '''DO NOT GENERATE THEM'''. | ||
This mod will have some small cell changes, so is not as easy to clean, which is why you did this as a separate .esp. Make sure it has no placed objects, then merge it. | This mod will have some small cell changes, so is not as easy to clean, which is why you did this as a separate .esp. Make sure it has no placed objects, then merge it. | ||
| Line 139: | Line 139: | ||
2) Once an object has been placed in a cell from region generation, and once that session has been saved and ended, the object can no longer be removed by that region. Meaning that if you want to change any settings related to region items, or have overlapping regions, you would have to manually remove them cell by cell if you've already saved the mod and started a new session. To make life easier, you should adopt a rather simple method of avoiding this problem all together. After every region you generate, select every bordering region and select "remove objects for this region". Even if you haven't generated that region yet, the region you generated placed objects slightly outside its border, and once saved, these objects may be doubled when that bordering region is generated later. This will leave only the space which exists only within the one region you generated as having items (the remaining parts will be mostly generated with those other regions. Save the mod, merge, and work on the next. For small regions, you can do more that one region per .esp, but should avoid generating regions which are near each other within the same .esp. For larger regions, you should keep it to a single .esp per region. | 2) Once an object has been placed in a cell from region generation, and once that session has been saved and ended, the object can no longer be removed by that region. Meaning that if you want to change any settings related to region items, or have overlapping regions, you would have to manually remove them cell by cell if you've already saved the mod and started a new session. To make life easier, you should adopt a rather simple method of avoiding this problem all together. After every region you generate, select every bordering region and select "remove objects for this region". Even if you haven't generated that region yet, the region you generated placed objects slightly outside its border, and once saved, these objects may be doubled when that bordering region is generated later. This will leave only the space which exists only within the one region you generated as having items (the remaining parts will be mostly generated with those other regions. Save the mod, merge, and work on the next. For small regions, you can do more that one region per .esp, but should avoid generating regions which are near each other within the same .esp. For larger regions, you should keep it to a single .esp per region. | ||
No doubt you're staring at this a bit confused. Just take your time and work through it one region at a time. For a 4 quad worldspace which is entirely generated, it is to be expected that you will be spending no less than a week doing little else other than generating objects if you are using several regions and region types (took me a little over 2 weeks when I did one 4 quad worldspace simply because I had to figure out most of this stuff and deal with crashes when the CS ran out of memory). For larger worldspaces, significantly longer. The downside however is that in order to make the landscape work right as a .esm without requiring it to be loaded in the 01 index, you will have to go through a few thousand tree entries in TES4Edit and remove the vwd flags. It's not as bad as it sounds since most of the work is just lots of clicking on the little + boxes and expanding cell information, but there isn't any sort of automated script which does this to my knowledge. You would also need to use TES4LodGen to generate distant objects afterward, but that's a fairly quick thing. | No doubt you're staring at this a bit confused. Just take your time and work through it one region at a time. For a 4 quad worldspace which is entirely generated, it is to be expected that you will be spending no less than a week doing little else other than generating objects if you are using several regions and region types (took me a little over 2 weeks when I did one 4 quad worldspace simply because I had to figure out most of this stuff and deal with crashes when the CS ran out of memory). For larger worldspaces, significantly longer. The downside however is that in order to make the landscape work right as a .esm without requiring it to be loaded in the 01 index, you will have to go through a few thousand tree entries in TES4Edit and remove the vwd flags. It's not as bad as it sounds since most of the work is just lots of clicking on the little + boxes and expanding cell information, but there isn't any sort of automated script which does this to my knowledge. You would also need to use TES4LodGen to generate distant objects afterward, but that's a fairly quick thing. | ||
== Dummy Terrain == | == Dummy Terrain == | ||