Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bsa
11-30-2010, 05:27 PM,
#11
 
Quote:Originally posted by morcroft
The main Elsweyr.esm contains all the heightmap data, and it and the gecko-split esp are dependant on the resources.esm. I find the huge heightmap makes the main file slow and unstable to work with as an esp - I know I'll merge all changes into it as an esm with Gecko in the long run, but right now the resources are in constant flux and I'd rather be able to work with them freely.

Like I said before, I'm not saying any of this is right and I really welcome any input. I'm pretty new at this.
I assume the resources esm is directly loaded after the OB esm (Mod index 01).

For modding just load the heightmap data as an esm.
Using an esp will reach a limit depending on your comp., on average around 25-30Mb and it's unstable as you said. If it reaches the limit you have to use an esm otherwise the CS will crash. Using an esm diminishes the loading time.

This will work for modding, for play-testing you have to convert the esm (with the height data in mod index 02, depending on the resources esm in mod index 01) to an esp.

In any case you have to maintain two esm's (and one esp for play-testing) which is waste of time.
For ST and BM I use one esm.


Quote:Originally posted by morcroft
Tried TES4Edit once, briefly, and didn't get on with it. Probably just me.

I use TES4Gecko and love it for all mod management stuff - although I don't think it has a BSA builder so I actually build the BSA's with OBMM, which is super-easy once you find the option.
Bsa's have to be made with other tools like bsa commander etc.

If you understand the record/Form ID structure (advanced users) TES4Edit is very handy tool, especially when fixing problems.

For maintaining an esm use the Gecko, I know because I helped to develop this tool with SACarrow.


Quote:Originally posted by The Old Ye Bard
I have however said a seperate .esm for resources, and then a seperate one for all the world data, which is the standard for all the large worldspace mods.
Standard?

If you have to merge a lot of files it's a waste of time (resource eps's and modded content esp's).

Or do you keep the modded content (e.g. interiors linked to the exterior) in a separate esp?

If so, the esp size is limited (see above).



Resuming.

It's possible to use this system with two esm's however it's not very practical.

If it's standard what's the advantage?

I am advising several non BC projects, they also use one esm.
Dum loquor, hora fugit  - While I speak the time flies



Ovid 43 BC - 17 AD
Reply
11-30-2010, 08:00 PM,
#12
 
Thanks for clarifying that Sandor. I will definitely only use one esm, assuming I get to that point before I find a co-leader. This is going slowly. I also do testing over at TESAlliance and there are always my two teenagers to keep track of.
Reply
11-30-2010, 09:01 PM,
#13
 
Quote:Originally posted by sandor
This will work for modding, for play-testing you have to convert the esm (with the height data in mod index 02, depending on the resources esm in mod index 01) to an esp.

Why is it necessary to use an esp for play-testing? I've seen this mentioned before elsewhere but don't understand why you can't playtest with an esm.

BTW: Ysne, hope you don't mind me using your forum as a classroom, and Sandor thanks for taking time to go over this!
Morcroft Darkes
Reply
12-01-2010, 08:20 AM,
#14
 
Quote:Originally posted by morcroft
Why is it necessary to use an esp for play-testing? I've seen this mentioned before elsewhere but don't understand why you can't playtest with an esm.
To be clear, I am talking about a modding version (nver splitted) and not about a release version prepped to be completely load order independent (LOD in mod index 00 and splitted).

When testing Scripteron's TES4 Plugin Utility (prior to the Gecko) we discovered that the VWD objects like trees caused the missing land problem when loading an esm in mod index 02. That's why the split plugin (move the tree/VWD objects to the split esp) and move WS's (LOD, load order independent) functions were added.

As mentioned above it's one of the reasons we use a single esm in mod index 01 for modding (no missing land).

As I said in my other post you could convert the esm to an esp for playing, but it's not very handy.
Dum loquor, hora fugit  - While I speak the time flies



Ovid 43 BC - 17 AD
Reply
12-02-2010, 02:05 PM,
#15
 
Sorry, Sandor, I guess I'm being dumb but I still don't get why you need everything in an esp for playtesting.

Professionally I always try to test stuff with as close to a final release version as possible - and if that means repeatedly modifying a development pack and rolling that forward into a release version that then gets tested then it just means the release process gets a good testing as well.

One thing - surely the resource esm as we use it can go in any old mod index: it doesn't contain land info or placed objects so there shouldn't be a load-order dependency, should there? I understand that for modding we have to put the main esm in index 01 to avoid the missing land issue.
Morcroft Darkes
Reply
12-02-2010, 05:12 PM,
#16
 
Quote:Originally posted by morcroft
One thing - surely the resource esm as we use it can go in any old mod index: it doesn't contain land info or placed objects so there shouldn't be a load-order dependency, should there?
That's correct.

Quote:Originally posted by morcroft
I understand that for modding we have to put the main esm in index 01 to avoid the missing land issue.
An esm (never splitted) containing VWD objects like trees has to be in mod index 01 otherwise the land will disappear (cells containing VWD objects).

For playing convert it to an esp or split the esm after converting it to an esp (load order independent esm/esp pair).


This is a very technical discussion, if you have other questions just send a PM, NP.
Dum loquor, hora fugit  - While I speak the time flies



Ovid 43 BC - 17 AD
Reply
12-02-2010, 06:26 PM,
#17
 
Quote:Originally posted by sandor
This is a very technical discussion, if you have other questions just send a PM, NP.

Nope - I think that covers it, thanks very much Sandor - and sorry for cluttering your thread with techy stuff, Ysne!
Morcroft Darkes
Reply
12-04-2010, 06:12 PM,
#18
 
Quote:Originally posted by morcroft
Quote:Originally posted by sandor
This is a very technical discussion, if you have other questions just send a PM, NP.

Nope - I think that covers it, thanks very much Sandor - and sorry for cluttering your thread with techy stuff, Ysne!

Sometimes, clutter can be very useful. This was.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)