uGridstoload=9 causes massive CTD problems

[SoulReaver911]

 

As mentioned in the opening post i already set it back to 5. The question was if there is any solution for setting it to 9 again without causing massive CTD problems. Maybe by adjusting some other things in the ini?

create a mod of your own in the geck, prior to loading the mod in the data windows as set active, above, the main settings for the games overall appearance is set to a default 800 x 600 very low settings. you need to set this twice, once before loading your project, and once at the moment of saving it. 7 is Ideal for the geck, 9 is too much as the settings when set to fill LOD and view, will exceed level 9 anyways.

 

this tends to crash the geck but! it will save it as a back up. once you have captured the save in the editor, you can delete the esp it made, rename the bak file as your project and you have full LOD view on any settings you choose.

 

kitty.

 

Purr4me's method works 100%

 

This is one of the coolest workarounds I've ever seen. Use it.

 

Purr4me, I'm thinking this would be a great upload on the nexus. Of course, it wouldn't be customized to each user's preference but you could add a little tutorial, or I'd could write one for you if you like. The defualt uploaded file could have everything set to about 3/4 of the way, and I think this would be reasonable.

 

Btw, the GECK didn't crash on me, so I didn't have to mess with any backups. :biggrin:

 

Results:

 

---With the .esp---

 

I set the gridstoload to 13 in FoFig just to be daring and loaded up the game. The load screen took a slightly little more time than usual, however when I got outside it was working! I ran around using the sprint mod for about 10 mins and no crashes. However, there was a fps drop everytime I went into a new cell (though ususally not on the way back.) This was barely considerable seeing as this happens to me on a regular basis. The game overall had a lower fps which was to be expected, however my comps specs are not too high end. I'd be happy to set gridstoload to about 7 or perhaps 8.

 

---Without the .esp---

 

With both tests I loaded up the game inside the mansion in Point Lookout so I was in an interior to begin with. This time when I left the mansion to see the outside world:

 

immediate crash.

 

 

 

Thanks Purr4Me!!!

 

EDIT:

 

No really, Thank You. This is AWESOME

 

EDIT 2:

 

Alright, here's something I noticed that I figured I would forewarn any using this method.

 

There is no going back

 

That is, on any game you save you make after enabling these changes. Previous game states will be fine.

 

A Tip:

 

Change the gridstoload a single digit at a time and playtest for at least 10 mins preferably in multiple locations Before making any game saves.

 

If there is a way to fix a game save after making these changes, please enlighten me. Otherwise, well worth the price once you get it all set up the way you like (no limitations on any processing settings!)

Edited April 14, 2013 by SoulReaver911

[Purr4me]

EDIT 2:

 

Alright, here's something I noticed that I figured I would forewarn any using this method.

 

There is no going back

 

That is, on any game you save you make after enabling these changes. Previous game states will be fine.

That is right ,once you touch the ini files, the geck will establish only your settings into the files data base, so, with any file you upload here, you need to add in instructions for those to also update their ini files that same exact way, or the file will NOT load. Nor will older saved games load if you mess with ini files in between throughways. older saved games will not load once they have changed. it's the video cards settings and graphics being the culprit.

If there is a way to fix a game save after making these changes, please enlighten me. Otherwise, well worth the price once you get it all set up the way you like (no limitations on any processing settings!)

That is the bad part, see, every one in the past 5 years has not concentrated on development for any saved game management tools. some do little but mess things up. If the effort was put forward to that end, then perhaps we might stand a chance to run any modified saved game or file on any game. That will always be there till one day, a really gifted individual will offer up such a tool. I can't upload mine, because I use licensed tools I can not distribute. Beside, Microsoft would hang me for that.

 

you can how ever at least see the bugs if you know the name of it using notepad ++, it is a free enterprise and loaded with options, but only to see things, the format it saves things in is not compatible with havock. requires some really-hard to do tech management to get it to save an edit so you can test and esm or esp, and still not usable.

 

Thanks for the post. do what you can, I'll sign it.

 

Kitty.

[Purr4me]

I just wanted to add something here, My method allows a u grid Equal to approximately 10.5 if you could call-it fractional, but, it also fixes a lot of distance bugs, cell loading bugs. Stabilizes the game. and the ini is set to =5 as in default. Now, if you touch your ini file just-for your own use, and set it up to 7,8,9,10,11 etc... you will have massive distance increase and massive hits on the system. So leave it alone, Grass, that one setting by it's self will eat up Ram real estate very fast and you will limit out and crash. stay above 4 and you should do alright. use a texture mod if need be to get more visual things. but the game global Bloatware needs to stop. it's not needed to have all these nice things and be running over 35 gig's of data. Most armor, weapon, skins of any thing can be reprogrammed in one esp / esm file and be equivalent to 35 gig's of junk......(in a file under 100 megabytes.)

 

The game raw with all dlc's and it's bsa archives is just over 5.5 gig's installed. the most you really need is 10 gig's. after that? it get s too complicated to track stuff.

 

Kitty.

[SoulReaver911]

Yeah, I agree, it's best to set ugridstoload around 5, but the option is still there for those who wish to use it. The esp you showed me is doubly useful cause now I'm not getting crashes when I set Lod object and tree distance really high (above the "official" maximum). Beforehand, I was getting crashes even when I was below and near to this supposed cap.

 

I'm thinking that this method you taught me is not applicable as a download. I'm thinking some wouldn't read the docs that come with it too closely and perhaps not make backup saves and when they change their settings back they can't play their save game.

 

I've been contemplating writing an all-around troubleshooting guide that I can post on the forum and as a download on the Nexus. So I'm thinking I want to add this info there instead, and I'll make sure to give you full credit.

 

 

It's not needed to have all these nice things and be running over 35 gig's of data. Most armor, weapon, skins of any thing can be reprogrammed in one esp / esm file and be equivalent to 35 gig's of junk......(in a file under 100 megabytes.)

 

The game raw with all dlc's and it's bsa archives is just over 5.5 gig's installed. the most you really need is 10 gig's. after that? it get s too complicated to track stuff.

 

Kitty.

 

 

I've been making a lot of BORG esps ever since I hit that cap where the game can't load textures correctly because there are too many esps/esms. (I'm dreaming up a way to make ONE single ESM, but this is daunting.) This fixes up the problem right quick (as far as I can tell.)

 

But I'm not sure what you mean when you write that borging esps can save many gigs of hard drive space (and thus game processing time) because all the esps and esms I'm using combined equate to less than half a gig (though I agree, there is still bloat in there. Working on it.)

 

Yeah, the armor mods are generally pretty easy to combine, but I can't even begin to touch heavily scripted mods without losing functionality. Not really sure why, but I'd like to know.

[Purr4me]

• Ok.
• 1. i have combined over 1000 mods in to a single mod, it took me well over 4 months to configure, wit that I found my self faced with over 40 gigs of data, and the engine cap is only 2 gig's maxed out, that does not count performance spikes, that exceeds the thresholds the engine can handle and CTD.
• 2. Of that, I found the same exact data replicated 100's of times by all mod authors.
• 3 so, I use an old explorer program like acdc type of thing to organized that data on a separate drive. removed exact duplicates and ended up with just under 1 gig.
• 4. how this happens is the folder and path statements each author made, it's all contained from the main games BSA archives. Why on earth, use a dead horse over and over again?
• 5 weapons, how many weapons are in fallout 3? how many weapons are made from fallout's data? how many types of weapons can there be? and how many can you use in one game? Eliminate the bloat.
• 6 the tool "Fo3edit" allows you to see a simple structure, a cell compartmentalized and very neat.
• 7the geck does this too But it branches out the sections and categories in separate windows. Both do the same thing and yet not.
• 8I look in a texture folder and see yet another texture folder, ok, so I look in that one too, I am now 2 folders deep.
• 9windows DOES not like LONG file names. GOT that? Big mistake not to control packaging here in any of these game and posting really bad path schemes. Every one wants it to be unique and have it their way, so their code does not step on others codes.
• 10. something needs to give way because memory leaks start at 1024 in the kernel. any data processing beyound that and errors begin to occur, The OS in in charge of the run time process and NO one thinks about that at all.
• Rules: are in place to facilitate this thinking and it has never stopped. It never will. BUT, if there is a set of rules in place, like the mod base is supposed to be, use only whats on the games disc, you don't need to change path. we already have overwrites of over writes of overwrites, ...on and on it goes, till a corrupt type gets in there and it's Finite to locate and fix.
• any mesh file can upset a script and vice verse. A texture can also cause bad things to happen. Scripting relies on the path. Deviate from a path, and make new ones exaggerates this problem how big can a mod get? Very very big ! ? does it need to be that big?
• No. it does not. The geck default loads up. and you will see just fallout alone ticked in the data to make a new mod, has bugs, or complains about things not right. Well, Remastered has the missing elements in it's bsa archive and the geck does not complain any more. thing is, you don't tick a BSA archive in the geck, it just needs to be present in the data folder. The same goes for the DLC's If it's there, then no complaints are seen. IF you add things into that folder, the geck WILL pick them up and load them in ram. So, no editing others mods with others mods data installed at all. all mod authors need to show what was used. Here in lies the problem. sharing is caring and some care not. the care not's do it their way and the heck with anyone else. So we have a variety of fun things to play with, only it's all the same things in different places eating up space.
• 11. the tools are made with all this in mind, so knowing that means IF we set out to fix this big bug, you are in for a fight.

The real question is now, do you want to Fight every one? because that's what's in front of you to even think about taking on this kind of Endeavor.

I know I am tired of it. I know the reasons for it and can acclimate my self from it's Viral infectious nature. My posts are hard to read. I admit that. it;s open to interpretation and good minded people will think long and hard. those in a hurry or not interested will not bother to read it, or shun it.

I answered a very tough question a few days ago on the AQFH page demo 3 mod thread. any one worth their salt can use any tools at hand and understand the depth of my post. any one not having the knowledge will not understand why I posted that answer. Till they them selves attempt to mod the game and deal with what we deal with, they never will. OMG, another wall of text. Sorry. Done.

 

Kitty.

[SoulReaver911]

Wall of text or no, I appreciate you putting in your experience, even if I did by chance cause some irritation on your weary soul (sorry bout that.)

Its true I always read your posts a couple of times, but it's mainly because you're talking about things I'm not accustomed to. I can't speak for others, but from where I'm reading, your posts are illuminating.

I'm looking at your experience with this game and it's really making me think. Is it really worth all this hassle? I was just looking at suggestions online for modifying the page file to try and accommodate for some of these memory leaks you mention inevitably happen when you've got more than a gig of mods loaded in game, but this doesn't fix the actual problem (though the page file could probably use some tweaking anyway.)

I enjoy the game as I use it now, and I feel I've eliminated many a problem yet I have a long road ahead if I want to go it all the way like you did. That is simply Incredible that you managed to get the size of your installed mods down to a fortieth.

I will consider your warning carefully.

Edited April 16, 2013 by SoulReaver911

[ERASERhead1]

It's definitely an engine limitation, as previously stated.

 

I just bought a Titan with 6gb VRam, best single GPU chip out right now, and I get CTD with uGrids at 7,9,11,13.

 

Even with over 150 mods in and downsampling to 3200x1800 resolution, I get solid 60 FPS with random CTD with UGrids higher than 5.

 

The game only uses 50 - 70% (tops) of the GPU, so it's an engine limitation.

 

Just letting you guys know.

[SuchFalloutVeryRads]

http://forums.nexusmods.com/index.php?/topic/1340369-skyrim-memory-patch-fixing-ils-ugrids-ctd-freezes-for-real-by-sheson/

 

Good news!

Hopefully this can be implemented with fallout.