Moving Worldspace data : IV

» Mon Mar 14, 2011 5:30 pm

Can a large mod with limitations of tool use (ie., TES4Edit, Tes4Gecko) because of memory limitations on the ESM (java heap memory, file size memory limits, etc) be effectively reduced through moving Worldspace data into another ESM and yet remain independent of the other ESM sharing the same data? i haven't used TES4Gecko's move worldspace feature, but I also am wondering if it can filter specific areas instead of transferring an entire worldspace?

I read,

TES4Gecko->Merge to Master is your friend. It will very reliably re-assemble a complete single-file mod from a split mod. You can use this to merge each team member's changes into the common master.

Every team effort like this requires a careful process worked out beforehand, with someone who acts as the "build master" to merge up all the work from each team member on a regular basis. You'll need to test your process thoroughly before you go too far along so you can iron out any kinks in the process.

TES4Edit will also become critical for you since it will let you check detailed version diffs and resolve any issues that arise from the team process (such as overlapping changes and/or any problems that result from Merge to Master).

For example, when working on OOO, we often have to use Merge to Master to recreate the original single-file ESP it was started with (but including all recent changes), then make changes to the ESP, split it back out, compare against the previous version (i.e., checking the version diffs with TES4Edit->Compare to) to see that all the changes were good and repair any issues that came up. Since I've heavily tweaked the ESM/ESP structure by hand (i.e., beyond what a normal split will create), I usually then merge the new changes by hand into the previous version using TES4Edit.

- dev_akm

» Mon Mar 14, 2011 11:45 pm

I'll be a little more specific. I'm working a a very large mod, currently the ESM is at 500mb+. Since I've began to assume responsibility to organize and regulate QC on it, I've found that it's too large to use tools unless I revert to old versions. In accepting that alternative, I lose a lot of time and work which I would like to prevent. I know if I downsize, which I can, I'll be able to get tool features (as mentioned above) back. (1) My main question is to manage the mod more efficiently with the above tools (which means downsizing to probably around 200mb), which would likely mean transferring data to share in a separate ESM, but while doing this will it require the 2 separate ESM to be dependent on each other if they share one worldspace?

example:
ESM (1) = has worldspace ; plus regions 1-10
ESM (2) = has worldspace ; plus regions 11-20

Where both ESM's have both the same worldspace names and definitions the actual block, sub-blocks, cells and content will be different according to the regions within each ESM, would this be suffiicient to split a large ESM and separate master dependency?

no reply needed; figured it out myself.