kylemarshiku

This is a cool idea. Hope someone's able to do it.

Hey everyone, I've been getting really into this game with my partner, and we're excited to try out some BG3 mods. Hailing from the Fallout New Vegas modding community, we don't know the details of what mods can or can't be made for this game yet, but I wanted to put a request out there that someone could read at a later date and hopefully be inspired, or at least folks might commiserate if you all agree with my request. If you disagree, or I missed something, please be kind. TLDR: Familiars in BG3 feel nearly useless outside of combat. Perhaps a mod could be made to let them interact with the world like the player and companions? I can't tell you the number of situations where I wished my familiar could've picked up something or interact with something. I've had DnD scenarios in my mind where I would've come up with some crafty use for my familiar, and this game just won't let me. I can scout with them, fight with them, sure, but the main boon of the familiar is just another puzzle piece you can move around. Half the time my spider just jumps in an enemy's way as bait. While I normally play DnD treating familiars as precious despite their ability to be resummoned, in this game, I'm doing it every rest. So, what can be done? First of all, normally when you have a character selected, you can click on thing in the environment to interact with them or pick them up. For familiars, this is just turned off, somehow. Maybe this could be turned back on? Familiars could have very limited inventory space. Perhaps as well, the Throw action could be made available for every Familiar? This would allow Familiars to throw things to allies or move environment objects around (though I understand the game lets you also just transport item from inventory to inventory too). Another thing is buttons, switches, and levers. When fighting the ancient Grymforge boss, I was disappointed to find out that ARROWS could pull levers, but sadly familiars cannot. Again, whatever doesn't let them ought be removed in my opinion. Also, you know those small cracks or burrows or whatever that you have to be tiny or gaseous to go through? I tried making my spider Tiny with the Reduce spell. No luck. Maybe that could be allowed, too? So, picking up things, throwing, and environment interaction are my main concerns, but there's some other stuff I thought would've been nice if we could've done as well. Like, it's odd how the game goes through such length to give most animals dialogue with the Speak with Animals spell, and yet you can't ever ever speak to your familiar? It'd be nice if your familiar has some simple dialogue, with extra flavor for when that spell is cast. It'd also be nice if you could name your familiar, even if it was just through a few preset options presented by dialogue tree upon speaking to the familiar. It'd also be cool if maybe familiars could don rings or necklaces to allow the player to buff them ever so slightly. It could even be that, when the familiar dies, their equipment and inventory item(s) are left behind. These are just some ideas I hope you all appreciate. I saw some interesting familiar mods that add types of familiars, but the way they worked felt... lacking. Best of luck to any who try.

Thank you, same to you.

Lol. We thank you for your help, ExhalePit, but we said we said what said.

Thank you for repeating Post #5 where that information was already provided. Thanks for trying though, buddy.

Okay, so we tried it. Try 18: We did the above, trying to move the reference IDs into the anchor itself so that we could cut down on overrides. It was tedious, but we managed to do it for our Merged Plugins Someguy Quests file. We cut down on hundreds of thousands of records in this manner, and it still worked. Then we tested out loading the game with the prior and altered versions with the Frontier loaded. We turned off the larger merges so that this one was the crutch. With this mod on, the game would crash on the crash sites. Without it, it would work. And... the altered version made no difference at all. So unfortunately our assumption that overrides in separate plugins counts towards this record limit seems to have been false. There's no need to try this with every merge, sadly. So, we failed. Sigh. It's worth noting that perhaps we have discovered a record limit. But if overrides don't count, the record limit is probably less than 5 million. (FNVEdit doesn't seem to give us an easy way to count only non-override records.) At least something was learned from this endeavor. As for us, we'll be forced to choose between the Frontier and 2 or 3 large merges (which could amount to hundreds of mods). Because we're tenacious, we're thinking about holding off on trying to incorporate the Frontier until the moment we're ready to start it. Then, we can test whether any crash sites show up in that later save at that point. So far, no crash sites have appeared in the Frontier, so we're hoping the phenomenon could remain localized in the Mojave. We could then play it and unload the mod after playing (and reverting to prior saves). i.e. the mainstream way of playing quest mods. While we would prefer to integrate it with our game and go home with boons and rewards, that simply won't be an option for us. We've hit a limit. That's our thoughts at the moment, anyway. Thank you all for attempting to help. If anyone else ever deduces something, feel free to post here or message us.

Right right. We tried to wait for 4 days as you said. It just didn't seem to make a difference, unfortunately. We're aware of how they had done that for consoles (if we're not mistaken, the Strip being segmented was a console-induced limitation as well, no?), but that seems to us like it might have been the more traditional type of out of memory error, perhaps? i.e. simply the number of assets, not so much the sheer stuff in the entire game world. But yeah, perhaps we simply have hit another limit. We're currently trying to test our hypothetical solution to offset the anchor by moving references into an ESP instead of using an override. If our supposition that the override is making the record count twice, this should ideally cut down some of the largest chunks in half. The problem is that, without knowledge of xEdit scripting, we're doing this manually, and it is EXTREMELY TEDIOUS just to do to even one merge. We'll post results when we can. Anyone know a good xEdit scriptwriter by any chance?

That's definitely more of a full mod list then just 83 mods. You've got 110 plugins! The only error we spot right away is that you have some ESPs above ESMs, and that's a big no-no. As for the the rest of your load order, we haven't used many of those mods and can't vouch for what LOOT decided to do. We do think it odd that it told you to put the MCM near the bottom though. We usually put it at the top. You're probably best off starting over and just testing in between installs as you go. This will help to let you know when you go wrong. Oh, also, look into Archive Invalidation when you get the chance. Not sure if Vortex does anything for it, but that might be useful to know.

When you're having an error this massive, it's not the worst idea to just start over, particularly when you're not sure where you might have gone wrong. It's worth considering, especially to make sure you do the 4GB thing correctly. As for your load order, as Jim said you can post it, but that would only really help if your load order is particularly disastrous.

Is this the bug you're referring to? https://en.uesp.net/wiki/Shivering:Reference_Bug Unfortunately, we're not sure how that information can be of use. Implementing anything akin to a formal patch provided by Bethesda is surely outside our means, isn't it? But perhaps that could be a possible problem. Perhaps the Stuff is the game, for some reason, neglecting to properly recycle the IDs because of how many IDs are being used. We did try to do your suggestion of going to a cell with no NPCs and waiting 4 days. (We had to go to a different cell, because someone is in Jean's Sky Diving in our game.) But unfortunately, waiting, saving, exiting, and reloading didn't have any effect. The crash sites still crashed our game after doing all that. Currently we feel the best step forward would be to figure out how to make an FNVEdit script to move REFs into an ESP. We've been trying to figure out if that script already exists, but we've yet to find it. OTherwise, we'll need to make it (or more realistically, find someone to make it).

We had an idea, and we just tested something else. So we'll add this: Try 17: Before we can explain what we tried, we have to explain why we tried it. When making our large merges with the Merge Plugins program, we discovered that the merges simply wouldn't work as ESMs without a sort of ESP "anchor". This has to do with what records ought to be in an ESM versus an ESP. Surely some mod authors are familiar with this recommendation, as we have seen mods that come with two plugins, one ESM and one ESP. This happened with FOOK and Adult Club New Vegas, off the top of our heads. Since we aren't making these plugins from scratch but rather are just merging existing mods, our solution to this problem was to use FNVEdit to Deep Copy Override a few categories (Activator, Cell, Talking Activator, and Worldspace) into an ESP per merge. These are the anchors, and they work! Doing this procedure allows the merges to function. Removing them, they cease to function. We only did this for merges that HAD to be ESMs (like mods with non-white NPCs, for example), like Merged Plugins Major Quests and Merged Plugins Companions, but NOT Merged Plugins Perks nor Merged Plugins Apparel. So we wondered... What if we treat TF like a merge? It seems to have been constructed that way. So we made an anchor for TF, doing a Deep Copy Override on those four categories of records as we have done for past merges. What this means is that we effectively just added a plugin to our game that makes ZERO changes to the game. It should NOT break ANYTHING. But you know what it does do? It adds about another 500,000 records. And guess what? The game crashes upon loading in ANY location. The entire game is a crash site now! This seems to confirm our suspicion that Stuff is DEFINITELY correlated to the number of records in the game. It may simply be that 6 million is the limit, but again, it's not a hard limit, as it only starts with some areas becoming crash sites. It is entirely possible other things factor into this, like assets or BSAs, which would be interesting to know. At this point, three pieces of information could be helpful to us. 1. Does anyone think BSAs or loose files could help this situation? If it's counting BSAs, then fine, let's unpack them! If it's counting loose files, then fine, let's pack them into BSAs! 2. Does anyone have any better idea of what this Stuff might be? Narrowing down the problem could be useful. 3. Does anyone know why this anchoring effect is specifically helpful? Perhaps there's another way we could go about it that would cut down on the number of records in our game. EDIT: One idea we have is this. What if we could change the Cells and Worldspaces to be actually IN the anchors? If they're referenced by something, we can't do that, as it'd be a circular reference. But maybe for the rest of them? The problem is that that would be an extremely tedious process. Perhaps an FNVEdit script could be written that would check each Cell and Worldspace sub-block and move them into a separate plugin, but we know not how to do that kind of scripting. But, this wold effectively accomplish the anchoring effect with over a million fewer records.

Hm, that doesn't add up. 4 billion records? We're not coming close to that number. We added them all up. Not counting the Frontier, we have 5,555,091 records. When the Frontier is added, we have 6,315,796. So, 6 million is well under 4 billion. Perhaps it counts assets and BSAs as well? We could count that up, too? Would that count loose files as well?

Just guessing here, but your description sounds like the Frontier's assets are loaded but the plugin with the actual content isn't. i.e. things that are replaced are replaced (like menu screens), but new things, like NPCs, aren't appearing. It sounds like you'd just need to make sure the plugin is checked. However, you're using Vortex, something we personally are not very familiar with, so not able to provide anymore specificity on how to solve it with that program. (Personally we use MO2)

If you're unable to track down in the mod where it adds Expired Stimpaks, such as in a script or a leveled list or whatnot, there is one other solution you could try. It's a bit hacky, not the cleanest solution, but it would probably work. You could open the mod in FNVEdit, find the Expired Stimpak entry in Ingestible or Misc or wherever, and just right-click > Remove it. It'll still be referenced by the script or leveled list, but with the entry gone, that item should never show up. It's a last-minute workaround.

Just guessing here, but strange texture errors and missing content like this is usually indicative of exceeding the plugin limit, though if you're only using 83 mods, that doesn't exactly fit. Here are some possible solutions you might want to try: 1. Try the Mod Limit Fix mod to see if it fixes that possible issue. 2. Try using mods to make your game more efficient, such as NVAC, NVTF, NVHR, and/or FNV4GB. 3. Try using FNVEdit to make a Merged Patch. It can help to make your game more stable.

ExhalePit is correct. M48A5, you're confusing records and plugins. Records are the amount of entries in a given plugin. And you're describing the plugin limit. While other Fallout games have a plugin limit of 255, FNV has a floating plugin limit that tends to hover 120-130. On Try 3 above, you can see we tried to assess whether we needed to lower our plugin limit to a considerably lower figure, but even after turning off a dozen plugins, there was no change. Also keep in mind that we said that we were using the mod that supposedly bypasses the floating plugin limit, meaning this should already be addressed anyway. That being said, we posited that there may still be a limit of records even when bypassing the limit of plugins, and so you might be indirectly correct anyway. We are not certain.

Hello. We have a huge game install that some of you might be aware we documented in this guide. For those of you not aware, we have ideological deviations from some of our critics in the way we mod our game, but this is not about that. Our game is massive, with a prioritization on taking any mod we want and smashing them all together. We are very satisfied with the result, and we fix errors as we stumble across them. Our game has large mods like Fallout New California (FNC) and Tale of Two Wastelands (TTW) installed, and we made a myriad of patches for anything else that was necessary. Prior to the attempt to also incorporate The Frontier (TF), everything worked fine. And that brings us to what we'd like to talk about and post here today. boring specs and stuff Hypothesis: There are a maximum number of game records that a given save file can handle, and upon experiencing an overload, amounts to a sort of out-of-memory crash. Perhaps we are wrong, but we have done extensive testing and are not sure what else to make of this. Perhaps someone reading who knows more than we do can enlighten us. The problem is that we have gone through great effort to bypass and ameliorate every other limiting factor there is to make an extremely massive Fallout New Vegas, and so we feel like we've hit upon some type of hidden limit that few others experience. Again, perhaps an expert here knows about this limitation, and it's just a limitation most don't talk about because most people never make it this far. We admit that that is totally possible. Issue: A heavily-modded game that works fine has The Frontier mod added to it. Upon its addition, it mostly works perfectly fine, but the game crashes whenever brought to the larger settlements in the Mojave. Primm, Novac, and Freeside all CTD. Please note that the below tries aren't literal one-time off tries. Each try below indicates NUMEROUS launches and tests of varying orders. We're just trying to be categorical in our explanation. Try 1: So thus began our testing to resolve this issue. We had previously not met an issue we couldn't match. Can't be done? Bah! If make a patch we must, then we shall! We started by making sure that FNC, TTW, and TF could all be installed simultaneously. We made a clean profile via Mod Organizer 2 and only installed those mods, along with the patch to make FNC and TTW work together. And... it worked perfectly fine. Since TF is compatible with both FNC and TTW independently, this was not surprising. So why did our game not work? Well, you're probably thinking another mod we had was conflicting in some way or causing issues. We suspected that as well. Try 2: We began trying to identify conflicts. We tested launching the game and going to the crash sites repeatedly, turning plugins on and off, brute-force trial and error. However, to our surprise, we discovered that the issue was with... NONE of them. We tried turning on and off every plugin, even asset mods, but nothing. Well, we did discover a curious thing. Our game currently has almost 120 plugins, just under the legacy plugin limit for FNV. If we turned off several of our larger plugins, it worked. The crash sites would not induce crashes when TF was installed. The problem is that it did not matter WHICH plugins we turned off. We have the mod that supposedly lifts plugin limits (even though TF also includes that fix), but still we suspected we must be experiencing some type of plugin limit. Try 3: We tried to reduce our number of plugins without sacrificing all of our content. We turned off a dozen plugins, far more than we had done earlier, but these plugins were much smaller in scope. Things like the Take Your Time mod and other small self-referential script mods that we were unable to merge into bigger plugins. Despite turning off many more plugins, the crash sites remained active. Reducing plugins was not the answer, not unless they were sufficiently "large" plugins, like some of our largest merged plugins. Observation: By this point, we're starting to notice that there's some type of limit we're coming up against. Note that we can go into TF's world and start doing quest stuff. It's just that having it installed makes some of the more well-known and presumably heavily-modded areas in the Mojave get overwhelmed and crash. This is strange considering that TF doesn't modify these areas at all. We don't know what wall we are pushing against, as it isn't plugins or conflicts, but we start calling it Stuff. The game doesn't seem to like how much Stuff we have. Try 4: We thought that Stuff might be other assets in the form of meshes, animations, and textures. So we turned off our biggest asset mods to see if that made a difference. It did not. Note that we are familiar with what an Out of Memory error looks like, the kind of error that usually accompanies using too heavy textures. It's why we don't use 4K textures. At no point here do we get an Out of Memory error. Just CTDs. Try 5: Having exhausted ideas on the plugin side of the equation, we turned to the save. Perhaps something is wrong with it? We play very methodically and almost never have removed a mod from our current save. We're over halfway done with TTW and have already completed FNC, and so our save is around 40 MB. From searching around, that's not an unusual size for a save late-game in vanilla, but certainly bigger than average. We start testing different saves, and we discover quickly that making a brand new save and heading straight to a crash site... works. It doesn't crash. We would've tested this earlier, but you understand we're invested in making our current save work. So now that we've determined a fresh save works, how did ours go wrong? Try 6: We began testing various saves we have, because we have kept an archive of every save we've done. Our most recent save is just over number 2000, and that one doesn't work. So we try earlier ones and discover that we had to go waaaaaay back about a thousand saves to find one that works and does not crash in a crash site. We searched to try to find a single moment where we might've F'ed up in the saves, maybe find some odd incompatibility, but we couldn't find it. The strangest thing was the gradual nature of it. In between save 1000 which definitely did work and later saves that definitely didn't work, were a bunch of saves that kinda-sorta worked. They'd only crash in the crash sites sometimes or would load for a minute and THEN crash. Usually it simply crashed during loading. This gave us the impression that there wasn't a single moment of incompatibility that tainted the save. Rather, it seemed like at some point, our save have experienced too much Stuff. Note: Despite our failure to identify an issue with our save, we wonder if playing through the game with TF installed from the very first, initial save would solve the problem. Perhaps, though adding mods part-way through is usually not a problem. It's removing them. For some mods, adding part-way might be an issue depending on how its implemented, but TF is kinda plug-and-play, altering very little outside of its added worldspaces. We'd like to test this, but we can't. The only way to really test this would be to start a new save and play through 1000+ saves with the mod on to see if we could replicate the issue. We've played this game over a year, and testing this is sadly not feasible. We're forced to presume our save is fine, and considering the lack of a single moment of incompatibility, we wager that is fine. We believe trying to play through it all again would lead to the same result with it not working given a long enough period of time. Try 7: We tried cleaning our save using New Vegas Save Cleaner to see if it could junk any data or make it smaller. It had no effect whatsoever. We went through the whole process, followed the instructions. Just nothing. We presume that perhaps our save is already cleaned via some other mods and simply has little junk to remove. Either that, or the cleaner is simply outdated and of no use to us. Try 8: We thought that perhaps, since removing large mods makes it work, that we could do that and only then put them back in. But no, putting them back into the save makes it not work again. Crashes at the crash sites. No matter where TF is in our mod load order nor plugin load order. Removing and adding back in makes no difference. So now we were really stumped. Try 9: Having watched the Task Manager considerably on the other screen as the game loaded, we began to consider the numbers might bear some significance. Our game is Large Address Aware and utilizes the 4 GB feature in the executable, as is standard for TTW and TF. We noticed that every time the game crashed, the memory used never reached nor exceed 4 GB. It'd get higher than 3.8 and then crash quite frequently. We thought maybe that was the Stuff, a memory limit. Perhaps we were just achieving an Out of Memory error in a very different manner than usual. Thus we began tests to try to lower that number, which largely revolved around turning specific big mods off. Our results weren't very helpful, as the only thing that worked was turning off the big merges as already addressed. After further testing, we deliberately shot up a heavily populated area elsewhere in the game, cranking the memory up, and reloading the game. The game loaded successfully exceeding 4 GB of memory, according the Task Manager. Having made no progress, we decided this might have been a ghost we were chasing and to change tactics. Try 10: Having looked through our game extensively and coming up empty, we decide to look into TF itself. Perhaps the issue isn't us! Perhaps there's just SOMETHING in TF that is overloading our game. Maybe some kind of soft incompatibility. We start by removing what seem to be the most likely culprits: Quests and Scripts. It doesn't work. The game loads, but the crash sites still crash. We tried removing EVERYTHING in the plugin, making it a dummy plugin. Naturally, it works now. So we theorize that maybe deleting the right thing here could be the answer! Maybe we can trial and error this until we narrow down the problematic records in TF. Try 11: And so we tried that. Gutting a category of records, sometimes multiple categories. Trying, failing, restarting, replacing. We had a backup file we'd use to bring records back after each test. We wrote down each combination we tried. We tried deleting half the records to see which half it was in, and we ran into issues. Doing this didn't always result in a binary it worked or it didn't work. Sometimes the game wouldn't load. We're dissecting TF; it's not unexpected. But after elaborate testing, we managed to narrow it down to Cells, Creatures, Dialogue Topics, NPCs, and Worldspaces. Deleting those would make it work. Leaving them in would make it crash at the crash sites. So we know we need to look in one of those. Also, side-note, we had to delete Form ID Lists each time or the game wouldn't even load. Try 12: We discovered that it didn't matter which combination we did. It we restored any one of those categories, the game would work. But if we restored 2 or more, the game would not work. This was the worst news we could have received. It meant that there wasn't simply an incompatibility anywhere in TF at all. This is effectively a microcosm of the plugin tests from earlier. The only reason narrowing it down to these categories had worked was, we deduced, because they were the largest collections of records! In short, it seemed that the only thing that worked was a reduction in Stuff. It mattered not which stuff that was. Try 13: Starting to get desperate, we look for any other possible answer. We noticed that for some strange reason, nearly every single quest in TF is Start Game Enabled. We compared it to the DLCs, which in turn had nearly NO quests Start Game Enabled. We thought, hey, maybe this is a huge drain on the game! We made a patch that turned off that flag for the majority of quests (with the intention of, it this worked, making our own script and trigger that would turn them on when necessary). It didn't matter. Still didn't work. Crashes still. Try 14: We know there is some wall fighting against us, just not what it is. This Stuff. We begin to feel that the Stuff might simply be the amount of content, i.e. the number of records loaded. We look in FNVEdit at the records per plugin. The highest four plugins in order are: The Frontier.esm (700,000), Fallout3.esm (600,000), FalloutNewVegas.esm (500,000), and Merged Plugins Minor Quests.esm (400,000). We decided to make a duplicate of that merged that we called Merged Plugins Minor Quests 2. There's a high risk of something going wrong, but since it is a merge that just adds quest mods, we rationalize that it should just add doubles of every quest, NPC, and everything. The game should, hopefully, load. but alas it did not, which was inconclusive. If we could download another 700,000 worth of records to test, we could test whether that mod worked. If it didn't, it would verify that these records were indeed the Stuff that held us back. If it did work, then it would imply something uniquely wrong with TF. But, we ran into a problem... There is no mod to test. No mod compares to TF's size. None. Not TTW. Not FNC. Even our largest merge was barely more than half its size. And we don't even know what we could merge to rival that. Try 15: With nothing left to try, we do some desperate Google searches. We've already scoured the GECK wiki. We end up on TF's Nexus page. We see the optional mod for weather performance. We try it. No effect. Try 16: We make this post. Conclusion: It would seem there's a maximum amount of Stuff that can be in a game, and that figure is somehow correlated with the number of records currently in play in a given save. It would seem that a fresh save is capable of doing anything, but not EVERYTHING in a single playthrough with the upper threshold of records reached. It's conceivable that the game just starts breaking down at that point. If we kept TF installed in our game, it is possible that continued playing on this save would result in even lesser settlements in the Mojave to crash, increasing the number of crash sites. So, in truth, the hypothetical maximum of records would be the number at which it is only a matter of play time until major settlements beget CTDs. Going under that number will ensure that all areas are accessible, given no other issues, and going over that number will increase the rate of instability and accrual of crash sites, starting from the most complex areas. Future Plans: Ideally, we're hoping someone smarter than us can shed some light on our issue. We're hoping our detailed explanation of tests will allow people to treat us in good faith and assuage any fears that we're seeking trolls just because we deviate in our play style. Hopefully the responses will be free of trolls and instead have genuine concern, but don't worry, we're not expecting anyone to fix our problem. We knew what we were getting into, and we've been happy with it. We just really wanted the Frontier to be part of that experience, and it seems like we've hit some kind of limit. If anyone knows, please reach out. Otherwise, perhaps we have discovered something that might be useful to know. We could calculate our total number of records if anyone is curious to know. Sadly, if we can't resolve this, we'll just have to resign ourselves to not partaking in the Frontier or sacrificing nearly a hundred other mods to make room for it,... and that just stinks. Thank you for your time. Sincerely, Kyle and Kira

Oh goodness, thank you so much! Can't believe we didn't think of that! We'll be able to do exactly what we wanted! Thanks!

Hello there. I had another idea of a mod I thought would be cool, one I thought would be simple... But turns out it might not be? Please let me know if anyone has any idea how this mod could possibly be made possible. The idea is as follows. I simply want to rename what the Reputation Titles are. I'm not sure if that is their proper name. I am NOT talking about Faction Reputations like Goodsprings, NCR, Legion, Novac, etc. I'm talking about the titles you have with them as a product of your fame and infamy. Currently they are: Neutral -> Accepted -> Liked -> Idolized Shunned -> Mixed -> Smiling Troublemaker -> Good-Natured Rascal Hated -> Sneering Punk -> Unpredictable -> Dark Hero Vilified -> Merciful Thug -> Soft-Hearted Devil -> Wild Child I've never liked these titles. They're silly and not informative about your reputation, nor do they make sense in the world. They are the weakest part of the Reputation system in my opinion. It's annoying to usually help the NCR but occasionally defy them and be called a "Good-Natured Rascal". It's annoying to kill the Legion on sight, but you helped them once or twice, so you're called a "Merciful Thug". These titles just do not reflect your actual status at all. So I've discussed this with my partner, and we've come up with some replacement titles. We wanted them to be more descriptive of their combo of fame and infamy, and we wanted them to be consistent nouns (unlike how the pure fame/infamy are adjectives???) that don't belittle the player. Here's what we came up with: Drifter -> Ally -> Friend -> Savior Pariah -> Free Agent -> Vigilante -> Hero Enemy -> Outlaw -> Enigma -> Anti-Hero Terrorist -> Villain -> Anti-Villain -> Wild Card We feel these titles are far better than what existed. However, we've looked through the ESM. Tried FNVEdit. Tried the GECK. Where is this information stored? Is it some kind of hard-coded? Does anyone have any idea how this can be changed? All we've seen are mods that add more faction reputations, but nothing that talks about the ranks of reputation and the titles themselves. Thank you for your time.

We never did figure this out, sorry. However, very fortunately, someone else did. I just found out that, back in December, Stewie added this functionality to their mod, lStewieAl's Tweaks. Just thought I'd update this in the event anyone came searching or was curious. Thanks for attempting to help, and thanks for someone actually enacting this idea. It's pretty cool.

Thank you! Oh, there was a bunch. Like every cell in New Vegas had been touched. Only a few made actual edits. The plus sign expands to a list of references (temporary and persistent) in the cell. If there's no plus sign, then the only possible changes there could be to the cell are top-level ones (like name, ambient music, fog, lighting, etc). I kept an eye out for things like that but didn't see any changes of that nature from this mod. So I was able to determine that this mod just added references to certain cells (as it had placed some NPCs throughout the game in certain places). Such changes would be denoted by the plus sign under the cell entries under this plugin in FNVEdit. I right-clicked the entries that did not have plus signs and clicked Remove, thereby deleting them from the plugin. (Those cells would remain in whichever masters they originated, just not the changes in THIS plugin.) I didn't try to use initially disabled or deleted flags because I feared doing that might not work...

Update, my problem is solved. Thank you so much for the help. It was Ghoul Bounties. The important thing to note was that I had a dirty plugin from a small quest mod that edited a bunch of cells that it didn't need to. In FNVEdit, I simply removed all the cell entries that didn't seem to actually do anything. (FNVEdit has a plus sign that shows additional changes to cells. I removed entries with no plus signs.) Now, Gomorrah, Ultra-Luxe, and the Sink are all working fine. And any other cells that had this issue that I never discovered are hopefully fixed as well.

I can't really explain it, but I've narrowed it down to one of my quest mods. When I turn those plugins off, the problem goes away. Those plugins include the Someguy Series and Ghoul Bounties. Hm. Anyhow, what do I actually do to fix the issue? Can I go into FNVEdit and just delete the interior cell entries that one of those mods edit to the affected interior locations? Or is that a bit nuclear?

I cranked up those INI settings very high, one GB of RAM at a time. Went up to 4 GB as suggested. It never worked. Never noticed any difference. So... what can I actually do about this then? If portals are the issue, is that something that can be fixed in the plugins? A FNVEdit solution would be ideal. Like, is there a way to repair the portals in the GECK? I don't even know which plugin would be causing this. I tried turning off all ILO stuff, all TTWI stuff, but I just don't know what is causing this! Sorry, it is frustrating.

Thank you for the responses. I'll get back to you when I get the time, dubiousintent, if that helps resolve it. But I wanted to at least respond to say thank you both for giving some light on the situation in the mean tiime, and to respond to AusAllerWelt's question. Some problematic cells that come to mind are Gomorrah, the Ultra-Luxe, and the OWB Sink. I don't have a single mod for all three. But I do have TTOV for Gomorrah, its corresponding mod for Ultra-Luxe, and TTW Interiors which affects the Sink. But that would imply... Would you say this is an error that might be found within the plugins making alterations to those interiors as opposed to the INI files or settings?