Difference between revisions of "Talk:Creating Large Worldspaces"

From the Oblivion ConstructionSet Wiki
Jump to navigation Jump to search
imported>Bruneauinfo
imported>Lanceor
 
(15 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=== A Few Notes ===
=== More Notes ===


'''TES4Geko''' - You don't have to worry about creating the shortcut properly if you run the program directly from the executable. This involves navigating to the executable's location each time you need to use it and running it from the installed location. Not as convenient of course, but it still gets the job done.
As for region generation I'm not so sure the 'requirements' listed for deleting content in bordering regions is really necessary. I'm running a rather large experiment on the whole subject for the next couple days. But I think it's been over complicated a little in the original article. --[[User:Bruneauinfo|Bruno]] 17:14, 16 January 2011 (EST)


'''Oblivion.esm''' - Is loading Oblivion.esm really necessary for creating a new world space? Doesn't this just set Oblivion.esm as a dependency for your New World? I just tested this and was able to create a new world space without Oblivion.esm. And after creating the new world space I was still able to load both Oblivion.esm and my new world space ESM files without error.
I'm applying a different method here:


'''Final Editing''' - I have a few notes in reference to making corrections in large world spaces to "sew together" the borders between quads.  
1 - I'm not worrying about having my region borders separate from my region content. First of all because it's not practical when creating a large worldspace. The potential for errors in locating region borders is tremendous. I followed the region borders instructions to the best of my ability. I then merged with the .esm. However, in many, many cases during region content generation I've already deleted some region borders and completely reconstructed them with no apparent side effect.  


*The greatest number of errors (rips) on a texture are created in the hightmap editor where land is not properly blended before saving the texture. Any large, abrupt changes in elevation are prone to tearing. These are indicated by hard lines between two colors. There should be no hard lines left on your texture in the hightmap editor when you save it. Make sure all hard lines are blended with either the blending tool or the noise tool.
I lieu of the instructions I've defined all my regions generally. Next I go back into these regions and break them up into small bite-sized pieces (12-15 cells). From my testing it appears that a region twice the size of another region with the same content takes exponentially more time to generate content as the smaller of the two. It actually takes less time to break the larger one in half and generate it in two parts than it does to generate it all at once. A LOT less time. The smaller the region the more productive you will be. So I think I can recommend breaking large regions down into ones containing no more than 12 to 15 cells.


*Additionally, in reference to the above note tears can be prevented at the exterior perimeter of your New World by blending the last few cells into the water rather than having the land just suddenly stop and drop off. Blending can be done with the blending tool or with the noise tool depending on the terrain type you want at these locations.
On the other hand, if your region content data is not creating a lot of objects the above suggestion can be ignored for the most part.  


*For World Spaces larger than 4 quads: When blending the borders between quads in the landscape editor it isn't necessary to to blend these perfectly to your finished specifications. Getting a good finished product can be just as time consuming in the landscape editor as it is in the heightmap editor with all of its seeming random error generation. Here is my suggested methodology keeping in mind the rest of the article's instructions:
2 - As for deleting content in neighboring regions? I've dispensed with that suggestion entirely. I've done up-close inspections of neighboring regions where this suggestion was followed and where it was not followed - in fact abused excessively and intentionally - and found no evidence of objects being copied on top of each other. If this is happening it is minute and the suggestions for avoiding it seem more expensive time-wise than just manually deleting unnecessary objects. --[[User:Bruneauinfo|Bruno]] 18:05, 16 January 2011 (EST)


1 - Design and finish the layout of 4 quads
===Other Issues===


2 - Save in the heightmap editor
This -> '''"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."''' <-- Is a little misleading. If you generate a region and found you have objects, spacing, etc that you don't like, you can remove the entire contents of the region, make adjustments, and generate the region again. And you can do this at any time during region generation. Yes, you won't want to do this after you start placing special objects like structures and NPCs, but common sense would dictate that you get your worldspace in order first before adding your game content. --[[User:Bruneauinfo|Bruno]] 14:40, 17 January 2011 (EST)


3 - Make error corrections in the landscape editor, save, and create .esm
The article mentions removing "viewable when distant" flags i.e. vwd flags. I've searched the internet via google and asked a lot of questions. Looking at [[TES4LODGen]] it appears the program no longer requires vwd flags be removed for proper operation. So I've edited the article to reflect this. --[[User:Bruneauinfo|Bruno]] 15:40, 20 January 2011 (EST)


4 - Start new .esp and design/finish the layout of the next 4 quads
=== Old Notes ===


5 - Save in the heightmap editor
(Content moved to body of article.) --[[User:Bruneauinfo|Bruno]] 14:01, 16 January 2011 (EST)


6 - Make error corrections in the landscape editor, save, and merge with the .esm
:This all looks very good - why not include it in the main article proper? Yours looks ''better'' than what's there, for that matter!
:[[User:DragoonWraith|<span style="font-family: Oblivion, Daedric Runes; size=2;">D</span>ragoon <span style="font-family: Oblivion, Daedric Runes; size=2;">W</span>raith]] [[User_talk:DragoonWraith|<span style="font-family: Oblivion, Daedric Runes; size=2;">TALK</span>]] 15:07, 15 January 2011 (EST)


7 - Repeat above steps designing additional quads following this pattern and merge
::I've noticed I have three stages of editing information:
::1 - I try to find and follow directions.
::2 - I find things about the directions I think are faulty and so I edit the directions
::3 - Time passes and some or all things I thought were bunk end up being true. So I go back and edit them again.


8 - After all heightmaps are created and merged start a new esp
::So instead of doing 2 in the main article, I thought it would be best to put my notes in the Discussion area first so as not to look like a fool and screw someone else up in their endeavors. :-D --[[User:Bruneauinfo|Bruno]] 14:01, 16 January 2011 (EST)


9 - Edit the borders in the heightmap. Multiple esps will be required for large worlds. Merge each "border-edit" esp with the esm as they are created. Also as you edit the borders scan the heightmap your working on for errors and fix them as you go. These will appear as sharply contrasted squares/rectangles.
:::OK, fair enough; carry on then. Excellent work all around! That's even better, honestly - I appreciate you checking back and correcting misunderstandings even more than the initial commentary, heh!
:::[[User:DragoonWraith|<span style="font-family: Oblivion, Daedric Runes; size=2;">D</span>ragoon <span style="font-family: Oblivion, Daedric Runes; size=2;">W</span>raith]] [[User_talk:DragoonWraith|<span style="font-family: Oblivion, Daedric Runes; size=2;">TALK</span>]] 16:45, 16 January 2011 (EST)


10 - After all borders are edited use the landscape editor to correct errors in conjunction with the heightmap editor. DO NOT make corrections with the heightmap editor at this time, and DO NOT save any more textures in the heightmap editor. At this time you will only use the heightmap editor for finding errors in your textures. Make the actual corrections using the landscape editor. Merge with the esm.
=== VWD Removal ===
 
Quote: '''Once you have trees and other content, you will also need to clear out all the VWD flags for your world space using TES4Edit in order for your world space to show correctly when loaded anywhere other than the 01 index. You would need to do this cleaning after every change which adds more trees, but thankfully, you only need to clean out those things which were added/moved. (Note: This final note has still not be verified in recent testing.)''' I've verified this to be correct. If nobody objects, I'll remove the final sentence in parentheses. There is a discussion that I started regarding this issue at http://forums.bethsoft.com/topic/1361740-move-worldspaces/ . [[User:Lanceor|Lanceor]] 07:57, 1 April 2012 (EDT)

Latest revision as of 06:57, 1 April 2012

More Notes[edit source]

As for region generation I'm not so sure the 'requirements' listed for deleting content in bordering regions is really necessary. I'm running a rather large experiment on the whole subject for the next couple days. But I think it's been over complicated a little in the original article. --Bruno 17:14, 16 January 2011 (EST)

I'm applying a different method here:

1 - I'm not worrying about having my region borders separate from my region content. First of all because it's not practical when creating a large worldspace. The potential for errors in locating region borders is tremendous. I followed the region borders instructions to the best of my ability. I then merged with the .esm. However, in many, many cases during region content generation I've already deleted some region borders and completely reconstructed them with no apparent side effect.

I lieu of the instructions I've defined all my regions generally. Next I go back into these regions and break them up into small bite-sized pieces (12-15 cells). From my testing it appears that a region twice the size of another region with the same content takes exponentially more time to generate content as the smaller of the two. It actually takes less time to break the larger one in half and generate it in two parts than it does to generate it all at once. A LOT less time. The smaller the region the more productive you will be. So I think I can recommend breaking large regions down into ones containing no more than 12 to 15 cells.

On the other hand, if your region content data is not creating a lot of objects the above suggestion can be ignored for the most part.

2 - As for deleting content in neighboring regions? I've dispensed with that suggestion entirely. I've done up-close inspections of neighboring regions where this suggestion was followed and where it was not followed - in fact abused excessively and intentionally - and found no evidence of objects being copied on top of each other. If this is happening it is minute and the suggestions for avoiding it seem more expensive time-wise than just manually deleting unnecessary objects. --Bruno 18:05, 16 January 2011 (EST)

Other Issues[edit source]

This -> "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." <-- Is a little misleading. If you generate a region and found you have objects, spacing, etc that you don't like, you can remove the entire contents of the region, make adjustments, and generate the region again. And you can do this at any time during region generation. Yes, you won't want to do this after you start placing special objects like structures and NPCs, but common sense would dictate that you get your worldspace in order first before adding your game content. --Bruno 14:40, 17 January 2011 (EST)

The article mentions removing "viewable when distant" flags i.e. vwd flags. I've searched the internet via google and asked a lot of questions. Looking at TES4LODGen it appears the program no longer requires vwd flags be removed for proper operation. So I've edited the article to reflect this. --Bruno 15:40, 20 January 2011 (EST)

Old Notes[edit source]

(Content moved to body of article.) --Bruno 14:01, 16 January 2011 (EST)

This all looks very good - why not include it in the main article proper? Yours looks better than what's there, for that matter!
Dragoon Wraith TALK 15:07, 15 January 2011 (EST)
I've noticed I have three stages of editing information:
1 - I try to find and follow directions.
2 - I find things about the directions I think are faulty and so I edit the directions
3 - Time passes and some or all things I thought were bunk end up being true. So I go back and edit them again.
So instead of doing 2 in the main article, I thought it would be best to put my notes in the Discussion area first so as not to look like a fool and screw someone else up in their endeavors. :-D --Bruno 14:01, 16 January 2011 (EST)
OK, fair enough; carry on then. Excellent work all around! That's even better, honestly - I appreciate you checking back and correcting misunderstandings even more than the initial commentary, heh!
Dragoon Wraith TALK 16:45, 16 January 2011 (EST)

VWD Removal[edit source]

Quote: Once you have trees and other content, you will also need to clear out all the VWD flags for your world space using TES4Edit in order for your world space to show correctly when loaded anywhere other than the 01 index. You would need to do this cleaning after every change which adds more trees, but thankfully, you only need to clean out those things which were added/moved. (Note: This final note has still not be verified in recent testing.) I've verified this to be correct. If nobody objects, I'll remove the final sentence in parentheses. There is a discussion that I started regarding this issue at http://forums.bethsoft.com/topic/1361740-move-worldspaces/ . Lanceor 07:57, 1 April 2012 (EDT)

Retrieved from "https://cs.uesp.net/w/index.php?title=Talk:Creating_Large_Worldspaces&oldid=34519"