MontyMM

Disabling hibernation is a good tip IMO, since it wastes a lot of space, and isn't very useful. This still allows the PC to enter very low power standby mode. The pagefile is a bit more debatable. It gets used more than you'd hope, and by putting it on an HDD, you're reducing paging back to mechanical speeds. If you're very tight for space to get a larger Skyrim installation on your SSD, this is probably a worthwhile trade-off. But for general system performance, I wouldn't do it. Some people also choose to do this to reduce wear on the SSD, but with modern SSDs I don't see this as too much of a concern.

Well, it sounds like what might happen if you removed the default assets from the data folder. I wonder if there's something wrong with your Mod Organiser setup, so that it's presenting an empty virtual data directory? I haven't used in it ages, but presumably there's some settings for default folder locations in there somewhere. That's where I'd look first.

I haven't had the chance to even look at Skyrim for a long while, but based on my recollections of testing a while back, those memory numbers strike me as very high without texture packs. Are you sure you don't have any raised settings lurking in the ini files - ugrids, cell buffers, etc? EDIT: Renamed thread, as MyBB was being an arse about the character length.

In my personal experience, healthy CPUs, GPUs and RAM only fail quite rarely, and usually due to some type of heat or electrical abuse. The ones that tend to misbehave often have something rotten about them right from the factory, as Aiyen says. I would definitely get it back to the supplier.

Just something that may be of interest, that I was looking at a while ago. In the recent (alpha) versions of 7zip, he's added the ability to rename files within the archive from the command line, using the -rn suffix. The folder paths of files in 7zip archives are just considered part of the file name, and renaming the filenames/paths does not require repacking the archive. So, you can get 7zip to dump the filenames/paths of its contents, and then use a a fairly simple script to rename them with the desired logic. Mods only come packed in a limited variety of schemes, so without too much effort you can create a procedure that will restructure almost any mod archive into a Wrye/MO friendly format, using a fairly straightforward set of logical checks on the existing path structures. This, of course, does not help if re-compressing for minimum size is the goal, but it does allow for the restructuring of STEP mods at lightning speeds. In most cases, it should also be possible to add files without decompression/re-compression.

The terrifying power of nature. Perhaps we'll all wake up before she sweeps us all aside. Regards to anyone affected by this one.

Hard to say, josh. It would depend on how good a job you did of compression vs what the author did. You would certainly expect that the author's reduced version would be better, since he would have access to the highest quality original assets, and perhaps better tools, but it is not guaranteed.

Thanks Vond. At least this removes the mystery, and tallies with the official response from Bethesda, which implies the simple 4gb limit: "Skyrim is a 32-bit program. Even if you're running on a 64-bit operating system, Skyrim was not written to utilize these features. As such, the memory that the game will utilize prior to crashing is extremely limited. We apologize for the inconvenience." I'll update the sticky post. This means we know that we have a limit for texture use, and we ought to take this into consideration for the future of the guides.

In light of all this chat about working sets and so on, it's worth checking what the figure is that Skyrim Monitor is reporting. Is it an accurate figure reported by Skyrim, or perhaps it's just pulling up the working set figure, same as the task manager? Could someone compare the figures, and also see if the Skyrim Monitor figure drops when Cleanmem trims? If so, we at least have a very likely answer to the odd figure of 3.1gb - it's only reporting the working set, and the real memory usage is simply hitting 4gb.

Makes sense to me. If I had to guess, I'd say the stutter is probably a certain number of pages being forced to the page file (and then perhaps page faulting as they are immediately read back into RAM) . It's also possible that there could be a hiccup when the Memory Manager reclassifies pages to the Standby List. There's tons of articles on how unwanted working set trimming can cause performance issues in certain scenarios. Here's one. It seems very unlikely to me that the 3GB crash is really avoided in this way. The amount of virtual memory that Skyrim is using cannot be reduced unless Skyrim itself reduces it. The thing to remember is that Task Manager does not give you an accurate figure for the Skyrim process. If you go into Task Manager processes tab, click on 'View', and choose 'Select Columns', you'll notice that the default Memory column is just the working set size. If the working set for the active process has been forcibly trimmed, then this figure can be very misleading - a portion of the Skyrim pages in RAM have been reclassified as being on the Standby List, and is no longer counted in that column. It's a lot like an accountant who moves expenditure from one column to another to make the books look better - but this doesn't actually change the amount of money you've spent. You can select a few more columns to view other aspects of memory use, but none of them will give you a true figure for what Skyrim is actually using. The 'Commit' column shows how much virtual memory has been committed to the process, but not necessarily the amount it is actually using. For any problems related to the memory address limits of a 32bit executable, it's this elusive real total of virtual memory use that matters. I'd always assumed that Skyrim Monitor profiled this figure accurately, but (and I'm not at home to check) it may also just be quoting that misleading working set figure.

I'm away at the moment, and don't have time to get into long and boring details, but I would again not recommend the use of CleanMem, or any similar application. It is almost certainly using a Windows API call to trim the working sets of running processes, which can create the appearance of a reduction in memory use, but that is all. What it won't be doing is sorting through the memory that Skyrim is actually using and deciding which bits it can "clean". Nor will it be doing anything to reclaim memory consumed by leaks, or just runaway consumption. If you're interested in this sort of thing, I'd recommend reading this article by Mark Russinov of Microsoft and Winternals.

I'm not honestly sure, as I've never done it myself. I got the impression that there is an "official" place to report bugs and issues - perhaps an online form rather than a forum thread? WilliamImm may know more.

I think that's a great idea. My apologies for derailing this thread like 10 times. No worries - hardly the crime of the century! :P It's just that it's a bit of a monster thread already, and if we get *very* lucky, it'd be good to have a thread focussed on possible solutions, rather than circumvention.

Thanks Flytrap. It might well be worth starting a new thread on the topic of optimisation and best choices to avoid 3GB, since I'd say there's a very good chance we'll be stuck with it.

I believe WilliamImm did, and I'm sure he'll let us know if he gets a response. Still, no harm in adding your own report to Beth. Might well be case of the more voices the better. I would caution to keep expectations low, though. I think it's pretty long odds we'll ever get satisfaction on this one.

Yes, I'm afraid this is another one that belongs in the large bin marked "Nonsense". Sadly, I suspect that the dreaded 3GB issue is something we're going to have to live with and work around. I very much doubt that anything short of a code fix from Beth will save us. Feel free to politely harass them!

We don't have enough inside knowledge to confirm ini settings are good or bad with 100% certainty. But given the official definition and warning about this tweak, and given that we don't include ini tweaks until we have really good evidence to support them, I would say it's not recommended.

Please use the search. This has been discussed a few times, and very recently here. As I asked before, I think it's better if we keep this particular thread for what we learn about the problem itself (if anything), and start new threads for ideas and questions about how to get around it through optimisation and tweaks.

I think we can afford much more flexibility in the troubleshooting section - if someone asks, and you happen to know, no harm in answering. But maintaining the guide with info on non-step mods is a slightly different consideration.

Thanks Kelmych. I didn't realise that this had so much functionality, and quickly switching loadouts for different situations with a hotkey is a major win IMHO. I'll have a play, but from the sound of it I would strongly support its inclusion.

I just want to make sure there's no misunderstanding. You're unlikely to hit the 3GB RAM cap while using a 1GB card because (to the best of our knowledge) the bulk of Skyrim's RAM usage with a heavy mod load is just mirroring the texture data that's in VRAM.  So, your video card would choke before you created a 3GB demand for RAM.

I've moved these posts about DDSopt, as they are a duplication of the discussion here, and I did already ask that the optimisation questions are posted in separate threads.

Yeah, I've had a certain type of techie telling me how much RAM I wouldn't need since I put 64MB in my Pentium II :P Luckily, that CPU could probably serve you well for years, and with a RAM upgrade and a new GPU when the time is right, you should be good to go. I agree with techangel though - while you're constrained by the 1GB card, you might not find the 4GB RAM a limiting factor for Skyrim. Could be cutting it close though, and suffering some performance drops here and there.

I would just add that 3.1GB is not the key figure for the possible memory related crashes. I think that was just the rough figure identified in the original post on the subject. It's a fuzzy limit around 3GB. I did a fair bit of testing, and I could reproduce crashes as low as 2.8GB

+1 to both.