Tutorial for building NMM installer scripts.

[ShinraStrife]

NMM looks for 2 XML files in the FOMod folder of your mod's archive. info.xml contains information about your mod and moduleconfig.xml contains the installer.

 

So basically you make those 2 files using the tutorial on the first page and put them in a folder called FOMod inside your mod's folder. When you go to install the mod through NMM it will realize you have info.xml and moduleconfig.xml in the FOMod folder and initialize the script.

If you want me to check your XML code for errors, post the code somewhere like pastebin and I'll give it a look over.

Edited June 9, 2016 by ShinraStrife

[DarkShenron]

Thanks for this guide, was struggling in making a NMM installer....XML gets confusing at times hehe. I have added a link for your guide in my mod at http://www.nexusmods.com/oblivion/mods/47156/? ... i hope you don't mind :)

[damanding]

Now if only I could find a tutorial that would help me figure out how to package multiple esps into one esp based on fomod choices.

[ShinraStrife]

Now if only I could find a tutorial that would help me figure out how to package multiple esps into one esp based on fomod choices.

I have never tried to do this myself, but I know it can be done using a wrye bash script. I remember a skyrim weather mod that used a script to automate combining weather mod's esp plugins in wrye bash. I think it was Frostfall. You might try to reverse engineer that mod and see what he did to make it work.

[JonathanOstrus]

Now if only I could find a tutorial that would help me figure out how to package multiple esps into one esp based on fomod choices.

 

Cool but potentially terrible idea. The reason's have been touched so many times so I'll try to be brief. Here's why:

 

Each mod has a unique set of internal record ID's. They are 6 digit hex values. When loaded in the game the references are 8 hex digits, the first 2 being the plugin's load order. Everyone should already know this.

 

If you merge 2 plugin's there are two main things that could happen.

• If both files use completely unique internal record id's and have no duplicates then all would be fine you just make a new one with the same id values.
• If there are conflicts (as usually would be the case), then you have to renumber one of the plugin's references.

In the case of scenario 2, any time you update and it re-merges the plugins the record id's could potentially change. This would cause the game engine to do unpredictable things. For example the first time you merge maybe your record ID A001 points to a pillow. After the second merge maybe A001 is now a hat. The game won't know what happened and will try to perform things on the pillow thinking it's a hat. This may sound amusing but will likely just cause the save game to be corrupted and unusable.

 

Generally the first record in any plugin is the same ID (this is set by the creating application xEdit/CK). Then it increments linearly. Hence the reason you'd likely have ID conflicts.

 

**Potential work around**

 

If you are the author of the mod, you can deliberately use xEdit to set the "Next Object ID" in the header to some high number as a base in each of the proposed plugins. You would do this before creating content in the plugin file.

 

For example:

1. Modfile 1 - Next ID 10000
2. Modfile 2 - Next ID 200000
3. Modfile 3 - Next ID 400000
4. etc

Given that the possible record id values are 6 hex digits that equates out to 16,777,215 id's. Assuming some internal overhead round that down to a safe 16,760,000 records. Just increment some amount of record values you know you'll never use and then you should be ok. Then whenever you merge plugins there shouldn't be any conflicting ID's because you told them to start numbering at places that wouldn't conflict. In my example the first file has 190,000 records of space before it would generate an ID that would conflict with file 2. File 2 have 200,000 and so forth.

[ShinraStrife]

Cool but potentially terrible idea. The reason's have been touched so many times so I'll try to be brief. Here's why:

ÃÂ

Each mod has a unique set of internal record ID's. They are 6 digit hex values. When loaded in the game the references are 8 hex digits, the first 2 being the plugin's load order. Everyone should already know this.

ÃÂ

If you merge 2 plugin's there are two main things that could happen.

 

• If both files use completely unique internal record id's and have no duplicates then all would be fine you just make a new one with the same id values.
• If there are conflicts (as usually would be the case), then you have to renumber one of the plugin's references.

In the case of scenario 2, any time you update and it re-merges the plugins the record id's could potentially change. This would cause the game engine to do unpredictable things. For example the first time you merge maybe your record ID A001 points to a pillow. After the second merge maybe A001 is now a hat. The game won't know what happened and will try to perform things on the pillow thinking it's a hat. This may sound amusing but will likely just cause the save game to be corrupted and unusable.ÃÂ

ÃÂ

Generally the first record in any plugin is the same ID (this is set by the creating application xEdit/CK). Then it increments linearly. Hence the reason you'd likely have ID conflicts.

ÃÂ

**Potential work around**

ÃÂ

If you are the author of the mod, you can deliberately use xEdit to set the "Next Object ID" in the header to some high number as a base in each of the proposed plugins. You would do this before creating content in the plugin file.

ÃÂ

For example:

• Modfile 1 - Next ID 10000
• Modfile 2 - Next ID 200000
• Modfile 3 - Next ID 400000
• etc

Given that the possible record id values are 6 hex digits that equates out toÃÂ 16,777,215 id's. Assuming some internal overhead round that down to a safeÃÂ 16,760,000 records. Just increment some amount of record values you know you'll never use and then you should be ok. Then whenever you merge plugins there shouldn't be any conflicting ID's because you told them to start numbering at places that wouldn't conflict. In my example the first file has 190,000 records of space before it would generate an ID that would conflict with file 2. File 2 have 200,000 and so forth.

The 8 digit hexadecimal values you are referring to are called FormIDs.

 

FormIDs can only have their last 6 digits changed by editing, the load order digits are automatically generated by the launcher at game start.

 

When 2 records have the same FormID the game assumes the record lower in the load order is an overwrite record. the method used by chesko's wrye bash script in his Frostfall mod (the method I mentioned earlier) doesn't merge the actual plugins together, it creates a new plugin that overwrites the records based on what weather mod's the user has installed so that his temperature and exposure system can register any new climate records that the user may have installed. Overwriting records can be made in the Creation Kit and in xEdit as well and won't do any harm if you follow the original record type (COBJ overwrites COBJ, TXST overwrites TXST and so on)

 

Save game corruption usually only happens when mods have been uninstalled mid-playthrough, or if the record structures in a plugin are corrupt. Record corruption is a known problem with mods made by the xSnip tools. Any reputable mod author will caution you to avoid using that tool.

Edited August 28, 2016 by ShinraStrife

[JonathanOstrus]

 

Cool but potentially terrible idea. The reason's have been touched so many times so I'll try to be brief. Here's why:

 

Each mod has a unique set of internal record ID's. They are 6 digit hex values. When loaded in the game the references are 8 hex digits, the first 2 being the plugin's load order. Everyone should already know this.

 

If you merge 2 plugin's there are two main things that could happen.

--snip snip--

The 8 digit hexadecimal values you are referring to are called FormIDs and the method used by chesko's wrye bash script in his Frostfall mod (the method I mentioned earlier) doesn't merge the actual plugins together, it creates a patch that overwrites the records using a new plugin based on what weather mod's the user has installed so that his temperature and exposure system can register any new climate records that the user may have installed. Overwriting records can be made in the Creation Kit and in xEdit as well and won't do any harm if you know what you're doing.

 

 

All true. It sounded like damanding wanted to automate something like making a merged patch though. Not overriding records. I might have misunderstood though. I believe wrye bash could be scripted to make merged patches of new content, but then all the stuff I mentioned comes into play. If you're only ever dealing with overrides then making a merged override patch isn't really an issue since you intentionally want to overwrite the same form id's.

[ShinraStrife]

 

 

Cool but potentially terrible idea. The reason's have been touched so many times so I'll try to be brief. Here's why:

 

Each mod has a unique set of internal record ID's. They are 6 digit hex values. When loaded in the game the references are 8 hex digits, the first 2 being the plugin's load order. Everyone should already know this.

 

If you merge 2 plugin's there are two main things that could happen.

--snip snip--

 

The 8 digit hexadecimal values you are referring to are called FormIDs and the method used by chesko's wrye bash script in his Frostfall mod (the method I mentioned earlier) doesn't merge the actual plugins together, it creates a patch that overwrites the records using a new plugin based on what weather mod's the user has installed so that his temperature and exposure system can register any new climate records that the user may have installed. Overwriting records can be made in the Creation Kit and in xEdit as well and won't do any harm if you know what you're doing.

All true. It sounded like damanding wanted to automate something like making a merged patch though. Not overriding records. I might have misunderstood though. I believe wrye bash could be scripted to make merged patches of new content, but then all the stuff I mentioned comes into play. If you're only ever dealing with overrides then making a merged override patch isn't really an issue since you intentionally want to overwrite the same form id's.

If I'm understanding what he posted correctly, I think he wants to merge his own plugins together so he should be able to do it quite easily since he knows what records are inside them.

[damanding]

Actually I'm helping the original mod's author figure it out, so he would be more familiar with the specific content than I would but I can always poke around the esps in CK in depth to familiarize myself. If it helps any, the mods in question are the restoration of location mods by Quince99. Many of the materials are duplicated across mods and the installer could be written in such a way that they're just pulled once from one source esp. The idea is that users pick which locations they want to install and have just one esp instead of many. Rdunlap has already done this with his restored settlements mod but I've been unable to contact him for details on how.

 

Edit to clarify, I have been asked by the mod author to help with this, so it is done with permission.

Edited August 28, 2016 by damanding

[ShinraStrife]

 

If he doesn't get back to you, I'd just open his mod up in the CK or xEdit and see what he did. There's nothing illegal with that as long as you don't copy and paste anything from his plugin/meshes/textures files and use them in yours. That's how a lot of people learn many things. I learned programming languages by downloading source code and trying to repeat what the source code did in my own projects and it's a good hands on way to learn. Although it is more 'well mannered' to ask permission first, you don't have to unless you are using copyrighted material as is (or just copy pasting) in your own projects.

Edited August 28, 2016 by ShinraStrife