Jump to content

Magic Threshold vs the FF Block - Investigations


SMB92

Recommended Posts

Hi all,


Okay after a few days of testing I was interested to find that there are 2 limits or rather 2 thresholds that one can run into in NV.


Here's what we know so far:


The first is as previously found - the game loads it's plugins starting at block 74 allowing for only 139 plugins. We also know that this limit can be exceeded with mods that are entirely injected to their master i.e Weapon Mod Recipes and the WMX version - some of it's plugins entirely inject themselves into WMR.esm which allowed me to get to 143 plugins. To confirm this I removed all those patches and replaced them with normal mods and presto the game wigged out at 143 but stayed stable at 139.


Second, BSA's don't count toward the 139 limit however they are most likely loaded into the blocks above the 74 block. We know that BSAs are ordered alphabetically upon load with the exception that any BSA specified in the SArchiveSection of the INI are given priority and loaded in the order specified. We also know that in order to order your BSAs in the correct fashion we can put a prefix mapping on each BSA, evidently the game does not care about the name of the BSA - as an example the ultimate edition comes with a BSA named "Update.bsa" and is loaded without a plugin although it is not specified in the INI, it is designed to that as it was intended to load last. Also evidently the game prefixes each BSA anyway - this is how I suspect the game gives the INI specified BSA's priority. Furthermore prefixing is the same method that Mod Organizer uses to order the BSAs - this is what first prompted my investigation. For good practice always prefix a BSA with 3 characters, starting at aaa, aab, aac etc etc, never use numbers, only letters.


Now the FF block - this one I've been trying to get my head around. Now if one exceeds the 139 limit he can expect the engine to start corrupting alot of things and also a lot of menus begin to disappear, which I believe derives from the game not loading the extra plugins and/or half loading it. With an FF block overflow, you don't get the full blown corruption or menus disappearing however you start to lose resources randomly, sometimes coming back and disappearing again (which I believe is because that block is changing all the time as the game loads more temp objects into it and removes some as well. That is the most logical and obvious theory anyway), but you'll never lose the menus and YOU WON'T GET CORRUPTED SAVES. Now how did I find this out? Well I got my LO down to 135 plugins, with an expectation I could go another 4. I have added some larger mods lately like Monster Wars and Skunkwater Gulch and I was surprised to find, what I just wrote, happening in game. So I go back and disable Skunkwater Gulch and play again, problem goes away. Activate it again and start playing, problem returns. This time I play for a couple hours, noticing that the menus hadn't gone and everything was working still. I exit and reload the game, game loads fine. Plays for about 15 minutes, problems arise but game is still playable. So I start checking the indexing of my mods and find a number of masters are loaded directly into the FF block. I am not 100% yet as to why they get loaded in there, especially when a number of dependent plugins still require them to load before them although those plugins remain at their normal index position. I do know one thing - the game does preserve the original indexing of those mods but somehow redirects it to the FF block. I don't understand why they designed it like this, previous games didn't do it i.e Oblivion and FO3, although my theory is the game wants to make the FF block like a master block for all other referncing plugins, perhaps the idea was to make it so all other plugins could just read from it but hey idk.


So now we know that it's more than possible to flood the FF block causing temp items to completely go missing but return depending on he number of temp items/cells/master records loaded into it. We also know that it won't cause major corruption of memory and missing menus as opposed to exceeding the limit.


EDIT/UPDATE: I forgot to mention that one can lower the amount of objects in the FF block by lowering their uGridsToLoad value and also lowering their cell buffers. I tested this out and it does work but it's a bad sacrifice to make if you have a good rig and would like the higher settings :/


At the end of the day there is no solution to these design flaws and likely never will be, but at least we know our limit and how we can go about our modding.


Hope this helps, would really like a moderator to pin this for everyones sake Happy modding folks XD
Link to comment
Share on other sites

Furthermore I have a question for anybody who may have any idea - If the game can reserve the FF block for all it's data THEN surely it will index and reserve every possible slot, in which case, WHAT HAPPENS TO THEM!?

 

Probably cos that's the way it's coded idk but I figured it was asking.

Link to comment
Share on other sites

Yeah tried that same result, I definitely flooded the FF block with content. There is a difference that's for sure cos I can definitely run 140 if I take away a big one.

 

Now further supporting the 140 limit, If I load 140 null esp files, well not null but with a single edit etc etc like add a rock somewhere via GECK, Game still won't pass the 140 threshold. It corrupts everything. With this, no corruption but the game won't load any data from whatever mods get injected there. It will show up again and correct itself when I perform a PCB in an interior, try that ith 140 and you get nowhere.

 

Either way we'll never know how to fix it, but again we can only work around it.... I keep testing my stuff everyday.......

 

Oh and scratch that question about where the other slots are going, I doubt they even get reserved at all, they work differently to the FF block as that is hard coded.

Link to comment
Share on other sites

  • Recently Browsing   0 members

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