Nv Plugin Limit

[A.J.]

Since sometimes this subject still comes out in posts, I found back the old thread which was explaining why 139 is the limit of active mods and why after that problems will randomly happen.

I don't use so many mods on NV so I never tested it. Anyway, here it is:

 

http://forums.nexusmods.com/index.php?/topic/915951-theories-on-the-magic-threshold-mod-limit-and-an-interesting-find/

 

I paste here the passage:

Now that's a little off topic but here's what I did find intersting in Mod Organizer's logs: FalloutNV.esm STARTS AT 74 WHEN LOADED INTO MEMORY.

...

If FalloutNV.esm starts at 74 then there are 138 slots left to fill.

How we work this out? Well there are 16 combinations of bytes in the first 2 when the first is a set number, or in other words 16 mods for every 1st byte's number i.e 80 through to 8f. Consider 74-7F is only 12 slots and then F0-FE is 15 slots (as the game uses FF block for non-persistent references/temporary items like all Beth games) and then we have blocks starting with 8,9,A,B,C,D,E with 16 possible combinations for each, so do the math it's 12+112+15=139, including Fallout.esm.

...

Now why do some people go above this limit? I have found that I can go to 175 because several of them are merged or injected at the end and after closer examination, in reality i'm running 139 mods. I have found that despite theoretical sensationalism (lol) that BSA files do not count toward this limit, although loose esp's seem to. I tested this theory with Wyre Flash ghosting technique, when I disable ghosting on several unused merged esp's the game goes to crap again.

 

[Halstrom]

Interesting info that is

[sidfu]

the limist seems to be random also what effects what u can safely run is number of scripts. for me when have a few script heavy mods i get graphical corrutprion ofter a while but when i loewr number of scripted mods it stops so im running right now 140ish mobs saftely without the destorion or lag.

[Halstrom]

There is also another limit on the number or amount of meshes / textures installed too, no ones worked out what the limit is but when you hit it, vanilla stuff that no mods are touching starts disappearing.

[7KeysCurtain]

I'm one who has reached this plugin limit in FNV. When I did the whole Mojave turned upside down, land textures were rainbow colored, Alot of red ! everywhere but as soon as I disabled ANY .esp from my load order it was fixed, after looking around Google that's when I found out about this dreaded plugin limit and it was the reason for what I was experiencing.

 

Luckily for this tool I managed to merge a whole bunch of .esps into one to reduce the number of loaded mods.

 

FNV Plugin Utility : http://www.nexusmods.com/newvegas/mods/39655/?

 

You'll need to be careful what you merge and always make backups, I have all my weapons, clothing & armor mods merged into WCAMerged.esp instead of 30 seperate .esps.

[prideslayer]

Since sometimes this subject still comes out in posts, I found back the old thread which was explaining why 139 is the limit of active mods and why after that problems will randomly happen.

I don't use so many mods on NV so I never tested it. Anyway, here it is:

 

http://forums.nexusmods.com/index.php?/topic/915951-theories-on-the-magic-threshold-mod-limit-and-an-interesting-find/

 

I paste here the passage:

 

Now that's a little off topic but here's what I did find intersting in Mod Organizer's logs: FalloutNV.esm STARTS AT 74 WHEN LOADED INTO MEMORY.

...

If FalloutNV.esm starts at 74 then there are 138 slots left to fill.

How we work this out? Well there are 16 combinations of bytes in the first 2 when the first is a set number, or in other words 16 mods for every 1st byte's number i.e 80 through to 8f. Consider 74-7F is only 12 slots and then F0-FE is 15 slots (as the game uses FF block for non-persistent references/temporary items like all Beth games) and then we have blocks starting with 8,9,A,B,C,D,E with 16 possible combinations for each, so do the math it's 12+112+15=139, including Fallout.esm.

 

...

Now why do some people go above this limit? I have found that I can go to 175 because several of them are merged or injected at the end and after closer examination, in reality i'm running 139 mods. I have found that despite theoretical sensationalism (lol) that BSA files do not count toward this limit, although loose esp's seem to. I tested this theory with Wyre Flash ghosting technique, when I disable ghosting on several unused merged esp's the game goes to crap again.

That is.. an astonishing bit of detective work for someone who obviously doesn't understand hex. He goes through all that math rigamarole but it boils down to this: If 0x00..0x74 are reserved as he thinks, you're left with 0x75..0xFF. That is 138 slots. The only math you have to do is 0xFF - 0x75 == 255 - 117 == 138.

 

That said, I'm not certain he's interpreting the hex values in the logfile right if he jumps through such hoops to do simple subtraction.

[A.J.]

If you remember I already told you, Prideslayer, about Nexus' number of doom. You said sometimes people can go over that limit and that limit was different from different people so it wasn't really proved. Then few days ago I found back this link and I wanted to show you all why they arrived to this conclusion. Anyway this is something for you programmers, I don't understand anything about it so I can't claim it can be true/false. But in my mind, since nexus halls are wandered by programmers too, and some wander LL too, if it was completely wrong I suppose there were answers explaining why. At contrary, on Nexus I saw positive answers from scripters I esteem.

 

The only thing I might say about it, is connected to what I told you once, about the fact that if you run 145 mods for example and you don't "notice" problems it doesn't mean you don't have problems. You answered me a wonderful sentence which was much or less "if there's a bug but noone can see that bug, can we say it's really a bug?". While I liked this sentence, it let me think about the OP statement. Let's see if I can explain with a simple example with random numbers.

 

Following what stated in OP, after 139 the next plugin will start to occupy the same records of 74, which is FalloutNV.esm. But how many records are in FalloutNV and how many in a esp mod? the comparison is quite different, so let's say for example falloutnv has 1 million of records and the 140th esp has 1000 records. This means that only 0,1% of falloutnv.esm will be overridden. And so go on for the rest of the mods. How many possibilities you have to meet these "overridden records", in game? with these random numbers, 0.1%. How much time you need to meet in game ALL the content of NV? a lot, and it isn't even possible because some records are in the esm but are not used in game (User / Info 0, think to FO3 enclave npcs, just to say).

 

TL;DR, I really think that you can have 150 mods, that can override some records of 10 other mods (from 74 to 83) and still not see a bug ingame until you don't test A LOT of things. Sure if you jump in game and play a hour you can't claim everything works. This would be different than the usual CTDs caused by instability. See it more like an incompatibility between 2 mods, if 2 mods modify the same vanilla navmesh for example, you can't have problems until you don't jump in there.

 

I guess if people have 150 mods and "run fine", it's just a matter of big numbers and possibilities and the destiny. Today they run fine, tomorrow who knows...

 

EDIT: think also that after FalloutNV, the next mods should be DLCs, which many have but noone tests when they are testing stability. So if even the 141th mod afflicts DeadMoney.esm, you wouldn't know until you go in Sierra Madre

[Halstrom]

I also suspect people going over the limit may think they are ok, but after long term play find little things are screwing up and maybe they are getting away with them. I run 165 plugins but only 128 active and seem to be ok, I only turn the others on (mostly older Sexout mods) when FNVEdit testing for SCR conflicts & usage. Haven't tried any long term play for a while over 135ish

[prideslayer]

AJ, I do remember our discussion. To address just a few points you brought up.

 

Yes, programmers frequent both places. I don't think any commented in that thread though, because not one person said "hey idiot, you don't have to list out '0,1,2,...e,f' and multiply by 16 and do a bunch of addition." Every programmer understands hexadecimal, or at least, every one that is qualified to comment on what might be happening with some random 0x74.

 

If the theory is correct, and the record overwriting happens at the start, it's extremely easy to test without guessing or hoping you run into the 0.1%:

 

1. Create a new, empty mod.

2. Duplicate it 139 times (copy/paste the file or whatever).

3. Open the 139th copy in the GECK and add a new (non-actor/creature) record, like an item, script, or quest.

4. Open the 139th copy in FNVEdit with only FalloutNV.ESM checked and change the formID of the new record to 01104C0C.

5. Activate all mods in FOMM, make sure the modified one is LAST.

6. Start a new game. It should crash nearly immediately.

 

0x00104C0C is the fixed formID for doc mitchell. If the mod index does wrap around at 0x8B (139) back to 0x00, his record should be overwritten when 0x8B104C0C overwrites 0x00104C0C.

 

In fact, you could test this with any form ID. Just note down what it is before you activate the last mod, and then see if it changes to something else with that mod active. You don't have to run around for hours hoping to run into a glitch.

 

This is a simple and only slightly tedious test to verify the theory. It's one the theory author should have tried before saying he'd "found" the problem, because right now, the theory is just an unverified guess.

 

I'm not saying he's WRONG, I'm saying that he (and others in that thread) are claiming to have found conclusive proof for a theory when they haven't even tested it, an are operating under the assumption that a guy who obviously isn't a programmer has correctly interpreted the log file information and what follows beyond it. If it turns out he is correct, it would be terribly simple for me to hard code that limit into FOMM.

 

We could go one step further and modify FNVEdit (or perhaps GeckPU, or both) so that they only ever use record IDs won't conflict even if wrap-around occurs.

[A.J.]

It's cool, PrideSlayer, and you're right it deserves a test, I'm going to try it and post you the results. My interest is not in denying who said what, is in understanding better the things.

[A.J.]

Ok I did the experiment but nothing happened. Also, the ingame reference of Mitchell was always the same. I wasn't sure if the last plugin (the modified one) had to index at 8B or 8C so I did a few more tries

 

137 - 8A - Doc Mitchell ingame ref: 00104c0f

138 - 8B - Doc Mitchell ingame ref: 00104c0f

139 - 8C - Doc Mitchell ingame ref: 00104c0f

140 - 8D - Doc Mitchell ingame ref: 00104c0f

141 - 8E - Doc Mitchell ingame ref: 00104c0f

 

Just to be sure. You made me change the reference with 01104C0C instead of Mitchell one's which is 00104C0C, is it correct? well I tried to change also with the same but FNVEdit protests so I get it's correct as you wrote.

 

Also, I did the same try but putting the item ingame and changing its temporary reference to DocMitchell fixed reference 0x104c0f, changing x to 1 as you did before. Still, no results.

 

Could it be that this "maybe-issue" influences dynamic references instead, or I don't know, Temporary references and not Fixed ones, and I must make experiments on them?

 

Last thing, I don't know if it could influence the result. First, I use FOMM, while that guy uses MO. Then, to make the try I unflagged every mod, but every time I close and reload FOMM I have Dead Money which is always flagged on (and I don't have .nam files, just to say). I don't think it influences but anyway is good if I tell you

 

What do you think?

[prideslayer]

Ok I did the experiment but nothing happened. Also, the ingame reference of Mitchell was always the same. I wasn't sure if the last plugin (the modified one) had to index at 8B or 8C so I did a few more tries

 

137 - 8A - Doc Mitchell ingame ref: 00104c0f

138 - 8B - Doc Mitchell ingame ref: 00104c0f

139 - 8C - Doc Mitchell ingame ref: 00104c0f

140 - 8D - Doc Mitchell ingame ref: 00104c0f

141 - 8E - Doc Mitchell ingame ref: 00104c0f

His ref would not change, what should happen is he should have been replaced (*without* changing his refid) to whatever record you put in at that XX104c0f slot. Meaning if you made that record in your mod a toaster (and the game didn't end up crashing first) going to doc mitchell should have shown him to be a toaster, not a human being.

 

Just to be sure. You made me change the reference with 01104C0C instead of Mitchell one's which is 00104C0C, is it correct? well I tried to change also with the same but FNVEdit protests so I get it's correct as you wrote.

If you followed the instructions exactly then, in FNVEdit, your last mod will have a (temporary) mod ID of 01 since only it and Fallout.exe/esm are loaded, and the vanilla core always gets id 00.

 

If you load up a bunch of other things then it might be 09 or 5F or who knows what. The point was just to change the last 6 to match doc mitchell's, to see if the wrap-around is actually happening or not.

 

Also, I did the same try but putting the item ingame and changing its temporary reference to DocMitchell fixed reference 0x104c0f, changing x to 1 as you did before. Still, no results.

 

Could it be that this "maybe-issue" influences dynamic references instead, or I don't know, Temporary references and not Fixed ones, and I must make experiments on them?

There are a lot of things that "could be." We're trying to use the scientific method to prove or disprove them. You could try something more drastic if you think you're getting the IDs wrong somehow.. use XX000014 which represents the player (I think 0x14 is the player anyway). The important thing there is that the XX value matches the mod index of your mod in FNVEdit. If your mod has a '01' next to it in fnvedit when changing the ID, then you use '01' as the first two digits. If it says 'C9' then you use 'C9'. Putting anything else in is going to cause it to intentionally inject an overwriting record -- but we're looking for an accidental overwrite (or injection).

 

Last thing, I don't know if it could influence the result. First, I use FOMM, while that guy uses MO. Then, to make the try I unflagged every mod, but every time I close and reload FOMM I have Dead Money which is always flagged on (and I don't have .nam files, just to say). I don't think it influences but anyway is good if I tell you

 

What do you think?

FOMM vs MO will not matter at all. I'm pretty sure you missed a NAM if deadmoney is still showing up, but that should not cause any problems either.

 

All formIDs are broken up into two pieces:

 

0xXXYYYYYY

 

YYYYYY is a 6 digit hex value that is the ID of the form within the mod. The first two digits, the 0xXX represents the mod index, in other words, its position in the load order. It's not stored within the ESP/ESM and changes as load order changes.

 

The claim made by 'that guy' is that a mod ID like 0x??aaaaaa will overwrite 0x01aaaaaa if the mod is loaded at the 139th (or whatever) position in the load order. To be blunt, "I don't buy it", but it's possible -- so we may as well try to see if it's true or not.

 

Personally, I don't think there's a hard limit like this except for the built in one of 0xFE -- meaning you can have 253 mods loaded, total. There are 256 slots (0x00 - 0xFF). You lose one for the vanilla ESM and EXE with no DLC (0x00), you lose another for dynamic refs (0xFF). 256 - 2 = 254.

 

If there is any other limit, the engine developers would have had to go through extra effort to put a lower limit in on purpose, and then not told anyone. I haven't seen any evidence that this is the case and I'd expect to, if not within the game console itself, then through workarounds and hacks in the NVSE source code.

[A.J.]

I followed exactly, but for example at 139 it was 8C, you were speaking about 8B, so I wasn't really sure...

Anyway I tried both with a Misc object, a Quest object and a NPC object

I really would love if you find a "scientific answer", no matter if that means ME DOING a thousand of ESPs.

 

In the meantime, look here:

"why i can't run more than 140 plugins ? i click the 141 and my game goes wrong in the worst way possible like some meshes don't load , textures goes wrong , some mods stop working , can't open the esc menu , can't save and so on ..."

This was posted 5 days ago and not even on Nexus, so you can't even say it's some sort of ... how can I call it... when people suggestion themselves and start to believe to that.

 

So I could really think there's a truth, maybe the explanation is not exactly that one, but maybe it's something concerning other resources (like meshes and textures? or some specific group of records?).

So, first of all, are we sure that trying it on an empty plugin is good? I would try with a mod, but I'm not sure of what could happens if I replicate a complex mod 139 times and then I activate it. I mean maybe it could crash for whatever other reason

 

Anyway thank you very much for wanting to go deep, you only need to tell me what to do and I try that, I'm really interested. PS did you see my way to handle FE with SexOut? I don't know, I see that as the only viable solution in my opinion

[prideslayer]

I haven't seen anything FE (you mean FAFF right? expressions?) in a while, link?

 

8b/8c is probably me just forgetting if falloutnv.esm starts at 00 or 01.

 

You don't need an empty mod, you can put something in it, and then just copy it 140 or 150 times and see what happens. Start deactivating them when you run into a problem, one at a time, until it works -- and there's the magic number, if there is one.

 

I think a lot of people run into the problem around 140 simply because most people use, by and large, the same or similar collections of mods, so they run into some other limitation we're not aware of at around the same place. It's just a guess though. I know there are also problems when you have too many loose files installed in the data dir, that has nothing to do with how many mod ESPs/ESMs are active, so they may have run into that as well.

 

That one, I have no idea what causes it, but something does.. too many loose files in the model/texture folders and *boom* graphical glitches everywhere for no apparent reason. There might be a really low limit there, perhaps an open file limit of 1024 or 4096 or some other nice round number.

 

I'll think more on ways to test this, but I'll be honest, It doesn't really bug me that much. I purposely stay away from those high values and rarely have more than 50 or 60 mods going, never mind twice that many. If we do find a hard limit, even if it's 139 or 140, I'll happily code a warning into FOMM that says "hey knucklehead, deactivate or merge something or you're going to have problems.. probably."

[BruceWayne]

I'm not sure how relevant it still is, but some of us went through this process before in this thread: http://www.loverslab.com/topic/16435-tracking-down-the-plugin-limit/

 

[A.J.]

I remember of that Zippy test, it was the first thing I learnt about NV limit. My OP was showing how that limit wasn't really "variable" because someone fixed that number at 139. So I'm just trying to understand if that number can be verified in some way, or if it is variable as Zippy and many others noticed on their own, the crowd is splitted in two and I want to understand it better.

Because if the fixed number is true, I guess that for that theory it would be also hard to notice problems when you go over it if you simply play the game for some time.

[RitualClarity]

I don't know if others have this problem however I run into different plugin limits. These limits when testing a variety of mods many of which others might not even use anymore. I run FNVedit and make sure that it can load (in the past. I didn't understand how to "clean" the mods so some might have been very dirty). The issue seems to stem both from textures and esp/esm the amount of records or textures that are being accessed. Based on my very "un-scientific" experiments, since I am not a programer or even a modder, it appears the content "volume" is the cause for issues. The more you load up, the more the memory is accessed and processor etc the more stresses. Eventually when you hit the limit it crashes. Many times records and quests are "slow to respond" with more of a delay. Simple access like using the "E" key becomes more difficult.

 

Textures are slightly different. When I loaded up all of the SCR into a BSA it didn't seem to matter compressed or not however... in stressed state of a very heavy textured mod (with NMC Textures as well) those items that are nested deeper inside the folder seemed to go missing before those not so deeply nested. I posted those results and comments awhile back and if memory serves me correctly Halstrom and Docta Sax commented on this. Also if the actual BSA exceeds a specific size that caused me some issues with deeply nested files. Almost as if the game engine allowed a specific amount of time to find a texture and when it ran out.. it rendered nothing.

 

This has nothing to do with the actual physical hex limit of the Game engine which still remains the same. this is likely the reason that some can have 141, others can have 150 and still some can only have 100. It can even be effected by the hardware. It seems as if some of the older hardware is more "effective" with the game engine than some of the newer ones. This is likely settings or something else interfering.

 

There is my alien 2 Cents for whatever it is worth.

[A.J.]

I haven't seen anything FE (you mean FAFF right? expressions?) in a while, link?

 

 

Yes, facial expressions. I can't really say FAFF because I use other thing. Anyway this is the only solution I see as reliable, here