0 of 0

File information

Last updated

Original upload

Created by

jimnms

Uploaded by

jimnms

Virus scan

Safe to use

Tags for this mod

About this mod

This fixes the GameDaysPassed variable when it becomes stuck or slows down. This variable controls the hardcore needs (food, water and sleep) meters, which causes them to sticking and stop updating in real time, and any other things that rely on this variable.

Permissions and credits
Changelogs
NVSE Users
There is a fix for this bug is included with the JIP LN NVSE Plugin. If you already have that plugin installed, make sure the fix is enabled in the .ini (I believe it is enabled by default). If you don't have that plugin installed, then install it instead of my fix.

I'll leave my fix up for people that aren't running or don't want to run NVSE for some reason

The Problem
There is a bug in the game with the global variable called GameDaysPassed.  The hardcore needs meters update based on this variable.  As this variable grows larger, it begins to slow down, eventually stopping completely.  This means on long games, you may notice your hardcore needs seem to slow down or stop updating in real time. The game still tracks this variable, it just stops updating it in real time.  It updates when you sleep, wait or fast travel, which can lead to larger spikes in your needs than you might have expected.  The variable is also saved with the game.  You might often notice that you weren't hungry, thirsty or tired when you saved, but upon loading a save, you find your hunger, thirst and sleep values significantly higher than they were when you saved.  Running at a lower TimeScale than default seems to cause the GameDaysPassed variable to break sooner [see more information below].

My Fix
My fix adds a script that calculates how much the GameDaysPassed variable should be increasing.  Each time it runs, it compares that to the current value of the GameDaysPassed variable, and if the current GameDaysPassed variable is less than what it should be, the script updates it.  It will adjust to the TimeScale, so don't worry if you run with a different TimeScale than the default (I personally prefer a TimeScale of 12).

Known Bugs
You sill still might experience spikes in your needs when loading a save game, but they should be greatly reduced than before.  I have been playing with my fix enabled for several weeks and the largest spike I noticed when loading a save was ~50 in my thirst meter, which is far better than the 400+ I sometimes got before.  I'm also using Project Nevada with increased rates.

If you enable this in an existing game, you might notice that your needs seem to accumulate faster after enabling this fix.  This isn't a bug, this is things going back to the way they should be.  That is because the GetDaysPassed value accumulates slower the higher it gets which caused your hardcore needs to slow down.

Important Notes
The first version I uploaded was a quick and dirty fix, but the latest version is a more permanent solution.  It is safe to run this on a new game because as long as the game is properly updating GameDaysPassed, my fix will not touch anything.  It only kicks in if GameDaysPassed begins to slow down or has stopped.

There are a couple of other bugs that cause the sleep meter to stick, which I have also included a fix for.  This includes your sleep meter sticking after starting DLC like Dead Money or Lonesome Road.

Installation
Download and enable it with the mod manager of your choice.

More Information
When I noticed my needs meters had stopped updating in my game and I searched for a solution, I found several fixes that didn't work.  I eventually found this forum post where Waren_AlKar mentions that the GameDaysPassed becomes bugged after exceeding 64.  I did some testing by setting GameDaysPassed to different values and monitoring it.  I noticed it seems to accumulate at an inconsistent rate whether you were inside or outside, and depending on your TimeScale.  In all cases, once the GameDaysPassed variable reached a high enough value, it would begin to accumulate slower until it stopped.  Lower TimeScales values seem to cause it to stop sooner than the default TimeScale.