Jump to content

57 GB of log files?!


Recommended Posts

Posted

My HD has been filling up fast for a couple of hours now. I tracked the data down to my Papyrus logs. When I deleted them, I'd freed up 57 gigs of HD space.

 

That seems a bit high.

 

Any ideas? My game's running stable other than running out of HD space.

 

 

Edit: Googling around, this seems pretty common. I'll figure it out. Has anybody used LvlPredatorScript?

Posted

Why is your papyrus log enabled? Unless you're testing scripts for your own mod or for someone else's, your logs should NEVER be on. It does nothing but hurt performance.

Posted

57 gig is probably the biggest size I've ever seen. Something is terribly wrong with your setup, papyrus logging enabled or not.

My own papyrus is only 15kb.  You likely have stuff causing stack dumps, which can lead to script lag and file size bloat.

If you think your game is stable, you are probably used to your fps/latency. I'd nuke everything and start over.

Posted

Checking that save with ReSaver, it had 80,000+ strings and wasn't saving anymore. Started a new character.

 

Also, pretty sure I identified the mod spamming my Papyrus log -- pretty sure (not 100 percent but close) it was DFW Support. I (stupidly) enabled debug logging for some reason yesterday afternoon. I may still go back to a save before I set that to see if the save can be... well, saved.

 

Posted

1. I'm not entirely sure it was DFWS. Looking at what I was able to load of my smallest (2.3Gb) log, it looked like it, but it may have been something else.

2. DFWS itself warns against doing what I did in enabling debug logging. In effect, it says it will spam the log. But I didn't expect anything like what happened.

3. Unfortunately, I'm not able to re-save any of the saves I made right before changing that setting, so I can't clean the saves. It looks like that character is toast. But still, that's to be expected. I'm running Crash Fixes but I still think it has trouble keeping saves with really high string counts (80k is about 15k beyond the theoretical limit) going.

Posted

The mentioned stack dumps can lead to much worse results than script lag and bloat. In essence, it means that some scripts just were skipped to be finished. That can be fine if the mods using those scripts just assume that they are finished and don't need them anymore or restart them. It can mean that basic functions of a mod won't work anymore and quests can't be started/finished because they require those scripts working. And it can lead to bloats when a mod asks over and over again if those scipts are finished, don't find related values, etc. That can hit pretty much any scripts from any mod or even vanilla scripts, and the results are completly unpredictable.

 

Bad enough, you usually don't recognize the moment they happen, and that the log were one happened is overwritten it doesn't mean the scripts are working again... it only means you can't figure out anymore when exactly it happened. And when they happen, it's pretty much never the fault of one single mod. 

To prevent them, avoid mods which run checks/scans/scripts every few seconds, and/or reduce the number of scans. Stack dumps still can happen even without any regular checks if several mods (+ Skyrim itself) run a lot of scripts at once, but it's less likely to happen. For example, getting arrested via PO in the middle of a civil war battle with several NPCs wearing devious devices is a scenario i'd try to avoid.

And it's the reason i pretty much never turn off the logs. Checking at least sizes of logs every 2.-3. time i start/quit Skyrim to be able to see if there are stack dumps and reload is it worth to lose some performance imho. Big sizes don't always mean you had a stack dump, but when they happen your log will be bigger than usual.

 

Having a high string count shouldn't be a problem anymore with crash fixes, but unfortunatly it doesn't mean you can add as much script mods as you want, there are other restrictions as well.

 

 

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...