I imagine Bethesda uses Perforce or something along those lines. In the last maybe 5 years or so every project I have worked on whether it was with Valve, Activision, Id, EA, even Zenimax it seems to be the general practice to use Perforce or some derivative. What these programs do is store all the files for a game on a server and in order for anyone to edit them they have to have a login and check the files out like you check out books in a library. This way anyone can see who has what files checked out and it warns you if someone already has that file. You can see who checked things in and you can read the comments to see what changes they made. Its not some super Geck version its more about the support for software like perforce or simply the inclusion of that software in the pipeline.

This thread helped me out allot with my question before though. Thanks pkleiss.
I believe I want to begin working in this manor from now on if its possible. I hope FO3edit is setup properly to handle this work flow effectively.

I copied this from Miaximus' FO3Edit manual.


This requires the copied file to be above the recipient file. This leads me to a new question.
If we are updating to a master, the master will need to be higher in the load order. If the master is higher, it will not be the file that is merged into. Take an example of two ESP that have been modified by two team members: Member1.ESP & Member2.ESP. Member 1 holds the Master.ESM as well. The load order would have to be like this:

Master.ESM
Member2.ESP
Member1.ESP

In this case, after using FO3Edit's "Deep copy as override into?" function, Member1.ESP will necessarily have to become the new master file, yes?
It seems to me that there is no way to merge the ESP files into the ESM as the last file is the recipient and ESMs must load before ESPs, right?
If Member1.ESP and Member2.ESP were originally setup as children of Master.ESM and Falout3.ESM, would the new Member1.ESP (now holding all the records) present a problem with the fact that the Member2.ESP records were Dependant on Master.ESM, which is no longer available?
It would be imperative that the new Member1.ESP have no dependency on Master.ESM any more so that it can be converted to an ESM to repeat the Work Flow process. Is this the case?

Anyway, I want to try out the work flow idea, but am still a little apprehensive until I fully understand the ramifications of all the steps involved.

If Member1.ESP and Member2.ESP both share a common master, neither of them need be dependent upon each other. If Member1.ESP needs to reference any forms from Member2.ESP, those forms would have to be injected into Master.ESM. Both Member1.ESP and Member2.ESP can reference each others' injected forms without them even being in Master.ESM (http://i196.photobucket.com/albums/aa150/JustinCoherent/SCRForms.png)

Once new forms are established as 'keepers', they should be copied (upward) into Master.ESM so neither Member1.ESP nor Member2.ESP have references intact by injection only. If Member A and B were to "Change Form ID" and target the same version of Master.ESM with completely different forms, they would end up overlapping each other as the renumbering of form ID's is determined according to the Next Expected Object ID (NOID). To avoid the NOID, member A should take their turn with merging, then pass off the file to member B or change the NOID value of Master.ESM to a higher value before preparing to merge new records so both team members don't try to claim the same Form ID's.

Whatever they use seems to allow Master.ESM to reference uninjected forms from Member1.ESP and Member2.ESP even if Master.ESM is loaded or active between the two. In multiple cases, the DLC files had references to out of range Form ID's which evidently originated in equivalents to Member1.ESP and Member2.ESP. Check out

• OA:
  • AudioExtAnchorageBunker [REGN:XX004403] <-best example
  
  
• TP
  • [INFO:XX001028]
    
  • DLCPittAutoAxeToolAnimObject [ANIO:XX009ADC]
  
  
• PL:
  • [INFO:XX008855]
    
  • [NAVM:XX00CE43]
    
  • [REGN:XX003E31]
  
  
• MZ:
  • [REFR:XX006DBB]
    
  • [REFR:XX006DBE]

It looks like their tools allow the active plugin to reference stuff loaded before and after. :shrug: just a hunch.

Perhaps I was unclear with what I was asking in my proir post...

Some Caveats:
1) Member1.ESP and Member2.ESP have no dependancy on each other. They represent two seperate pluggins to Master.ESM and contain new content that does not overlap. Lets say Member1.ESP contains new scripts to be added to the Master.ESM and Member2.ESP has added clutter to cells in Master.ESM
2) Ultimatatly Member1.ESP and Member2.ESP need to be merged into Master.ESM to create a new Master.ESM; Member1.ESP and Member2.ESP will become obsolete after the merge.
3) From the FO3Edit manual under 6.4 Merging a Plug-in into another Plug-in or Master, it states that the load order determines which file will be the reciepiant of the merged records, namely the last file in the load order.
4) The master files must load before pluggin files, therefore the master cannot be the file that recieces the merged records.
5) Can two files be merged simultaneously, or do they have to merged in seperate instances?

Based on this load order: (and is this the proper load order(s)?)

Master.ESM
Member2.ESP
Member1.ESP

or

Master.ESM (step 1)
Member2.ESP

and

NewMember2.ESP (step 2 - merged from Master.ESM and Member2.ESP in step 1)
Member1.ESP

1) Member1.ESP will contain the merged records of Master.ESM and Member2.ESP (Yes or No)?
2) Member1.ESP will still have Master.ESM set as a master file dependancy (Yes or No)?
3) Member1.ESP will have to be converted to NewMaster.ESM and Master.ESM will be deleted along with Member2.esp (YES OR No)?
4) It would be imperative that the new Member1.ESP have no dependency on Master.ESM any more so that it can be converted to an ESM to repeat the Work Flow process. Is this the case?

Or to rephrase the question, given the three files as stated above, what are the exact steps needed to merge the two ESPs into the Master.ESM such that their is only one Master.ESM when finished?

My main concern is that if I have to merge the master into the pluggin, won't the pluggin still have a master dependancy?
I hope this is clear...

Why merge down (ESM into esp)? Merge upward (Member2.ESP & Member1.ESP into Master.ESM). This will ensure all the form ID's are unique as it's far less likely to have multiple records with the same Form ID's merging the .esp's into the ESM. The master can be the recipient of the merged records. Multiple files can be assimilated in the same session by multiselecting all native forms from the assimilatee and "Change Form ID" selecting Master.ESM as the target, then copying as override.

• Start with
  
  • [BORG].ESM
    
  • Enterprise.esp (Add master, select [BORG].ESM)
    
  • KlingonVessel.esp (Add master, select [BORG].ESM)
  
  
• Inject all forms from esp(s) into Master .ESM so you have
  
  • [BORG].ESM
    
  • Enterprise.esp (Muiltiselect all native forms and "Change Form ID", select [BORG].ESM as the target plugin)
    
  • KlingonVessel.esp (Muiltiselect all native forms and "Change Form ID", select [BORG].ESM as the target plugin)
  
  
• Then copy as override all records you want from both into Master.ESM
  
  • [BORG].ESM
    
  • Enterprise.esp (Copy as override all injecting forms into [BORG].ESM)
    
  • KlingonVessel.esp (Copy as override all injecting forms into [BORG].ESM)
  
  
• In the end all you need is...
  
  • [BORG].ESM

Okay, thanks JustinOther. I was hoping that was the way to do it. I had it in my head that ESMs had to load first in FOMM, but that is only for gameplay it seems. Rearranging load orders for merges is completely unrelated to load order for gameplay. So I am good to go now.
Thanks for clarifying this for me.
BTW- nice Trek anology.

FO3Edit will not let an ESP/esp (flase-flag or not) load after a bona fide or false-flag ESM/ESP, nor will the game engine, so even if FOMM shows an esp loading above an ESM, the ESM will still load first. I think maybe it's confusing about the up/down description. I think of 'top' as [00] Fallout3.ESM although as an anology sometimes [00] is the foundation or bottom. http://www.mediafire.com/download.php?mmizuurfiyz's some plugins which demonstrate the merging process I use and swear by. If you liked the Star Trek reference, you'll love that pack.

Ok, I'm back to being confused again.

JustinOther said:


Miaximus' FO3Edit says:


Forgive me if I sound like an idiot, but I keep seeing contradictions.
From what you say, the load order of the three files should be:

BORG.ESM
Enterprise.esp
KlingonVessel.esp

From what Miaximus says, based on this load order, KlingonVessel.esp is the only file that can be the recipient of the merge, not BORG.ESM

In his example from the FO3Edit manual, the load order of the two files are:

Destructible Building Materials 3000.esp
500_Rads_Bar.esp

In his example its 500_Rads_Bar.esp that is receiving the merged records from DBM3000.esp. 500_Rads_bar.esp is being loaded after DBM3000.esp.

Do you see my confusion?

Check out http://www.gamesas.com/bgsforums/index.php?showtopic=1003825&st=160&p=15039299&#entry15039299 and the answers to it. Making a merged patch (Downward) is different than assimilation (upward). I you want multiple files' records to all end up in the same place, merge up into the file you're going to keep.

I think much of the confusion is over 'up' vs. 'down'. For clarity's sake, what's at the 'top' of your load list? Fallout3.ESM, right? Then again, which plugin has the 'lowest' load index? Also Fallout3.ESM. Therein lies the confusion, I think. When I say 'up', I'm referring to whichever plugin is loading first, thus BORG.ESM is loading before Enterprise.esp and Klingon.esp and both esp's records are assimilated 'up' into BORG.ESM. Look at the four stages in that pack and it should make perfect sense.

After a successful merge:

[00] Fallout3.ESM
[01] [BORG].ESM <---Keep
[02] Enterprise.esp <--Toss
[03] KlingonVessel.esp <--Toss



Elminster's reply is definitely suggeting the same approach as it's impossible (for us) to add Enterprise.esp to [BORG].ESM's master list. When he says 'down', he means it relative to load index/Form ID.

ModA : BORG :: ModB : Enterprise

That make more sense now?

This can also be done with FO3 Plugin. The team members could work on their own projects, then merge them seamlessly in just a few seconds using FO3 Plugin. I did this for my own mod, dividing the things I needed to do into various groups (e.g., "armor", "weapons", etc.), then merged them all together into a single esp file at the end. I've also used this to merge bits and pieces of other mods into a compilation esp; the bits and pieces came from several hundred mods downloaded from Nexus, and the only problem I've run into so far is that FO3 Plugin sometimes insists that the merging mod has the same master set as the merged-to esp (easy to do in the GECK). I found FO3 Plugin to be much easier to use, and far faster when it comes to merging.

If you need to overwrite something, FO3 Plugin will also do that without any problems as well.

Don't get me wrong; FO3Edit is a great tool, and I use it to 'clip out' the bits and pieces of mods I want to use, throwing away the stuff I don't want. But right tool for the right job, and FO3 Plugin is the right tool for merging esps.

Although it might take longer to merge with FO3Edit, I still much prefer it. Depending upon what you're merging, FO3Plugin might or might not get everything as you want it while with FO3Edit, every override/conflict has to be addressed. Often, two versions of the same record will have different parts you want to keep, say destruction data for an object from one assimilatee, a script from another, and the model is re-routed by yet another plugin. The only way to ensure you don't inadvertently overwrite anything you want to keep is merging by hand with FO3Edit. If using FO3Plugin to merge plugins entirely comprised of new forms, it's probably a faster option and certainly easier, but when merging plugins which override [00] forms, FO3Edit takes the gold as you have to make all those little decisions while resolving conflicts rather then it all being automated.

This is exactly what I am hoping to try. I am going to give this a shot tomorrow.
I am lightly curious what little changes I will notice about how my world space and cells behave when I convert the entire esp into a esm.
I also seriously wish I knew about how this works when I first started working on my overhaul.

Thanks for the input, but I have to agree with JustinOther that FO3Edit is a much better tool overall for this stuff. FO3Plug-in can do basic merges well, but it neglects alot of other functions that modders Should use (like MasterUpdate). Its alot easier in my view to learn one tool, and learn it well, and FO3Edit can do the whole gambit of tasks that a modder needs.

FO3Plug-in is great for certain situations, but I would still recommend FO3Edit for merging and mod manipulation as the best tool for the job.

Miax

I guess with that said. Just in terms of combining esp files into a single master file. What do I need to watch out for while using FO3Edit?
Or rather what are the weakest points of FO3Edit for this kind of process?

Forgot to mention it, in Project Valhalla. We used SVN version control. This worked pretty well, later we merged everything together with FO3Edit if it was needed.

Alright maybe it is just late but I have been messing around with merging a plugin into a esm. I am missing some important detail.
Currently what I am doing is I load up my esm and begin making changes then when I save it I specify the name of the new.esp.
SO now I have

CT_Chapter1.esm
CT_C1Workfile1.esp

So at the end of the day all I want is the ability to simply take everything that is in CT_C1Workfile1.esp and dump it into CT_Chapter1.esm
However I cannot do this as FO3Edit says "The required master "CT_C1Workfile1.esp" can not be added to "CT_Chapter1.esm" as it is a high load order."

I am sorry if I am asking a silly question here but what are the exact steps I need to do to merge this into the esm?
I plan to have my wife and a couple other people all working off the same esm in a similar manor. So I need to be able to combine everyone's work regularly.

Can anyone help me with this?

This was my exact concern from my earlier posts in this thread. From what JustinOther wrote, there must be a differnet command for merging "up" than merging "down". I still do not fully understand the steps either.

I don't quite understand it either....hopefully someone will figure it out and put up a set of instructions

Ok I got it thanks to Mezmorelda.
I was able to merge an esp into my main ESM with no problems at all using a program called FO3Plugin.

Here are the simple instructions to do this with this program.
It was off topic on this thread so you have to scroll down a bit.
http://www.gamesas.com/bgsforums/index.php?showtopic=1050175






Remember this is not FO3Edit that gave this error. It was a similar error that FO3Plugin gave me. But for very different reason than FO3Edit.



The only thing I can foresee being a problem at this point is getting FO3plugin to work because it requiers Java 1.6 to be installed. The readme.txt file for this program shows a good location to get a simple install for this.



Feel free to ask any questions if you need.

Before the forms can be copied upward (From 02 into 01), all 02 forms must be within 01's range. Multiselect as many 02 forms in one go as you can (Ctrl+ L-Click is your friend), then R-click -> "Change Form ID" -> "Choose target plugin" -> Select 01, and all selected 02 records will end up starting with 01 while the references will be kept intact as updating of references happens automatically when changing the form ID of more than one record at a time. When and only when each and every single 02 record has been injected into 01, "copy as override into" 01 and all previously 02 forms will now be 01 forms and can be assimilated leaving 01 to keep and 02 to discard.

Important: After assimilating 02 into 01, filter and 'clean' 02, then check everything left behind (if anything) manually as if 01 already overrode a 00 record and 02 further edits the same record, the additional info in 02 must be drug/dropped into 01, ensuring every edit actually makes its way into the keeper file. Subrecord data can often be manually meshed together into one version of the record to do it all with FO3Edit rather than simply choosing one version of the record or the other to take precedence.

Thanks JustinOther. I think this is exactly what was missing from this thread. :foodndrink:

I know I'd mentioned the changing form ID's part, but maybe hadn't emphasized it was imperative to do so before upward merging. Hope that makes more sense now.

'http://i196.photobucket.com/albums/aa150/JustinCoherent/Fallout%203/OrphanedReferences.png'. When copying any cell, worldspace, or dialogue records from one plugin to another, sometimes the copies will not be 'fostered' and will either A) be deleted unceremoniously and without warning by the GECK and/or B) cause crashes and other problems. They're really easy to overlook. If you copy records of those types, expand the trees in the recipient file and check for orphans, then delete them, reload, copy, recheck. Often, when copying Base Effect (MGEF) records, the Associated Script won't copy over and must be manually drug over to complete the merge. Other than those two issues, I've not had any other problems with FO3Edit's current build.

Interesting, I need to put this in the guide! Thanks for the bits.

Noting for future updates... :read:

Miax

Knowing is half the battle against the "Children". If a REF has an editor ID, it seems more likely to be orphaned after copying over. If any given REF or INFO has ended up orphaned in an FO3Edit session, one has to delete it/them and reload the program, then try again as that particular record will invariably end up orphaned if re-copied in the same session. To save time, if copying into an ESM with a large ONAM list, untick the ESM flag of the recipient file so you don't have to wait for it to build the ONAM list every session until all records are copied and fostered as they should be, then re-tick the ESM flag when done. If ever you encounter an INFO that just won't copy, you can manually add an empty info to the recipient's target topic and assign it the errant INFO's Form ID when doing so, allowing you to then drag/drop the subrecord data and all should work out.