TR's method of dealing with ESPs
Posted: 17 Sep 2012, 01:53
I asked on the TR forums for some information about their methods of dealing with ESPs before merging their claims into the final TR_Mainland.ESM.
If we have somewhere around 251, this method should be pretty useful in separating up each area for each modder. It would let us keep each area separate until we're ready for the merge
It's a good read for anyone interested in the subject:
If we have somewhere around 251, this method should be pretty useful in separating up each area for each modder. It would let us keep each area separate until we're ready for the merge
It's a good read for anyone interested in the subject:
I bolded the last part, because it seems important. So I suppose we should focus on trying to get the landscape as finished as we can before we start in on giving out claims.arvisrend wrote:In a nutshell, here's the life of an int/ext claim at TR:
First, the claim gets done in a separate file which depends only on TR_Data.esm (not on TR_Mainland.esm).
Once it is reviewed, it ends up in the "finished" section of the forum.
These int/ext claims are then merged into detailing/NPC claims (a detailing/NPC claim is usually about 5 adjacent ext claims + whatever ints they should be linked to). These claims are then NPCed (which means that both creatures and NPCs are being added to them), bordermatched (i. e., mismatches in vertex coloring, height and ground texturing at the borders between the former ext claims are being fixed) and partially quested (although most quests nowadays are separate claims).
When all of these claims are done for a particular release, they all are merged into TR_Mainland.esm (actually it's an ESP file internally, since ESM's are annoying to work with). Again, border matching becomes necessary because the borders between distinct detailing/NPC claims have not yet been dealt with.
The Heartland release will work differently (there is a merged file with all exts out in the public already, although no NPCing and not very much bordermatching have been done yet), but normally it works as I said above.
Quest claims work differently and we haven't figured out yet what's the best workflow here. Normally we use the "ESP dependency" trick: Quest claims are NOT dependent on TR_Mainland.esp (or .esm), but only on .esm. However, they are always loaded in the CS alongside TR_Mainland.esp, so it is possible to reference NPCs from TR_Mainland.esp in them.
Oh, and we are using a pre-made heightmap for making the ext claims, so we don't have extreme slopes at the claim borders. And roads, too, are planned in advance, since they wouldn't match otherwise.