keithinhanoi

It's interesting and timely that a question has been raised about the compression feature of ENBoost toggled with EnableCompression= in enbost.ini. There's been some discussion about it over in this STEP forum thread as well, centering around the question of whether enabling ENBoost's compression will result lowered VRAM usage. I initially responded that enabling compression would result in reduced VRAM usage, based on some very reliable sources, but then when questioned on the varacity of that statement, I went searching for every single reference to it on the ENB forums and the ENBoost comments thread on Nexus, and revised my statement to say that according to everything mentioned about the feature, it only compresses data in system RAM - and compression in VRAM is not mentioned. So, because I and others have witnessed reduced VRAM usage in some conditions with EnableCompression=true, I went and asked Boris about it to find out once and for all whether it also compresses data stored in VRAM. His answer: So, enabling compression does not result in data being compressed in VRAM, and from what Boris said, with all other factores being the same, any reduced VRAM usage seen is only coincidence, and not related to enabling compression. Ultimately, the main benefit to enabling compression is reduced system RAM usage, which is of greatest concern for people using 32-bit Windows, or people running 64-bit windows with only 4, 6 or perhaps 8GB of system RAM. People with over 16GB on 64-bit Windows, such as myself, will probably be better advised to leave compression disabled to avoid the micro-stuttering that some people have reported with it enabled. However, like most of the ENBoost settings, it's always recommended to do testing of each setting to discover what works best on your particular computer setup.

I've only ever used markfordelete on all unwanted corpses in my game - including four instances of a stalking dragon corpse, and a fair number vampire corpses that were littering some cities, without any noticeable negative effects. I only recently found I could be using the disable command, but most information about using that seems to relate to getting rid of objects, not corpses (for example to get rid of unwanted dynamically placed birds nests from the mod SkyBirds.) So my plan is to continue to use markfordelete to get rid of any unneeded corpses that won't self-delete.

Well, the wonderful thing about the Unofficial Patches is that they are extremely well documented. In the UHP Version History page, I see this entries: UHP v1.0.1 UHP v1.0.3 From these I gather that the UP team found there was supposed to be a cooking pot placed by HF in Proudspire Manor, and so if HF didn't have a FormID for it, there would need to be a new unique Form ID for it in the UHP plugin. What I've noticed that there are loads of other mods which have included their own fixes for things that are later (or were previously) picked up by the UP team. Notable examples include major lighting mods such as ELFX. In many cases, the fix is just a re-positioning of an existing item, and you have to assume that if the mod makes a lot of changes to a cell, it would be better to let those placements "win" out in conflict management (and of course they would as they load after any of the Unofficial Patches.) But then there's items missing from the original game/DLCS which are added by other mods as well as the UPs and you run into exactly the situation you're describing. The UP team can't possibly predict or track every single mod that attempts the same fixes that the UPs do, so it's left to the user to decide how to handle the "conflict". I'd assume since you're using a customized Proudspire, find the Form ID of the cooking pot placed by UHP, and disable it, TES5Edit UDR style, so you just see the one added by the custom Proudspire mod.

@diznanl I don't see anything in your skyrim/skyrimprefs.ini files that would lead to longer loading screen times. What have you set for the two memory block allocation sizes in ssme.ini? Also, your load order doesn't show what SKSE plugins you are using, and those can potentially affect loading screen times. @EssArrBee Could you explain why occlusion culling should be turned off in enblocal.ini? That feature reduces the number of planes being rendered, and should help to increase FPS / performance a bit - which is exactly what I see when I enable it. I haven't read anything the links it to longer loading screen times or lowered performance, so it would be very helpful to know where you got that information from - TIA.

Noved742 - have you considered using ELE (Enhanced Lighting for ENB)? (https://enbseries.enbdev.com/forum/viewtopic.php?f=6&t=1930) As the name suggests, it's specifically designed to work well with ENB. Also, it's quite modular, so some plugin modules can be used in tandem with parts of ELFX. Also, it's very "friendly" with Relighting Skyrim if you were to think about switching to it from ELFX. I've had a chance to look at the example area in Whiterun next to the big tree. Changing the detailed shadow settings didn't affect things there - just deffered shadows as you had found.

Not so 'duuuh', really. You could use SNOW's main download with the blowing snow effect along with Quality Snowflakes. However SNOW's optional flakes textures download are the same files as Quality Snowflakes, so in that case it's a choice of one or the other.

Yes, well, and we all know how herding cats goes. But the great Boracle has spoken and he clearly said it used to be 10240 max. Anyhow, it's very interesting that AutodetectVideoMemorySize settles on 4800MB for your system, while the ((RAM + VRAM) - 2048) would have you setting it to 7168.

Kuldebar - another question of curiosity: Why did you decide against Soolie's HD Distant Terrain? His take is interesting because the different sets of the landscape LODs based on distance have different resolution levels. Although he doesn't provide normals or meshes, certainly Ethatron's could be "mix and matched" with Soolie's textures. Oh dear - even more testing!

Kuldebar - I'm curious as to what the ENB GUI reports your Video Memory to be, now that you're trying out AutodetectVideoMemorySize=true. Also, I've just posted on the ENB thread for 0.252 to ask Boris definitively about the limits of VideoMemorySizeMb. Jafin16 visted another thread here on STEP, and said that the max limit is 10240 (10Gb,) despite my ENB GUI reporting between 15-17Gb when I set AutodetectVideoMemorySize=true. Boris has actually answered the question before, saying the limit is 1 Terabyte (!!!!), and interestingly nobody even batted an eyelash on that reply. Well, his reply to me came damn quick, and what do you know - the limit for VideoMemorySizeMb really is 1 Tb, but based his answer, seeing a large value for Video Memory in the ENB GUI is not a good thing. So that still leaves the question of what is a good value for VideoMemorySizeMb, and although there is still a very large camp of people stating that the formula ((RAM + VRAM) - 2048) works best, when Boris was asked about it, this is how he replied: I think what he's referring to when he talks about the "other software" and "shared video memory" is DXDiag, which on my system reports shared video memory as being 4GB (4095MB to be exact) even though I've got 1GB of VRAM. So that follows his explanation of "available video memory is bigger than physical always" as Windows extends video memory by sharing system RAM with the video driver. In practical terms, however, even though he states the obvious that real video memory gives the best performance, implying that setting VideoMemorySizeMb to the equivalent of the amount of physical VRAM you've got should result in good performance, I have read again and again that following that rule of thumb has resulted in poorer performance for many users than it does when VideoMemorySizeMb is set higher than VRAM. So, going back to the topic of this thread, I'm not 100% convinced that using AutodetectVideoMemorySize=true is the best recommendation for all users as the method to set ENBoost's video memory size, nor would I be happy to settle with recommending the ((RAM + VRAM) - 2048) formula, either. No, I would say the recommendations should be based on system type (32 vs 64-bit), system RAM, and VRAM -- and those recommendations should be clearly labelled as a starting point which should be followed up with in-game testing and adjusting. I've asked Boris a follow-up question about where all that "video memory" is allocated, and after I get a reply, then I plan on asking about the EnableCompression feature - because even after some more searching and researching, I don't have a clear picture of how it works, and I haven't found a clear explanation of why VRAM usage would go down when it is enabled.

Well, I had been using Yuril's Quality SnowFlakes HD V2 with the fxsnowsoftsub.dds texture downsampled to 512 res in GIMP, but the blowing snow effect that SNOW provides is just sublime, and I actually like the optional snowflake textures better. Interestingly, I notice that SNOW's optional snowflake texture replacer doesn't include one I see in QS-HDv2 - fxsnowsub.dds, so I've asked about this in the comments thread. Anyhow, since this provides a range of resolution options and a great improvement on the vanilla effect, it seems like a good candidate for STEP: Core.

I'm not really in a position to test it at the moment, but have you tried playing with the Detailed Shadow options in the ENB GUI? I basically use ENB just for shadows (anything else slows things down way too much on my card & mod lineup,) and for example I've noticed that turning of the ShadowCastersFix option will allow some shadow effects to appear that would otherwise not show up with ENB on. One in particular is some sunlight coming through a window of the basement of the meadery in Riften, which is a super cool effect that didn't show up with ENB's shadows turned on. I'm not sure if that one instance is ELFX supplied, but I'm guessing yes. When I have a chance I can check into it more.

Sure, but I don't see any chain link, intricate lantern or woven fence -shaped mountains, hills or valleys in the landscape. I think Ethatron was trying to say the perceived performance gains of medium resolution meshes is purely psychological, and maybe that was a pre-SMIM statement. Anyhow, only one way to find out - in-game testing!

I also use the HQ-LOD's meshes and normals with LOD textures supplied RCRN (the weather mod, which supplies vanilla LOD landscape textures that are edited so areas with snow are not blindingly bright in sunny weather.) Kuldebar - I'm wondering why you opted for the medium resolution meshes, since Ethatron states he's not aware of any machine that can't handle the hiigh resolution meshes. What's really great about the HQ-LODs is that he's got a special set of red, blue & green colored textures for testing LOD distances.

I just did a bit more digging on the sources of my previous understanding that enabling compression in ENBoost will reduce VRAM usage. Probably the most trustworthy source of that idea was from Phinix, who has added explanations right into the enblocal.ini that he supplied with his Phinix Natural ENB. It's just been updated to v2.0, and when I downloaded it and checked in the enblocal.ini that it comes with, sure enough, this is what I found: //Disabling may reduce stuttering in some cases, however can also //cause significantly higher VRAM use.EnableCompression=true So, I hope that helps to explain where I've gotten that idea from. Perhaps asking Boris himself would be the best way to make sure?

blattgeist, that explanation was bad, and not based on my usual in-depth level of research. I've got no excuse for forgetting to put my normal disclaimer of "as I understand it..." So, I apologize for the confusion. I've just scoured the ENB Forums, and unfortunately this is one of those settings where a simple search for certain text will reveal the whole picture. Here's what I did find, though, mostly searching for direct quotes from Boris: Now, from all of that - as I understand it - Boris added the compression feature, without any option to disable it, in v0.200 in an effort to reduce system RAM usage of cached data. It uses LZ4 compression for 1.5:1 ratio improvement for storage of cached texture and object data. So in other words, 150MB of cached data will take up 100MB of RAM. Initially Boris talks about it being especially useful for people running on 32-bit Windows, or if enbhost.exe is not used. From this, I deduce that the compression of cached data stored in RAM is applied to memory allocated by ENBoost in Skyrim itself (TESV.exe). Much later, with ENB v0.250, he extended the memory limit of ENBoost to 128GB, "or about 192 when compression enabled." This means that the compression is also applied to cached data stored in the RAM allocated by instances of enbhost.exe. When I say "instances" this means that there can be more than one enbhost.exe running on your system. When the first instance of enbhost.exe is full with 4GB of data, another one will be started. Nowhere did I find Boris saying that the ENBoost compression added in v0.200 is applied to any data stored in the VRAM of your videocard. Also, as far as I can tell, the compression is applied in addition to whatever compression was used to make the textures themselves. So, if a particular texture file was created with DXTx compression, that gets read from your HDD/SDD, compressed using LZ4 and cached to RAM allocated by ENBoost in either TESV.exe or enbhost.exe. When that cached data is read to be used for rendering, it is decompressed and written to VRAM, in it's "original" form (ie., with DXTx compression). Adding to this, Boris reiterates something that I've read in plenty of places and makes a lot of sense - if you are using uncompressed textures, they take longer to load in cell transitions, and also take up more VRAM on your videocard. So, based on all of this, the compression feature should have no effect on VRAM usage - and this of course conflicts with a lot of reports and information I've read elsewhere (and not from Boris directly.) What will still have an effect on your VRAM usage is the size (resolution and compression) of the texture files being used in your game. After Boris introduced the compression feature, quite a few people reported that although they saw their system RAM usage decreased, the were experiencing stuttering / micro-stuttering. Finally, despite at first saying he would not change the feature, he added the EnableCompression= .ini toggle setting in ENB v0.233. I have not had a chance to read all users' reports on the enablecompression setting after it was added, but from what I did see, there are both people who experience stuttering with it enabled and others who get more stuttering with it disabled. Other important things to note are: [*]Boris' ENBoost compression feature is completely disabled when EnableUnsafeMemoryHacks=true [*]It appears that, if enabled, compression will still be used even if enbhost.exe is disabled with the setting ReduceSystemMemoryUsage=false. So, with your 16GB, I'd imagine saving on system RAM is not so much of a concern, so the advice here should be to try enabling / disabling compression to see which setting results in less stuttering / smoother gameplay. I've also edited my post with the erroneous explanation - again, a big apology for that!

Sounds good to me as well, as long as it doesn't involve a lot of time-consuming NavMesh editing to eat up your time! That's something I really need to learn how to do myself, maybe as part of the process of learning to love CK more than TES5Edit. Well, it's not performance related - though truth be told, I'm not getting the best FPS in Riften, and figured that's more to do with my lowly GPU than DoR, really.No, my issues have involved lighting and NPC routines.The lighting issues are my own, because I'm using ELFX - Exteriors, and in the end I just deleted all of the Riften worldspace edits in my copy of the ELFX - Exteriors.esp so that DoR's edits wouldn't be "fighting" with those made by ELFX. I'm also considering switching from my "switched off at day" lighting mod of choice that I've mentioned before to Lanterns of Skyrim, so I may just stop using ELFX - Exteriors altogether. I also switched out the Lantern used by DoR for the Skyrim vanilla one (for consistency, and I thought candles without a flame was strange.)As for the NPCs, I've seen one "Dock Worker" from Better Docks doing "ice skating" between two spots at night, and he otherwise just cycles between sitting on a particular bench and standing up. I couldn't find anything in TES5Edit that would be messing with his routines or behavior packages, so I'm really not sure what's going on there.Then, also late at night, a number of vanilla FormID'd Riften Guards seem to congregate just outside Black-Briar Manor, along with Dinya Balu. Sometimes one or two of the guards suddenly switches to the ready to fight idle, with their weapons drawn, even though there are no enemies near by. They all just stand there, milling around bumping into each other, and only very occasionally will one guard step away from the Manor's doorway. Everything is fine and normal at day, oddly. Again, when I look in TES5Edit, I can't find anything that would explain the strange behavior. That's it for Riften - and like I said, it's probably all my own "fault", so I wouldn't worry too much about it. However, I suppose my experience with how ELFX - Exteriors and Dawn of Riften don't get along very well shows that it might be the best advice to recommend not using ELFX - Exteriors with REGS at all. What do you think, CJ?

I wish!!! I still don't feel very comfortable in CK, let alone creating Papyrus scripts from scratch! However - It involves a kind of scripting, though in a much much simpler form.

CJ - I'm surprised neither you or anyone else has mentioned the update to Inns & Taverns to v2.0, which adds a new one, Hunter's Rest, near Shor's Stone. I'm assuming it will be fine, but have been sitting on the download waiting to install while I work through my "issues" with Dawn of Riften.

Just wanted to say that I helped David with the latest DG+DB patch plugin - I found some important sub-record data that previously wasn't forwarded from DG. Then either he rolled in the USKP fixes to make the DG+DB+USKP patch himself or got help elsewhere. Not sure, but I've got that downloaded and have taken a look at it. So I can tell you that without a doubt, neither the DG+DB or the DG+DB+USKP patch have any FormIDs which are unique to these two patch plugins. They're all changes to vanilla records, except for two, which make changes to AOS.esp FormID records. However, I've contacted David with an idea and an offer to help which would make these patches obsolete, and simplify things considerably in general. I don't want to say any more until I've heard back from him.

Thanks a bunch for the clarification - I have amended my notes that I'm using for the ENBoost explanations document I'm working on, and promise not to spread misinformation about that point (since clearly it's my mission to avoid it at all costs!) This highlights a problem with my research "method" which is just searching for quotes from Boris on a particular enblocal setting as the search string will only result in an incomplete "picture" of what the settings do. Because at times some of the more avid readers of the ENB Forums such as yourself give well-worded explanations and Boris replies with something along the lines of "That's correct," it means that the only way to build a complete picture is to pore through the entire thread for each binary build. This is a phenomenally daunting task, which is what has led to the spread of misinformation (intentional or not). Certainly, although it is true that the ENBoost settings are highly dependent on your system, they could be explained in one place in a clear enough manner and with general recommendations that I think the majority of misunderstandings could be cleared up. At least that's my ideal thinking on it - I'm not sure what you or anyone else believes.

FixSsaoWaterTransparency was removed a while ago, and IgnoreLoadingScreen was removed (and set to always enabled) in release version 0.250 or 0.251 (would have to search ENB Forums to be sure), and the FixSkyReflection and FixCursorVisibility fixes have been around for quite some time. So if you've downloaded the latest binary (0.252 as of writing this, ) then that explains the discrepancies. As far as I understand it from reading through many posts on the ENB Forums, setting EnableCompression to true will reduce system RAM usage - use Skyrim Performance Monitor or something like Process Hacker in the background to log RAM, etc. usage - but on some systems using compression will slow things down enough that you could get (micro-)stuttering, lag, or loss of smooth movement. Find out your general system RAM usage first, and if you're not getting close to maxing out (which is probably the case since you've got 16GB,) then it is likely safe to leave compression disabled. Nonetheless it's also a good idea to do some tests with the setting enabled and disabled, because some users have reported less stuttering with EnableCompression=true. Regarding your findings on AutodetectVideoMemorySize - that's a good example of exactly the kind of research that I've done and I recommend others doing. That said - be careful, because Boris has said a lot more about AutodetectVideoMemorySize since that post. In fact he has since made at least one change to the way it detects how much memory is available to allocate. But what you found there is a very important point about the setting - that it detects shared video memory (which is VRAM plus some amount of system RAM that can be used as "extended" VRAM by ENBoost.) DirectX in Windows by default will use some system RAM if available as shared video memory. This is something you can check by viewing a saved dxdiag report on your system (on Win 7 at least - not sure about Win 8). However, Boris' routine used by AutodetectVideoMemorySize definitely does not look at that shared video memory system value to make it's determination. He has explained it as something along the lines of attempting to pre-allocate some memory to see how much VRAM + RAM is available. My own experiences backs this up, as my dxdiag report shows a total of 4095MB of shared video memory while AutodetectVideoMemorySize results in ENBoost allocating 15-17GB as mentioned above. Note that this is just an upper limit, and whether all of that memory actually gets used depends on a lot of factors while playing the game. In my experience I've never seen my total TESV.exe + enbhost.exe ram usage + VRAM go over 4GB, but then, I've only got a 1GB videocard and use 1024 or 512 res textures. EDITED (16 April 2014) to fix my erroneous explanation of the EnableCompression setting. Sorry about that!

ENB settings are indeed similar to Skyrim's .ini settings with many conflicting accounts and recommendations. But it's even more difficult to discover the "truth" of the best ENBoost (enblocal.ini) settings because it is even more heavily dependent on every single facet of your system (32 vs 64 bit, Win 7 vs 8, CPU, GPU, RAM amount, VRAM amount, mod lineup, textures used, etc.) So, that's why I stick with words like "try" or "recommend" whenever I post about it. Personally though, I try to look at the direct source of information on the settings, by searching on the ENB Forums, for example "UseDefferedRendering" as the search text, and "ENBSeries" (Boris himself) as the poster. Then I can see what Boris has said about the feature. I'm in the process of putting together a comprehensive set of explanations for the enblocal.ini settings, and this is what I have for UseDefferedRendering, mostly based on posts by Boris: UseDefferedRendering ; true = Enables deferred shading rendering, which is required for most of ENB’s lighting effects. ; false = Disables deferred shading rendering, along with most of ENB’s lighting effects. ; NOTES: 1) The ENB lighting effects that require deferred shading rendering include: ambient occlusion (SSAO), image based lighting, reflections, particle lighting and skylighting. Effects not using deferred shading rendering include: detailed shadow fixes, bloom, HDR, DoF (Depth of Field), and sunrays. ; 2) Deferred shading rendering is incompatible with hardware MSAA (multisampled anti-aliasing), and it should not be used when ENB processed graphics effects are enabled. ENB’s AA must be used instead. ; 3) Although unconfirmed, the general recommendation is to set UseDefferedRendering=false if you have disabled ENB graphics processed effects with UsePatchSpeedhackWithoutGraphics=true, because enabling deferred rendering may lower performance when only using the ENBoost features. This is also true if you only want to use ENB processed graphics effects which do not require deferred shading lighting. However, you should still set bFloatPointRenderTarget=0 in your skyrimprefs.ini file. ; 4) When UsePatchSpeedhackWithoutGraphics is set to false and UseDefferedRendering is set to false the following message will be displayed in red text in Skyrim’s main menu at start up: Deferred rendering disabled so some effects are disabled. That explanation includes links to the wikipedia entry explaining deferred shading, and also an ENBForums link regarding which of ENB's graphical effect require it. As for ReservedMemorySizeMb, that's just something you'll have to experiment with, though what it should be set to seems by all accounts to be related to how much of your physical VRAM you are generally using in game. Boris has said that on some systems setting it to a higher value can help reduce stuttering in texture "heavy" areas of the game, but setting it too low or high can lead to instability. The upper limit is definitely 1GB, though, as stated by Boris. Then, regarding AutodetectVideoMemorySize, that is another one that you just have to try. As I've mentioned elsewhere in these forums, if I use it, the ENB GUI shows it has set Video Memory size to anywhere from 15-17GB, on my Win 7 x64 system with 32GB of system RAM and 1GB VRAM. I'm not seeing any CTDs that are directly related to that. But that's just me, on my system, and you may experience something different. What I can tell you for a fact is that if AutodetectVideoMemorySize is set to true, the VideoMemorySizeMb value will be ignored.

I've got a 1GB AMD like Kuldebar, albeit quite a bit slower. 1. Enable Compression helps us on VRAM usage as we're limited on actual physical video RAM memory (which I'm sure is what Kuldebar meant.) It also can slow things down a bit - translating to stutter or lack of "fluid motion" in game in areas where a significant number of textures are getting loaded / unloaded. The compression is applied when moving data from system RAM to VRAM, IIRC, because that where it's assumed your working with constraints of how much memory is available. Like everything else about ENBoost, your mileage may vary - it really depends on your system, and particularly your MB bus / PCIe / RAM / VRAM clock speeds. Jafin16 certainly seems to know his stuff, and Boris has rarely come back to correct Jafin16, so his explanations can be trusted. That doesn't stop me from reading through every post Boris has made about each ENBoost feature / enblocal.ini setting to gather what the maker himself has said on the topic (though it does require so real reverse-English translation skills to really understand it all!) 2. I also run SKSE 1.7 alpha, and implementing sheson's memory patch fix with it. I don't see any difference in stability regardless of how I set ExpandSystemMemoryX64. What I can tell you is that the setting definitely changes where some memory heap blocks are allocated in TESV.exe's memory address space. I've used the VMMap utility to confirm this - even the blocks affected by sheson's fix are moved to the top of the address space when the setting is enabled (and thus matching Boris' description of what it does.) However, I absolutely refuse to agree that the setting causes any incompatibilities with SKSE 1.7.0, and would suggest that it's much more likely due to something else - perhaps Race Menu (which is known to drastically increase block 1 heap usage) or another SKSE plug-in-based mod? But then, I also use Race Menu - no problem, so go figure. Bottom line, it's hard to know how I'm avoiding the crash with ExpandSystemMemoryX64=true when I don't get one in the first place. Honestly, I have investigated quite deeply - even asking questions of MS system engineers into what this feature does, and you are not missing out on anything performance-wise by leaving it disabled. Trust me. Just set it to whatever doesn't seem to cause more crashes, and forget about it. What did I say above....? Oh yeah, again, your mileage may vary. 3. By limited VRAM, I'm sure he means actual physical video RAM. Which I've only got 1GB of. SO Boris' comment doesn't really apply to you. General consensus as of late with ReservedMemorySizeMb is to try 128 or 256 for a 4GB vcard setup like yours. That setting seems to have much more correlation to reproducible crashes than ExpandSystemMemoryX64 does, from what I've read. But... if you're hitting your (physical) VRAM limit often, you must be using pretty hi-res textures, so then you may actually want to try setting ReservedMemorySizeMb to 512. Maxing out on VRAM also means you should consider setting VideoMemorySizeMb higher than 4096, to extend what is used as VRAM into system RAM (in enbhost.exe, as jafin16 explained.) To throw my hat into the ring on that VideoMemorySizeMb question - I am running with 4095 myself, had been using 3072 before, and have seen no difference, but when I had tried setting it to 1024 or even 1000 as some suggest - lag & stutter galore! Very interesting to note - with my 32GB of system ram, if I set AutodetectVideoMemorySize=true (which overrides ANYTHING you have set by VideoMemorySizeMb by the way) then when I check in the ENB GUI, it tells me ENBoost decided my Video Memory Size is between 15-17GB, depending on what else is running when I start Skyrim. This shows that the previous 10GB limit on the RAM+VRAM-2048 equation no longer applies, due to the new 128GB limit increase that Boris added (in 0.250, I think it was). Also, it shows that AutodetectVideoMemorySize does not just set the value to be the same as your physical VRAM size.

Finally finished my massive compatibility patch (nearly 1MB!!) for my personal line up of mods + most of REGS, and am now taking an "inspection tour" of the modified cities, towns, etc. I have to agree about Dawn of Whiterun taking FPS down too low to be worth using. So, it's ditched. I've decided just to spruce WR up just a little bit with Pines of Whiterun (mentioned some posts earlier), and I've also dropped the Bosmeric Drunken Huntsman in place as well (can see why that jumped onto Hotfiles so quick.) After just now weeding out some unnecessary 4k textures I didn't realize I had hiding in a few corners, I'm ready to continue. Next stop, Riften!

It just means Nernie's food items won't be recognized by iNeed's hunger "system". Everything else will work just fine.