Multiple Team Members work on the same .ESP

[ManehattanProject]

This one's specifically for those who have done collaborations, specifically in the realm of level design.

 

I'm doing the primary level design for areas, creating the fundamental structure with hallways, rooms and lighting. After that's done, I'm going to pass it off to my "interior decorator" member of the team.

 

But I realized if I continue working on it, there's going to be problems because we'll end up in different versions of the mod since we have only a single mod for the actual levels. What's the best way to handle this?

 

Off the top of my head, here's a few ideas...but has anyone found an effective way to do this in practice? I really don't want to have to wait until the other person is done to work on another level.

 

• Create "mini-mods" that contain only the level in to be decorated, then use TESSnip or FNVEdit (I actually haven't found the entry on how to do this directly in FNVEdit yet) to copy the finished levels back into the primary mod, deleting the original levels and replacing them with the decorated ones.
• Duplicate the ENTIRE mod so the decorator has all of our custom assets (there's a lot) then just merge the level part back in.
• Divide the mod into separate sections for ONLY levels and then ONLY assets. (This would be difficult as we tend to create new assets as we go when we find a need for them) and then do something similar to Step 1 or 2.

Any suggestions?

 

 

[rickerhk]

I wouldn't let TesSnip touch my project. It was never updated for New Vegas. Record definitions have changed since FO3 and there are new ones. Plus it doesn't handle ONAM records at all.

Turn your main file into an esm. Everyone uses the same esm and makes new plugins with your esm as a master. Try not to over-lap each other. Periodically call in all the plugins for a merge (don't wait too long between merges). Everybody stops working till the merge is done and they have a copy of the new esm.

In the beginning when there is just world building (no scripting or quests) it's safe to just use FNVPlugin to merge esps (one at a time!) into the esm. Then you distribute the new esm. IMPORTANT - the esp's that were merged need to be discarded and all new esp's created for continuing work. If you keep using the same esp, then next time a merge occurs, the old stuff will be duplicated again and you will have a huge mess. That is because FORMIds change during the merge.

FNVPlugin has some bugs in regards to references moving from non persistent in the master to persistent in a plugin so drag persistent references over in FNVEdit before using FNVPlugin.

Later on when you start to have scripts, quests, and dialog you need to learn 'merge by injection' with FNVEdit.

This is basically how we've done Project Brazil for the last few years.

[ManehattanProject]

 

I wouldn't let TesSnip touch my project. It was never updated for New Vegas. Record definitions have changed since FO3 and there are new ones. Plus it doesn't handle ONAM records at all.

Turn your main file into an esm. Everyone uses the same esm and makes new plugins with your esm as a master. Try not to over-lap each other. Periodically call in all the plugins for a merge (don't wait too long between merges). Everybody stops working till the merge is done and they have a copy of the new esm.

In the beginning when there is just world building (no scripting or quests) it's safe to just use FNVPlugin to merge esps (one at a time!) into the esm. Then you distribute the new esm. IMPORTANT - the esp's that were merged need to be discarded and all new esp's created for continuing work. If you keep using the same esp, then next time a merge occurs, the old stuff will be duplicated again and you will have a huge mess. That is because FORMIds change during the merge.

FNVPlugin has some bugs in regards to references moving from non persistent in the master to persistent in a plugin so drag persistent references over in FNVEdit before using FNVPlugin.

Later on when you start to have scripts, quests, and dialog you need to learn 'merge by injection' with FNVEdit.

This is basically how we've done Project Brazil for the last few years.

 

 

So to check that I'm understanding you, it sounds like the best solution would be indeed to split off all custom assets (doors, hallways, static objects, activators, etc) into an .esm and then have all levels/worldspaces as a separate .esp. Or instead just convert the whole thing to an .esm (I usually use WyreBash for that, as there's a single click solution to that)?

 

But won't that end up duplicating all of the levels every time we have a merge? Or do we just delete the original .esm one? That would make sense as long as we were sure that no one was working at the same level at the same time.

 

(Sadly, I have a stupid injury that prevents me from reading for long periods of time--such as the FNVEdit Manual :tongue:).

 

(I found that FNVEdit's Master creation was just as simple as WyreBash. Just a few more clicks)

 

Aha! I missed a key word. You said new. I didn't make the connection that you meant new, empty mod. Okay, so now this makes perfect sense. When you merge them back in, it just merges the changes, not a whole new level. That means we don't have to flip it back and forth between .esp and .esm.

 

Again, thank you a billion times over for pointing me in the right direction. :)

Edited July 4, 2015 by ManehattanProject

[rickerhk]

You should only use FNVEdit to toggle the master bit in a plugin because neither wrye nor snip will update the ONAM table for overwritten worldspace records (in the case where your esm overrides worldspace references in FalloutNV.esm or other masters). For simple plugins it doesn't matter, though.

[ManehattanProject]

You should only use FNVEdit to toggle the master bit in a plugin because neither wrye nor snip will update the ONAM table for overwritten worldspace records (in the case where your esm overrides worldspace references in FalloutNV.esm or other masters). For simple plugins it doesn't matter, though.

 

Good tip. I'll make sure that gets out to the whole team. Thank you again! :)

[RoyBatterian]

I'm going to suggest that you download and read the FNVEdit training manual, and understand it as much as you can.

 

Practice learning to merge plugins on stuff you have already (make backups), until you get familiar with the process.

 

When you merge dialogues, scripts and quests, you need to keep in mind that those should be done last so that all references in them are already updated to the new master index. Otherwise xEdit will throw errors about masters.

 

I'm going to also suggest that doing dialogues should be done last of all, as xEdit has not fully decoded dialogues and additionally it likes to insert null references into previous info fields which can cause issues and it won't let you remove them (annoying). If you wait until it's the last thing, since you'll be wanting to dump your scripts for voice acting anyways, you can do it all at once in geck and not worry about bugs introduced by xEdit.

[rickerhk]

I'm going to suggest that you download and read the FNVEdit training manual, and understand it as much as you can.

 

Practice learning to merge plugins on stuff you have already (make backups), until you get familiar with the process.

 

When you merge dialogues, scripts and quests, you need to keep in mind that those should be done last so that all references in them are already updated to the new master index. Otherwise xEdit will throw errors about masters.

 

I'm going to also suggest that doing dialogues should be done last of all, as xEdit has not fully decoded dialogues and additionally it likes to insert null references into previous info fields which can cause issues and it won't let you remove them (annoying). If you wait until it's the last thing, since you'll be wanting to dump your scripts for voice acting anyways, you can do it all at once in geck and not worry about bugs introduced by xEdit.

That brings up a good point. I believe you are referring to subrecords having to do with the 'conversation Editor'? We've completely avoided using that and have no intention of ever using it. I'm not sure how those subrecords affect PREV Info fields, but given that we never use the CONV Editor, from what I've seen every INFO has a previous INFO field, even if it is all zeros (Null, I guess). If you look at a plugin with a hex editor, the first INFO after a topic has either 8 zeros for the PreV INFO, or a FORMId from one of the plugin's masters. The next INFO's prev info field points to the INFO stored above it and so on. The Geck always sorts the INFO's this way in the plugin and whines about 'PREV INFO not found' when some third party tool like FNVPlugin or older versions of xEdit did not honor this order in the saved file. Fortunately Elminster finally fixed that problem with xEdit and I have not had any problems with merging dialog since then (doing it last, like you said - after quest and scripts. Actually quests and scripts, close save, reopen, then continue).

[RoyBatterian]

hrm, in vanilla files the prev info is empty instead of null (no field) when looking at it. I'll ask Jax about that, he's been decoding all this stuff and then we can know if it's actually empty or if xEdit is just playing visual tricks on us (which would be annoying).

[rickerhk]

hrm, in vanilla files the prev info is empty instead of null (no field) when looking at it. I'll ask Jax about that, he's been decoding all this stuff and then we can know if it's actually empty or if xEdit is just playing visual tricks on us (which would be annoying).

I don't think you'll ever find an absence of the field. It will either be zeros or a formID. I understand what you mean by 'null' in the sense of 'nothing', but the field is always there in the plugin. xEdit labels it a 'Null Reference' which I guess you could say the FormID 00000000 is a reference to 'nothing'. I'm not a programmer so stretching these definitions doesn't bother me :tongue:

[RoyBatterian]

This is what I mean here, I don't know if xEdit is just not showing there is a null double word there, or if there is no data all. Usually when a field is like that the sub record doesn't exist.

 

http://i.imgur.com/rvsV2wW.jpg