Jump to content
⚠ Known Issue: Media on User Profiles ×

The GameDaysPassed variable is messed up, looking for a way to fix it.


jimnms

Recommended Posts

In my current game, my hardcore needs stopped updating in real time. I did some searching and found a couple of mods that claimed to fix them, but they didn't work. I then found this post where the last post by Waren_AlKar mentions that the GameDaysPassed variable stops working when it reaches a value of 64, and that is indeed part of the problem. The hardcore needs increase based on this variable.

 

I did some testing and found that there is more to it than it just stopping at 64. The game starts off with this variable set at 5, so I set GameDaysPassed to 5, then waited 10 game minutes and checked the GameDaysPassed variable again. I did this several times and I found that GameDaysPassed is increasing about 1.5x the actual game time. After each 10 game minute wait, the GameDaysPassed variable increased by 15 minutes. The hardcore needs also began updating since GameDaysPassed was now increasing in real-time, and they were increasing faster than they should because of this.

 

That's not the worst part though. I tested GameDaysPassed at other values, and as the value increases, it accumulates at a slower rate until it stops around 64. By the time it reaches a value of 60, it is only accumulating at 8 seconds per game minute. This causes the hardcore needs to increase slower the the longer the game lasts until they stop when GameDaysPassed reaches ~64.

 

Somewhere the game is still keeping track of things because although it doesn't update in real time anymore past a value of 64, it still increases when you sleep, rest or fast travel, which causes the hardcore needs to increase as well when you perform either of those actions. It is also being saved with the game, so when you load a save the GameDaysPassed variable is updated, which is why you might notice your needs have increased from what they were when you made the save.

 

When looking at the variable on the console or what is returned when being read by scripts calling the variable, it only returns a value out to 4 decimal places. My guess is that due to rounding the value up and down to 4 decimal places, as the value increases, it's causing it to increase more slowly the higher it goes until it reaches a certain value where it doesn't round up or takes a very long time to pass before it rounds up by that fraction.

 

My game has already passed 64 GameDaysPassed, so i threw together a quick fix, but I'm trying to think of a more permanent fix. I have briefly explored the GECK looking for what controls the needs to see if it can be separated from the GameDaysPassed variable, but I can't find it. Right now my only idea is to set GameDaysPassed to a high number (64 or higher) at the start of the game and use a script to increase it. This seems like it would be very inefficient though and there has to be a better way.

 

Does anyone know what controls the hardcore needs and is it something that can be edited in the GECK or is it hard coded? I'm looking for ideas on a way to make a fix that will work from the start of the game rather than waiting for it to break.

Link to comment
Share on other sites

Tested the issue a bit with the following in a 1-second quest script:

	let fSome := GetSecondsPassed
	if iStage > 5
		let iStage := 0
		let GameDaysPassed += 5
	endif
	printc "GDP %.8f, GSP %.6f" GameDaysPassed fSome
	let iStage += 1

Results are in the spoiler, and I took a few samples to indicate the differences. For me, it never stopped increasing, but the average value by which it increased did seem to become higher passing the 64 mark.

 

 

 

GDP 6.34132195, GSP 0.966000
GDP 6.34167671, GSP 0.999999 --> diff: 0.00035476
GDP 6.34203482, GSP 1.009999
GDP 6.34240770, GSP 0.993000
GDP 6.34276533, GSP 1.010000
GDP 11.34321404, GSP 0.999999
GDP 11.34355640, GSP 0.994999 --> diff: 0.0003416
GDP 11.34389973, GSP 0.999999
GDP 11.34424305, GSP 0.999999
GDP 11.34458637, GSP 0.999999
GDP 11.34492970, GSP 0.999999
GDP 16.34527588, GSP 1.004000
GDP 16.34564209, GSP 0.999999 --> diff: 0.00036621
GDP 16.34600639, GSP 0.993999
GDP 16.34637070, GSP 0.994999
GDP 16.34657669, GSP 0.999999
GDP 16.34694099, GSP 0.993999
GDP 21.34730721, GSP 0.999999
GDP 21.34767342, GSP 0.999999 --> diff: 0.00036621
GDP 21.34803963, GSP 0.999999
GDP 21.34840584, GSP 0.999999
GDP 21.34877205, GSP 0.999999
GDP 21.34913826, GSP 0.999999
GDP 26.34950447, GSP 0.999999
GDP 26.34987068, GSP 0.999999 --> diff: 0.00036591
GDP 26.35023689, GSP 0.999999
GDP 26.35060310, GSP 0.999999
GDP 26.35096931, GSP 0.999999
GDP 26.35133553, GSP 0.999999
GDP 31.35170174, GSP 0.999999
GDP 31.35206795, GSP 0.999999 --> diff: 0.00036621
GDP 31.35243416, GSP 0.999999
GDP 31.35280037, GSP 0.999999
GDP 31.35316658, GSP 0.999999
GDP 31.35341263, GSP 0.999999
GDP 36.35377884, GSP 0.999999
GDP 36.35403824, GSP 0.999999 --> diff: 0.0002594
GDP 36.35429764, GSP 0.999999
GDP 36.35455704, GSP 0.999999
GDP 36.35481644, GSP 0.999999
GDP 36.35507584, GSP 0.999999
GDP 41.35533524, GSP 0.999999
GDP 41.35559464, GSP 0.999999 --> diff: 0.0002594
GDP 41.35585403, GSP 0.999999
GDP 41.35611343, GSP 0.999999
GDP 41.35637283, GSP 0.999999
GDP 41.35663223, GSP 0.999999
GDP 46.35689163, GSP 0.999999
GDP 46.35715103, GSP 0.999999 --> diff: 0.0002594
GDP 46.35741043, GSP 0.999999
GDP 46.35766983, GSP 0.999999
GDP 46.35792923, GSP 0.999999
GDP 46.35818863, GSP 0.999999
GDP 51.35841751, GSP 0.999999
GDP 51.35867691, GSP 0.999999 --> diff: 0.0002594
GDP 51.35893631, GSP 0.999999
GDP 51.35919571, GSP 0.999999
GDP 51.35945511, GSP 0.999999
GDP 51.35971451, GSP 0.999999
GDP 56.35989761, GSP 0.999999
GDP 56.36015701, GSP 0.999999 --> diff: 0.0002594
GDP 56.36041641, GSP 0.999999
GDP 56.36067581, GSP 0.999999
GDP 56.36093521, GSP 0.999999
GDP 56.36119461, GSP 0.999999
GDP 61.36145401, GSP 0.999999
GDP 61.36171341, GSP 0.999999 --> diff: 0.0002594
GDP 61.36197281, GSP 0.999999
GDP 61.36223221, GSP 0.999999
GDP 61.36249161, GSP 0.999999
GDP 61.36275101, GSP 0.999999
GDP 66.36300659, GSP 0.999999
GDP 66.36346436, GSP 0.999999 --> diff: 0.00045777
GDP 66.36395264, GSP 0.999999
GDP 66.36441040, GSP 0.999999
GDP 66.36486816, GSP 0.999999
GDP 66.36532593, GSP 0.999999
GDP 71.36578369, GSP 0.999999
GDP 71.36624146, GSP 0.999999 --> diff: 0.00045777
GDP 71.36669922, GSP 0.999999
GDP 71.36715698, GSP 0.999999
GDP 71.36761475, GSP 0.999999
GDP 71.36807251, GSP 0.999999
GDP 76.36867523, GSP 0.999999
GDP 76.36913300, GSP 0.999999 --> diff: 0.00045777
GDP 76.36959076, GSP 0.999999
GDP 76.37004852, GSP 0.999999
GDP 76.37050629, GSP 0.999999
GDP 76.37096405, GSP 0.999999
GDP 81.37142181, GSP 0.999999
GDP 81.37187958, GSP 0.999999 --> diff: 0.00045777
GDP 81.37233734, GSP 0.999999
GDP 81.37277985, GSP 0.999999
GDP 81.37323761, GSP 0.999999
GDP 81.37369537, GSP 0.999999
GDP 86.37415314, GSP 0.999999
GDP 86.37461090, GSP 0.999999 --> diff: 0.00045776
GDP 86.37506866, GSP 0.999999
GDP 86.37541962, GSP 0.999999
GDP 86.37587738, GSP 0.999999
GDP 86.37633514, GSP 0.999999
GDP 91.37679291, GSP 0.999999
GDP 91.37725067, GSP 0.999999 --> diff: 0.00045776
GDP 91.37769318, GSP 0.994999
GDP 91.37815094, GSP 0.999999
GDP 91.37860870, GSP 0.999999
GDP 91.37906647, GSP 0.999999
GDP 96.37952423, GSP 0.999999
GDP 96.37998199, GSP 0.999999 --> diff: 0.00045776
GDP 96.38043976, GSP 0.999999
GDP 96.38089752, GSP 0.999999
GDP 96.38135529, GSP 0.999999
GDP 96.38181305, GSP 0.999999
GDP 101.38227081, GSP 0.999999
GDP 101.38272858, GSP 0.999999 --> diff: 0.00045777
GDP 101.38318634, GSP 0.999999

 

 

Edited by DoctaSax
Link to comment
Share on other sites

Time scale affects the rates too.

 

64 days is interesting... have you checked the gameday/month ? Sometimes they roll over into illegal values.

 

64 seems to be a recurring number, the game famously has the bethesda 64hz refresh rate bug.

Link to comment
Share on other sites

Possibly related issue I have with the game is that after many days have passed, possibly at that same 64-day mark, the stores begin restocking more rarely. I recently noticed that the actual reason this happens seems to be that the game for some reason has trouble advancing the day of the week at midnight after enough time has passed. Waiting or sleeping past midnight helps with this, but not 100% of the time.

Edited by Crowley9
Link to comment
Share on other sites

Tested the issue a bit with the following in a 1-second quest script:
	let fSome := GetSecondsPassed
	if iStage > 5
		let iStage := 0
		let GameDaysPassed += 5
	endif
	printc "GDP %.8f, GSP %.6f" GameDaysPassed fSome
	let iStage += 1

Results are in the spoiler, and I took a few samples to indicate the differences. For me, it never stopped increasing, but the average value by which it increased did seem to become higher passing the 64 mark.

 

Where were you when you did your test? When I did my initial testing, I just used the console and wrote down the values reported from there. I did the tests where I was in the game at the time, which was at the radio station northeast of Bitter Springs (Bravo I think).

 

When I was making the script to fix it, I used NVSE's PrintF function to output to a log so I could keep an eye on what was going on and make sure nothing was messing up. I made a few changes to its output format, then I did some more tests last night and things got weirder. I started by setting GameDaysPassed to 20, let it run for a minute then incremented it by 10 up to 100.

 

I'm currently in the Lucky 38 suite, so that's where I ran my test. The GameDaysPassed variable accumulated correctly (well slightly fast) until somewhere between 60 and 70 where it drastically slowed down. It was still accumulating, even at 100, so I just bumped it to 150 and there it completely stopped.

 

That was totally different than what I got from my previous test, but like I said, I was outside when I did that test. I went outside and ran it again. I got about the same results as my initial test It was accumulating about 1.25x faster than it should until it slowed way down at 40 and stopping completely at 70.

 

I dumped the logs to Google Spreadsheets. Here is the indoor test and here is the outdoor test.

Link to comment
Share on other sites

  • 2 months later...

Update: The mod "Timescale Pacemaker" by Asterra was developed specifically to address this issue. See the comments for one on 14 Sep 2017 by DoctaSax which explains the source of the problem (single-precision math using double-precision values).

 

Added 'Issue: GLOB variable 'GameDaysPassed' doesn't advance or suddenly jumps' to "Misc." section in the wiki "Fallout NV Mod Conflict Troubleshooting" guide.

 

-Dubious-

Link to comment
Share on other sites

Thanks dubiousintent, I'll take a look at that. My temporary fix is working for me and I was too busy playing the game to work on a permanent fix. As Red Green said, "this is only temporary, unless it works."

Link to comment
Share on other sites

  • Recently Browsing   0 members

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