Jump to content

Massive Inventory Lag


PAPVAFS11

Recommended Posts

This is less of a cry for help and more of a way for me to learn what not to do in the future.

 

A long time ago, I had a personal mod package pieced together from Project Nevada, Nevada Skies, Tale of Two Wastelands, and a bucket of other mods I'd made myself. The problem with the package was that, more often than not, virtually any inventory action in the game would cause a noticeable stutter. This happened for everything from firing a weapon (and therefore generating shells into the character's inventory) to ordinary item movement between containers.

 

That problem made the game virtually unplayable without a lot of patience I didn't have. I quit and stopped playing for a long time. Recently, I've come back and set myself to revitalizing that mod package. As such, I want to know what kind of foul-up could have caused the game to choke during inventory actions so I'll know what not to do this time around.

 

Is there anyone out there who might know what caused this? I can provide more information on the mod package if needed.

Edited by PAPVAFS11
Link to comment
Share on other sites

Shoot. I'd hoped a more experienced merged plugin maker would respond, but I'll give it a shot. Note that I am quite new at creating merged plugins (haven't needed them before), but I have several (7) active and researched the heck out of it first (though I am still finding new references). I have a stable game with the result (no CTDs and 4+ hour sessions using 200+ mods about 90+ hours in) on an older system (I3 3.3Ghz CPU and GTX760).

 

= FNV Personal Merge Plugin guidelines =

The focus here is getting under the plugin cap in the easiest possible manner consistent with a stable game by creating merge plugins for strictly personal use. This means we take a very conservative approach and generally try to avoid any surgery on mods. The resulting merge is highly specific to your personal "Load Order" (LO). Do not attempt to redistribute the result as it will almost certainly not work for anyone else.

* First of all don't try to put everything into a single merge plugin. (Maybe you didn't, but that was my impression. IF so, this is probably the root cause of your problems.)

 

* Disable your Bashed Patch (BP) before working on merges, and activate any mods deactivated by it.

* Sort with LOOT (or manually if you really know what you are doing; but in that case you probably don't need any of my advice).

* Follow the "Fallout New Vegas Beginners guide to modding" article by gromulos to get your load order "green" in Wrye Flash (WF). The article covers why this is a "good idea". (If you aren't using Wrye Flash with a heavily modded game, you are not getting the benefit of all your mods. The "Wrye Bash Pictorial Guide" makes the learning curve much easier.) You can (if you really know what you are doing) create a "merge patch" file instead of using Wrye Flash, but if you are like me, WF is simply easier and "good enough".

* The mods that can go into a merge need to be "contiguously" adjacent in your load order (LO). No "active" mods not included in the merge between files being merged. This provides your first clue as to how many separate merges you are going to need.

* Note that once LOOT has sorted your LO, you can "move" mods up and down in the Wrye Flash "Mods" tab with <Ctrl+Cursor> keys to make them contiguous. You can "group select" (<Shift+Click> or <Ctrl+Click>) files as well before moving them. I always then run LOOT again to see if it doesn't like the result of my manual manipulations. Sometimes it really wants to put a mod elsewhere that doesn't fit adjacently into a "merge group". Personally I play it safe and leave such mods alone unless I feel really confident I know why it's safe to override LOOT's insistence.

* As a general "placement" rule, the group needs to be positioned where the "highest numbered" (lowest in the LO list) is positioned. This is where you should placed the resulting merge plugin. This is the primary reason you need all the mods you use active, even those that the BP may deactivate.

* The S.T.E.P. guide "Merging Plugins" covers the basic process very well in my opinion. The following are some key points I learned to supplement it.

* The simplest merge to create is "non-conflicting" mods. These are usually things that add new items, such as weapons or armor. (Let Wrye Flash deal with conflicting mods, unless you don't like the results and want to create a "merged patch" file instead of using the Bashed Patch. Use one or the other but not both.) Note that if you "renumber FormIDs" you will lose any such items you already have in your save game's inventory.

* The next simplest merge is "fixes" that are unrelated to each other (because they aren't conflicting). This might be considered a subset of the first group, but I find they are less likely to be updated over time, and therefor worth having in their own merge.

* Third simplest are mods that all relate to a single topic mod (such as "Perks" or "Advanced Recon Armor"). Optional files for mods fall into this group UNLESS they are "patches" for other mods to work with the subject mod. Those fall into the next group. Here the LO is going to determine which of these merged mods wins any conflicts.

* Least simple are files all related to an "overhaul package" such as Project Nevada, WMX, "Weapons of the New Millenia", etc. The primary issue here is dependencies (other files looking for a specific file name in the package as a "master").

* The latest tool for creating merge files is "Merge Plugins Standalone" (MPS), which was released in December 2015. It is supported here. It uses the API for "xEdit" (FNVEdit). It makes the process very easy, but you do have to exercise some judgement and understand the problem areas it identifies for you. Be sure to carefully read the included documentation. Various setup choices may need to be revisited for each merge plugin such as record copying, FormID renumbering, and inclusion of "art assets".

* MPS won't let you merge mods with "errors", but it does have an "ignore errors" option. Be very skeptical about using this. The only time I use it is for "Unknown flags" which have a value. That just suggests FNVEdit doesn't know how to interpret the flag being used, which is not fatal (as far as I know). I do not ignore "NULL references". Those should be examined in FNVEdit or GECK and resolved or excluded.

* The things to always watch out for are: 1) BSA files, 2) Sound Files, 3) Self-referencing scripts, 4) Dependencies. ESMs can be merged, but generally they are masters for dependencies and I leave them out (block from merging) just to avoid the complications. While it is possible to deal with these issues, unless you want to become an advanced merge maker, it's easier to skip including files (i.e. Block merging) that have any of these issues. There are usually plenty of other, simpler merges to get you under the plugin cap.

* Note that when you create a merge you may need to still have some elements of the original mod installed separately (ESMs, menus, etc) while others such as ESPs and meshes & textures can be included in the merge. For this reason I recommend creating a "ReadMe" file for each merge plugin you create that lists which files are included and which still need to be installed separately. I also find it useful to make note of mods I initially thought to include but later rejected and the reason why. I also note any Bash Tags from the original mod, and which mod the merge needs to follow in the LO. You can add the Bash Tags in the "Comments" section of the "Installer" tab of WF (aka BAIN) as "{{BASH:<tag>, <tag>, <etc>}}" (which then get picked up by LOOT), or individually in the "Mods" tab in the "Bash Tags" field in the bottom right part of the screen for the selected merge plugin.

* Examine the resulting merge in FNVEdit for any errors or undesired conflict results. IF there are any, resolve them or remove the plugin from the merge.

* The MPS places the resulting merge file in it's own folder. You will need to copy and create a "package" (7zip or RAR file) to keep your ReadMe with the plugin and any assets. (I recommend you create a naming convention to make it easier to identify your merges: i.e. "Merge - <purpose>".)

* Install the merged plugin you just made.

* Run LOOT and adjust in the LO as needed to get it placed just after where the highest numbered plugin that was merged is located.

* Disable all the mod plugins that have been merged. (I uninstall them, and then re-install only the necessary files not included in the merger according to my ReadMe information because I use WF as my mod manager and then I can "Anneal All" to resolve "Install Order" issues.)

 

* Use the "metadata" capability of LOOT to identify the plugin that your merge needs to "Load After" to ensure it is placed correctly in your LO. Note this may need updating if you add other mods later or rebuild the merge.

* Run LOOT again to ensure no issues have been created when you disabled or uninstalled mods that were merged (such as "missing masters"), and that your LOOT metadata information is working as intended.

* Run "FNVLODGen" to rebuild your LOD files (because you have greatly changed your LO and it's LO dependent.)

* Rebuild your Bashed Patch (or merged patch file).

* Test each merge plugin just like the original mods before moving on to the next merge. The time to find problems is now, before they get into your save game.

* While you can add a new plugin to an existing merge, you have to completely redo it to remove one. This is another reason to have several rather than one massive merge.

Hope this is of some help.

 

[Edit: Revisions 10 Apr 2016 which include some sequence alterations, additions, and clarifications.]

 

-Dubious-

Edited by dubiousintent
Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...