Stable uGridsToLoad (by Altimor)

[hellanios]

Discussion thread:
Stable uGridsToLoad by Altimor
Wiki Link

---

Based on the feedback this mod does help solve the ugrids problem!! I think everyone should try it out!!

---

Accepted for 2.2.8

MT: We especially should be testing these *.dll/SKSE code appendages together (Player Physics, Safety Load)

I tested STEP:Core 2.2.7 without (left side) and with (right side) Safety Load, Stable uGrids, and Player Pysics. Here is SPM output from running the intro cart ride + fast travel to 9 different parts of skyrim, including Solthsiem + approx 30 second wait without mofing at all. The peak is the cart ride and returning to Windhelm from Solthsiem in both cases. Very little difference and no issues with either run. This does not really support for use in STEP:Core, but it does not refute it either. The true test is with STEP:Extended or Core with several demanding Packs installed and hours of gameplay with and without.

 

 

 

Edit: Stable uGridsToLoad was dropped after the release of 2.2.9.2 due to concerns regarding a potential memory corruption issue that was never fixed.

 

STEP does not recommend changing the uGrids setting. With DynDOLOD, there should be no need.

Edited January 6, 2016 by Nebulous112
Stable uGridsToLoad dropped

[Neovalen]

Actually Skyrim 1.9 takes care of that.

 

Sent from my XT907 using Tapatalk

[phazer11]

Oh? Huh hadn't heard that. Interesting.

[Noobsayer]

I have a question about higher ugrids in general with this baby. Since my computer can actually handle this now (I played around with a testsave and performance was fine), if I do this am I likely to miss cutscenes n such because they're triggered too far away for me to notice? Any downsides to higher ugrids other than performance?

[redirishlord]

I've been playing with ugrids set to 7 since memory patch 3.0 dropped. Smooth and stable on this;

CPU i7 4770k @ 3.5GHz
RAM 16GB (2 x 8GB DDR3 1866)
GPU NVidia GTX 670 2GB
120 GB SDD (Windows 8.1 64bit OS)
1TB 7200 RPM HDD (Skyrim)

I average 32 fps (running from Whiterun to Riften fighting random encounters through the forest) with Realvision option B full ENB according to Skyrim Performance Monitor.

The photobucket gallery should be Realvision ENB with a STEP texture base and ugrids 7 if you want a variety of distance shots, it really helps the distant terrain pop. I personally don't think ugrids 9 & greater is worth while, your mileage will vary of course (screen archers prefer higher settings, I need performance to fight ACE/Deadly Combat/ASIS style).

[Noobsayer]

So you don't have problems with stuff triggering/being over before you get there/see it etc.?

[redirishlord]

I haven't noticed any issues with ugrids 7, plays like vanilla with better graphics in the near distance. I am not running wildlife AI mods, as far as ASIS/OBIS perhaps bandits are getting a moment to prepare but that's not seeming a bad thing. I use Ewi65's advanced ini files as a guide for tuning my own config files, so I have some grass and lighting tweaks beyond the ultra settings.

[Noobsayer]

Great, thanks a bunch :)

[redirishlord]

As always, be careful tweaking your ini files, make sure you have some understanding (through research) what the values do when altered/added. For what its worth, ewi65's seem well researched and supported, but downloading and replacing your existing without any research is at risk and a leap of faith, just saying.

Best of luck (and props to Ewi, he's a generous modder).

[DoubleYou]

So, are we moving this to fixes?

[Nebulous112]

I'm wondering if this should get dropped for the new release. I noticed in this thread on the Bethesda forums, Arthmoor talks about how DynDOLOD has made altering uGrids obsolete.

 

I should fully read topics before I post to them. Apparently also fixes a bug, which I imagine hasn't been fixed elsewhere. Ignore.

Edited November 11, 2015 by Nebulous112

[Nebulous112]

FYI, more talk about this mod on the Bethesda forum. See this post, and read the subsequent exchange. It references the memory corruption issue mentioned earlier in this thread. Apparently, the below discussion referenced in this STEP thread started a day after v1.0 of Stable uGridsToLoad was released. There never was an update to the mod.

 

To give everyone an idea of what they're up to, here is an exchange from Altimor and Boris that I clipped out of a long and sprawling thread on his forum.  Don't worry if you don't understand exactly what they're talking about, but after the scams and unpardonable bollocks of the previous memory and stabilty "apps", this is a refreshing example of what technical NON-******** looks like.  :P

Keep your fingers crossed that these guys keep working on this stuff, because they may be able to uncover and address many stabilty issues in this way.

A: "Turns out there's another bug w high ugrids, an infinite loop in cell loading code. I hope to fix it tomorrow. I'm working on multithreaded cell loading atm."

A: "It definitely seems to be very finicky regarding PC differences. I can get grids up to 13 (poor performance but stable), other people have been able to use 15. For some reason if it fails the grid loading thread just continues forever. Breaking with the Visual Studio debugger during such a freeze showed that most of the threads were waiting for the grid loading thread to finish."

A: "From what I can tell the infinite loading is caused by 2 threads waiting on each other."

A: "uGridsToLoad 21: https://i.imgur.com/qtJh1tg.jpg
     Extra contrast to show distant terrain: https://i.imgur.com/i8tLHNo.jpg

I have a rudimentary fix for the threading deadlock, but I'm not convinced it's stable right now."

B: "I hope you didn't changes to functions of critical sections or other similar as it's not solution, rather new bug. Please confirm or users will corrupt their saves."

B: "Hmm, just thought that replacing thread sync functions can be good idea, if to bypass only specific threads. Gonna try myself, but such simplest tricks require heavy testing."

A: "I stop a specific WaitForSingleObject several calls deep in CellRefLockEnter, I'm aware it's probably not safe and that's why I'm not releasing it yet."

B: "Then better to detect which threads to bypass after some time, from my experience render thread and objects loading thread may work together not synced without issues to files, some graphic bugs occur, but it's minor. The same should be with sound thread (that damn with real time priority)."

B: "Just thought, any changes to sync functions may fail in "non game" conditions, like alt+tab and some time passed after this. Don't forget to test also."

 

 

The concern on the Bethesda thread is that this memory corruption issue was never fixed. The thread also mentions STEP multiple times, and the fact that STEP recommends it. Arthmoor thought STEP may not know about the issue, and suggested someone let STEP know.

 

Now, the question is - is this potential memory corruption a concern? And if so, does it outweigh the benefit of Stable uGridsToLoad fixing this problem?

Edited December 16, 2015 by Nebulous112

[DoubleYou]

Heh. If there are problems like such, then there really is no reason to use this. DynDoLOD is more than capable of providing the necessary visuals.

[TechAngel85]

I'll read over the thread. I've been for dropping this for a while now since I've never seen any benefit from it, never personally upped my ugrids, and we don't recommend other users upping their ugrids either. So the point of this mod is been moot to me for a while. If there is really a memory leak, it should be dropped.

[TechAngel85]

Seeing that the evidence is in black and white and right there for anyone to see of the memory leak never being fixed, I am for dropping this mod from the Guide ASAP. I rarely travel into the Nexus threads because it's nearly impossible to keep up with a conversation when most of the replies reference numbers for posts rather than the quoted text. Terrible design!

[DoubleYou]

I trust ShadeMe, and agree.