Interestingly, JIP's GLOB fix isn't working for me, even though my NVSE and eveything is all up to date. As it stands, this is the only thing that works for me right now. So thanks :)
JIP's nvse plugin v. 51.60 now comes with a fix for this too, and from what I hear it's more precise. Not that this isn't a valiant effort, but there's little point in having both installed. The same goes for jimnms' fix.
Thank you for the heads up. I've tested it and it works just as well. Thoughts:
1. The only way it is "more precise" is that it has the luxury of being able to update more regularly than every three seconds. Other than that, both JIP's and mine are basically atomic clocks. 2. Contrary to what is asserted, GameHours does not actually ever suffer from the same problem as GameDaysPassed. 3. The timing of this update is more than a little suspect. 4. If nothing else, this mod remains NVSE-independent.
1. Are you sure it doesn't actually fix the bug at its core? JIP does a lot of magical things with the engine, so I wouldn't be entirely surprised if that's what happened.
2. Well... I didn't see anyone asserting that, so I can't really comment.
3. Suspect? Are you implying something bad...? If this mod had any influence over JIP, it would likely have been 'Oh hey, that's broken. I might as well take a look... oh wow, I can fix that pretty easily!' and then the bug was fixed.
4. Yeah, that's still good for people who don't want to/can't use NVSE for any reason.
> Are you sure it doesn't actually fix the bug at its core?
After my tests, I'm almost certain that's precisely what it is doing: Correcting the issue at its core, which was most likely based on decimal place truncation as earlier speculated. This doesn't change what I asserted, though: Both the plugin and this mod provide the same precision, give or take the trivial, temporary aberration engendered by three-second updates.
> Well... I didn't see anyone asserting that, so I can't really comment.
It's in the JIP changelog.
> Are you implying something bad...?
It is just me grumbling. I toiled on this mod for many hours, fixed something modestly fundamental that'd been broken for almost seven years with nobody noticing, and within half a week, I'm informed that a "more precise" iteration has demoted mine to "valiant effort". Effectively I wasted that time giving someone else an idea. I think I deserve to grumble. ;p
1. I wonder... does JIP resync the variable, or does it just start ticking again?
2. Maybe JIP saw the same sort of bug COULD affect the 'gamehour' variable, but it hasn't actually been seen in practice? Then they just assumed that it was affected without checking if it actually was. If I had to take a guess based on how I assume that variable would function, it ticks up to 23 and then goes back to 0, so the bug is never actually experienced since it doesn't get that high. Or something, I don't know, that was just guess; I don't actually know if the variable does that, but I think it does?
3. Yeah, I can imagine that would suck. Still, you have to admit that it's great to have the bug truly fixed in a way that doesn't take up loadorder space, huh?
> I wonder... does JIP resync the variable, or does it just start ticking again?
It's not syncing, that's almost certain. There are tests I grew accustomed to performing which made this clear. It is straight up incrementing, but with precision as opposed to failing the way GameDaysPassed natively does.
> Maybe JIP saw the same sort of bug COULD affect the 'gamehour' variable, but it hasn't actually been seen in practice? Then they just assumed that it was affected without checking if it actually was.
After extensive testing -- I used my own mod, after all -- I can at the very least say that if GameHours ever inherently provides inaccurate numbers, they are on an order that is flatly unidentifiable under even extreme playtimes and timescales.
> Still, you have to admit that it's great to have the bug truly fixed in a way that doesn't take up loadorder space, huh?
Absolutely. But it wouldn't have hurt to be informed before I finished, to save me some time, or acknowledged after I was finished, to keep me from feeling like I got pickpocketed.
1. His fix is not only more precise because the value is updated more frequently, but also because an nvse plugin isn't bound by the same precision limit for math as GeckScript is. 2. It wouldn't be the first time I've heard that GameHour isn't accurate sometimes. It may not freeze, but that doesn't mean it can't be wrong. 3. The issue was on jip's radar before this mod's release - I remember talking about it on the TTW discord when I saw jimnms's thread. We revisited the bug later, discussing the cause, and if he'd be willing to fix it. It was left up in the air, time passed, a release came. Nothing suspect about any of that.
> His fix is not only more precise because the value is updated more frequently, but also because an nvse plugin isn't bound by the same precision limit for math as GeckScript is.
Which implies that GameHour -- the variable which this mod re-syncs to every interval -- is being updated via GeckScript, as opposed to something more internal and precise. That would make it difficult to explain why GameHour is effectively incontrovertible in its precision.
The variable is also updated by the engine directly when sleeping/waiting and normally as time passes, and not by script.
I've been aware of this issue for a long time, and only started looking into it again when this thread was started https://forums.nexusmods.com/index.php?/topic/5793832-the-gamedayspassed-variable-is-messed-up-looking-for-a-way-to-fix-it/ back in july by jimnns.
It is a coincidence that you released your mod so close to the fix being done in jipln. As DoctaSax stated we had already been discussing it on TTW's discord and in private for a long time, along with many many other engine bugs, that some also have fixes for now.
Everyone wants to have a bug free game, and people also often have the same ideas for similar mods. This is nothing new and should be expected. No one is trying to steal your fire. Also as stated there are many people who are vehemently against using NVSE (for whatever reason) and will find your fix to their liking.
I would first like to commend you for taking the initiative and providing a working fix for a serious game issue.
I just wanted to clarify a few things.
The game time globals issue, and the related hardcore needs issue, were brought to my attention a couple of weeks ago, in discord conversations with such people as RoyBatty, DoctaSax and _Voidwalker. I then started investigating a way to fix it. That was before you released your mod. Since I'm not a mind reader, there is no way I could have possibly known that you were working on a similar fix at the same time. I'm sorry that you feel like you've been "pickpocketed".
JIP LN fixes this issue at the engine level, by actually replacing the internal subroutine, responsible for incrementing game time globals, with a custom-made one, which performs floating-point arithmetic with double-precision (as opposed to the game's single-precision). Moreover, it is optimized and uses a set of low-level instructions which are much faster (though, within the big picture, the difference in performance is rather negligable).
Kudos for the bugfix! I'm curious how a different game start date affects the mod? In our Fallout - New California (Project Brazil) mod, at the start of a game, we set the year to 2260.
Specifically, we have these settings:
set GameYear to 2260 set GameHour to 19 set GameDay to 23 set GameMonth to 10 set timescale to 8
First test: started this fix with my long time savegame on a monday at about 6 pm (GDP: about 330.75...). I was waiting a bit at home. Day changed from monday to tuesday at 12.01 am (GDP: 331) and at 6 am, GDP was showing 331.25. Everything's correct and it updates in real time without doing anything else.
Before this, GDP wasn't stuck in my game, but updated really slowly. (Like jimnms told. I was using his fix before. Thanks for this.)
After this first test I can say: great fix! Thank you very much for this.
Well, I played a bit longer today (about 3 ingame days) as a second test and your fix works fine with my game and the GDP value.
In my long time savegame I'm in the year 2285 now, so this value of 330 can't be true. I noticed this bug when the GDP was at about 291 (yes, very late) and saw that it updated really slowly. Then I found jimnms fix and worked with it til today. I started your fix with the value of about 330.75 and since then it updates in real time again.
Normally the value had to be over 1000 now, as the game starts in the year 2281, but I'm happy that the GDP updates in real time again and the weekdays changes at midnight with this. Before, I had to quicksave and quickload right before midnight to have a normal weekday change.
> In my long time savegame I'm in the year 2285 now, so this value of 330 can't be true.
The behavior of v1.1 differs, in that it now stores and adjusts for any discrepancy that exists the first time one plays with the mod installed. This was made the default behavior because of the fact that without some kind of external counter (god mode or another mod), anyone playing Hardcore is likely to die from any major adjustments to GameDaysPassed, including the one the mod originally made on initialization. And since surviving two-week modifications to the date is the default vanilla behavior for DLC transitions, there remained no real point in keeping GameDaysPassed the exact same value as the date.
If you aren't concerned about this, you can use v1.0 of the mod.
Yes, I noticed that, but everything's fine with 1.1 for me. The jump between current GDP value and ingame date would be much too high when I think about some GDP based mods and all respawns and so on. You did a great job and again I'm happy to see GDP updating in real time now.
I started a post on the Nexus Forums a couple of months ago looking for help to fix this bug, and it looks like you might have done it (I haven't actually tried your fix yet as I'm on a break right now). Check out the post to see more details about what I and a few others observed testing the variable. In summary, I noticed my hardcore needs meters weren't working and discovered it was because the GameDaysPassed variable stopped updating. I did some testing and I noticed that it updates at different rates the longer the game goes on and whether you are inside or outside. Outside, GameDaysPassed updates at 1.25x to 1.5x faster than it should, until around 40 when it suddenly slows way down, accumulating only a few seconds per minute, then it stops around 64. Inside it also updates faster than it should (but not as fast as outside) up to 64, where it suddenly slows down and keeps updating slowly even passed a value of 100.
I slapped together a quick fix for personal use so I could continue my game without broken hardcore needs, but I decided to upload it because I figured other people might be interested in it even if it was just a quick and dirty fix and maybe someone could improve on it. My fix only works once the variable stops updating though, which means it does nothing when GameDaysPassed slows down. I never got around to making a more permanent solution, because well, as Red Green says, "This is only temporary, unless it works." For a permanent fix, I was thinking about just forcing GameDaysPassed to a high value from the beginning (above where it stops working normally) and let my script update it.
I just took a quick peak at your script. It looks like you're forcing GameDaysPassed to a value based on the GameHour/GameDay/GameMonth/GameYear variables and adjusting it to be equal to the number of days since the start date of the game. I didn't think of doing it that way. I set GameDaysPassed to the previous GameDaysPassed + ( GetSecondsPassed * TimeScale ) / 86400.
Both your script and the game are updating GameDaysPassed at the same time. This is what was bothering me when I tried to come up with a permanent solution. If the GameDaysPassed has not reached a high enough value where it slows down or stops, then it's possible another script can read the GameDaysPassed variable before the script fixes it. That's probably shouldn't cause any problems, but the hardcore needs may still accumulate faster than they should in the early game if the needs meter reads the GameDaysPassed variable before the script fixes it. Again, that's not really a huge problem, I'm just kind of OCD and it bothered me knowing that, so I was looking for a way to completely override the game's GameDaysPassed with a script. That's why I was thinking about setting the initial GameDaysPassed to a high value where it stops completely and letting the script take care of it. I don't know if having a high value for GameDaysPassed would cause issues and I didn't have time to test it either.
> If the GameDaysPassed has not reached a high enough value where it slows down or stops, then it's possible another script can read the GameDaysPassed variable before the script fixes it.
This is true, but since we are talking about a maximum three second lag between corrective tweaks, in addition to the fact that the internal GameDaysPassed modifies itself rather than recalculating from scratch, any difference we're talking about is going to be far too trivial to matter.
> That's probably shouldn't cause any problems, but the hardcore needs may still accumulate faster than they should in the early game if the needs meter reads the GameDaysPassed variable before the script fixes it.
Needs are going to accumulate a trifle faster solely because GameDaysPassed inherently lagged behind true game days passed on the whole. The point is that this was not intended behavior, and it certainly wasn't intended that needs and other factors reliant upon GameDaysPassed would potentially freeze outright. You seem to believe that the frame-by-frame GameDaysPassed updates and the tweaks enforced by this mod are causing the variable to go back and forth between increasingly disparate values. I think the important missing ingredient here is the fact that the internal mechanism only adds to whatever GameDaysPassed happens to be, whereas this mod forces specific values calculated from the reliable variables you earlier cited.
Here's an example of what happens to the variable, the way I understand the mod. Note that the numbers were found residing in my rectum, and have been placed here for your viewing pleasure.
Say a normal GameDaysPassed variable of 3.123213123, and at this point, the game for some reason decides to add 0.125321. That would make the number 3.248534123, an imperceptible change to most any function. This mod then kicks in, and changes the 3.248534123 to 25.10, and the game then ticks again, making the variable 25.225321. The next time the mod ticks, it would set that back to 25.10. The flip-flop is so tiny that it's inconsequential. And if you're early on in the game and GameDaysPassed is ticking normally, the mod will just keep setting it to about the same number. I don't know if any of that was a reasonable scenario, but I think it works for an example.
> Here's an example of what happens to the variable, the way I understand the mod.
In a nutshell, yes. I did an off-the-cuff bit of calculating myself. Assuming an internal worst-case inaccuracy of 100% (GameDaysPassed is frozen with no change) and a maximal Timescale of 30, the highest possible disparity a mod might encounter -- right before this mod kicks in on its three-second interval -- is 0.00104 days, or 90 non-realtime seconds. If Hardcore needs pick up on this, for example, one would have a small chance of briefly seeing dehydration lag by one point.
I encountered a problem with the mod. It might be because of TTW or an interaction with another mod, like Project Nevada. When I load a savegame, my thirst, hunger and sleep are increased by big number. I tested it and I can just load the same save game multiple times and the thirst hunger and sleep will be higher every time.
This is the behavior of the first version of the mod. (Except that there should definitely not be a cumulative effect across multiple saves.) If this is happening with v1.1, you might try first creating a save with the mod not enabled at all, and then loading that save with the mod freshly enabled.
Does the new function which deals with The Divide and Zion also account for other mods advancing time? It would be awful to require a patch for every use of that or a similar function.
The time advancement for both DLCs is variable: Honest Hearts advances 14 days plus or minus up to half a day depending on the time of day before traveling; trips to/from Zion after the initial trip are a flat 14 days; trips to/from Lonesome Road's The Divide are three days plus or minus up to half a day; Dead Money does not advance time. Given this variability, I found the best solution was to treat all discrepancies exceeding a minimum of 2.2 days to be invalid for advancing GameDaysPassed. The mod now captures any initial discrepancy (such as from being installed mid-game) by default.
I do not know of any mod that takes it upon itself to advance time, but that is the criterion: 2.2 days. This can be adjusted for the sake of other mods if absolutely necessary, but the adjustment I have made in v1.1 is meant to adhere to the behavior of the vanilla game, inasmuch as avoiding game-breaking phenomena such as instant death, and that was what dictated my solution.
Does that mean GameDaysPassed will still be made accurate, or will it remain off by whatever offset it got to and then advance normally from there? Do you mean 'invalid' as in the mod will ignore it and GameDaysPassed will not increment, or do you have some system to keep it correct while not killing you?
> Does that mean GameDaysPassed will still be made accurate, or will it remain off by whatever offset it got to and then advance normally from there?
The latter. This is the vanilla behavior when it comes to DLC transitions. Anyway, the ultimate point of this mod isn't the maintenance of sync so much as the avoidance of script/respawn/etc. timing issues.
> Do you mean 'invalid' as in the mod will ignore it and GameDaysPassed will not increment, or do you have some system to keep it correct while not killing you?
The former. The mod doesn't ignore it but rather takes it into account for future calculations.
Just a heads up, when travelling between locations such as the divide or zion (they take 2/14 days in game time to travel to, respectively) the GameDaysPassed ticks up after they clear your hardcore stats, meaning you'll likely die as soon as you enter those locations. I got around it by activating god mode and dealing with those stats accordingly. Just thought I'd pop this in here should there be a way to fix it. Love the mod, great job Asterra!
Should it also work in Tale of Two Wastelands? I normally set timescale back to default when I encounter weird bugs, but I prefer 6, so it would be perfect if this fixes those issues.
Not going to claim fixing one variable is going to fix everything weird that may occur with lower timescales -- there are, for example, cases where quests are set up to progress based on the passage of the time of day, and thus using a Timescale of 6 will cause things to halt for a longer than intended span -- but GameDaysPassed is referenced in over 200 individual scripts (in Fallout New Vegas alone), so the probable impact of correcting its timing is pretty big.
Give Feedback
53 comments
1. The only way it is "more precise" is that it has the luxury of being able to update more regularly than every three seconds. Other than that, both JIP's and mine are basically atomic clocks.
2. Contrary to what is asserted, GameHours does not actually ever suffer from the same problem as GameDaysPassed.
3. The timing of this update is more than a little suspect.
4. If nothing else, this mod remains NVSE-independent.
2. Well... I didn't see anyone asserting that, so I can't really comment.
3. Suspect? Are you implying something bad...? If this mod had any influence over JIP, it would likely have been 'Oh hey, that's broken. I might as well take a look... oh wow, I can fix that pretty easily!' and then the bug was fixed.
4. Yeah, that's still good for people who don't want to/can't use NVSE for any reason.
After my tests, I'm almost certain that's precisely what it is doing: Correcting the issue at its core, which was most likely based on decimal place truncation as earlier speculated. This doesn't change what I asserted, though: Both the plugin and this mod provide the same precision, give or take the trivial, temporary aberration engendered by three-second updates.
> Well... I didn't see anyone asserting that, so I can't really comment.
It's in the JIP changelog.
> Are you implying something bad...?
It is just me grumbling. I toiled on this mod for many hours, fixed something modestly fundamental that'd been broken for almost seven years with nobody noticing, and within half a week, I'm informed that a "more precise" iteration has demoted mine to "valiant effort". Effectively I wasted that time giving someone else an idea. I think I deserve to grumble. ;p
2. Maybe JIP saw the same sort of bug COULD affect the 'gamehour' variable, but it hasn't actually been seen in practice? Then they just assumed that it was affected without checking if it actually was.
If I had to take a guess based on how I assume that variable would function, it ticks up to 23 and then goes back to 0, so the bug is never actually experienced since it doesn't get that high. Or something, I don't know, that was just guess; I don't actually know if the variable does that, but I think it does?
3. Yeah, I can imagine that would suck. Still, you have to admit that it's great to have the bug truly fixed in a way that doesn't take up loadorder space, huh?
It's not syncing, that's almost certain. There are tests I grew accustomed to performing which made this clear. It is straight up incrementing, but with precision as opposed to failing the way GameDaysPassed natively does.
> Maybe JIP saw the same sort of bug COULD affect the 'gamehour' variable, but it hasn't actually been seen in practice? Then they just assumed that it was affected without checking if it actually was.
After extensive testing -- I used my own mod, after all -- I can at the very least say that if GameHours ever inherently provides inaccurate numbers, they are on an order that is flatly unidentifiable under even extreme playtimes and timescales.
> Still, you have to admit that it's great to have the bug truly fixed in a way that doesn't take up loadorder space, huh?
Absolutely. But it wouldn't have hurt to be informed before I finished, to save me some time, or acknowledged after I was finished, to keep me from feeling like I got pickpocketed.
2. It wouldn't be the first time I've heard that GameHour isn't accurate sometimes. It may not freeze, but that doesn't mean it can't be wrong.
3. The issue was on jip's radar before this mod's release - I remember talking about it on the TTW discord when I saw jimnms's thread. We revisited the bug later, discussing the cause, and if he'd be willing to fix it. It was left up in the air, time passed, a release came. Nothing suspect about any of that.
Which implies that GameHour -- the variable which this mod re-syncs to every interval -- is being updated via GeckScript, as opposed to something more internal and precise. That would make it difficult to explain why GameHour is effectively incontrovertible in its precision.
I've been aware of this issue for a long time, and only started looking into it again when this thread was started https://forums.nexusmods.com/index.php?/topic/5793832-the-gamedayspassed-variable-is-messed-up-looking-for-a-way-to-fix-it/ back in july by jimnns.
It is a coincidence that you released your mod so close to the fix being done in jipln. As DoctaSax stated we had already been discussing it on TTW's discord and in private for a long time, along with many many other engine bugs, that some also have fixes for now.
Everyone wants to have a bug free game, and people also often have the same ideas for similar mods. This is nothing new and should be expected. No one is trying to steal your fire. Also as stated there are many people who are vehemently against using NVSE (for whatever reason) and will find your fix to their liking.
I would first like to commend you for taking the initiative and providing a working fix for a serious game issue.
I just wanted to clarify a few things.
The game time globals issue, and the related hardcore needs issue, were brought to my attention a couple of weeks ago, in discord conversations with such people as RoyBatty, DoctaSax and _Voidwalker. I then started investigating a way to fix it. That was before you released your mod. Since I'm not a mind reader, there is no way I could have possibly known that you were working on a similar fix at the same time. I'm sorry that you feel like you've been "pickpocketed".
JIP LN fixes this issue at the engine level, by actually replacing the internal subroutine, responsible for incrementing game time globals, with a custom-made one, which performs floating-point arithmetic with double-precision (as opposed to the game's single-precision). Moreover, it is optimized and uses a set of low-level instructions which are much faster (though, within the big picture, the difference in performance is rather negligable).
I'm curious how a different game start date affects the mod?
In our Fallout - New California (Project Brazil) mod, at the start of a game, we set the year to 2260.
Specifically, we have these settings:
set GameYear to 2260
set GameHour to 19
set GameDay to 23
set GameMonth to 10
set timescale to 8
It won't respond well. I'll sneak in a fix.
Before this, GDP wasn't stuck in my game, but updated really slowly. (Like jimnms told. I was using his fix before. Thanks for this.)
After this first test I can say: great fix! Thank you very much for this.
Then again, I've got over 80 GDP at Timescale 5.
In my long time savegame I'm in the year 2285 now, so this value of 330 can't be true. I noticed this bug when the GDP was at about 291 (yes, very late) and saw that it updated really slowly. Then I found jimnms fix and worked with it til today. I started your fix with the value of about 330.75 and since then it updates in real time again.
Normally the value had to be over 1000 now, as the game starts in the year 2281, but I'm happy that the GDP updates in real time again and the weekdays changes at midnight with this. Before, I had to quicksave and quickload right before midnight to have a normal weekday change.
Btw: I use the default timescale of 30.
The behavior of v1.1 differs, in that it now stores and adjusts for any discrepancy that exists the first time one plays with the mod installed. This was made the default behavior because of the fact that without some kind of external counter (god mode or another mod), anyone playing Hardcore is likely to die from any major adjustments to GameDaysPassed, including the one the mod originally made on initialization. And since surviving two-week modifications to the date is the default vanilla behavior for DLC transitions, there remained no real point in keeping GameDaysPassed the exact same value as the date.
If you aren't concerned about this, you can use v1.0 of the mod.
I slapped together a quick fix for personal use so I could continue my game without broken hardcore needs, but I decided to upload it because I figured other people might be interested in it even if it was just a quick and dirty fix and maybe someone could improve on it. My fix only works once the variable stops updating though, which means it does nothing when GameDaysPassed slows down. I never got around to making a more permanent solution, because well, as Red Green says, "This is only temporary, unless it works." For a permanent fix, I was thinking about just forcing GameDaysPassed to a high value from the beginning (above where it stops working normally) and let my script update it.
I just took a quick peak at your script. It looks like you're forcing GameDaysPassed to a value based on the GameHour/GameDay/GameMonth/GameYear variables and adjusting it to be equal to the number of days since the start date of the game. I didn't think of doing it that way. I set GameDaysPassed to the previous GameDaysPassed + ( GetSecondsPassed * TimeScale ) / 86400.
Both your script and the game are updating GameDaysPassed at the same time. This is what was bothering me when I tried to come up with a permanent solution. If the GameDaysPassed has not reached a high enough value where it slows down or stops, then it's possible another script can read the GameDaysPassed variable before the script fixes it. That's probably shouldn't cause any problems, but the hardcore needs may still accumulate faster than they should in the early game if the needs meter reads the GameDaysPassed variable before the script fixes it. Again, that's not really a huge problem, I'm just kind of OCD and it bothered me knowing that, so I was looking for a way to completely override the game's GameDaysPassed with a script. That's why I was thinking about setting the initial GameDaysPassed to a high value where it stops completely and letting the script take care of it. I don't know if having a high value for GameDaysPassed would cause issues and I didn't have time to test it either.
This is true, but since we are talking about a maximum three second lag between corrective tweaks, in addition to the fact that the internal GameDaysPassed modifies itself rather than recalculating from scratch, any difference we're talking about is going to be far too trivial to matter.
> That's probably shouldn't cause any problems, but the hardcore needs may still accumulate faster than they should in the early game if the needs meter reads the GameDaysPassed variable before the script fixes it.
Needs are going to accumulate a trifle faster solely because GameDaysPassed inherently lagged behind true game days passed on the whole. The point is that this was not intended behavior, and it certainly wasn't intended that needs and other factors reliant upon GameDaysPassed would potentially freeze outright. You seem to believe that the frame-by-frame GameDaysPassed updates and the tweaks enforced by this mod are causing the variable to go back and forth between increasingly disparate values. I think the important missing ingredient here is the fact that the internal mechanism only adds to whatever GameDaysPassed happens to be, whereas this mod forces specific values calculated from the reliable variables you earlier cited.
Note that the numbers were found residing in my rectum, and have been placed here for your viewing pleasure.
Say a normal GameDaysPassed variable of 3.123213123, and at this point, the game for some reason decides to add 0.125321. That would make the number 3.248534123, an imperceptible change to most any function.
This mod then kicks in, and changes the 3.248534123 to 25.10, and the game then ticks again, making the variable 25.225321. The next time the mod ticks, it would set that back to 25.10. The flip-flop is so tiny that it's inconsequential. And if you're early on in the game and GameDaysPassed is ticking normally, the mod will just keep setting it to about the same number.
I don't know if any of that was a reasonable scenario, but I think it works for an example.
In a nutshell, yes. I did an off-the-cuff bit of calculating myself. Assuming an internal worst-case inaccuracy of 100% (GameDaysPassed is frozen with no change) and a maximal Timescale of 30, the highest possible disparity a mod might encounter -- right before this mod kicks in on its three-second interval -- is 0.00104 days, or 90 non-realtime seconds. If Hardcore needs pick up on this, for example, one would have a small chance of briefly seeing dehydration lag by one point.
I do not know of any mod that takes it upon itself to advance time, but that is the criterion: 2.2 days. This can be adjusted for the sake of other mods if absolutely necessary, but the adjustment I have made in v1.1 is meant to adhere to the behavior of the vanilla game, inasmuch as avoiding game-breaking phenomena such as instant death, and that was what dictated my solution.
Do you mean 'invalid' as in the mod will ignore it and GameDaysPassed will not increment, or do you have some system to keep it correct while not killing you?
The latter. This is the vanilla behavior when it comes to DLC transitions. Anyway, the ultimate point of this mod isn't the maintenance of sync so much as the avoidance of script/respawn/etc. timing issues.
> Do you mean 'invalid' as in the mod will ignore it and GameDaysPassed will not increment, or do you have some system to keep it correct while not killing you?
The former. The mod doesn't ignore it but rather takes it into account for future calculations.
Not going to claim fixing one variable is going to fix everything weird that may occur with lower timescales -- there are, for example, cases where quests are set up to progress based on the passage of the time of day, and thus using a Timescale of 6 will cause things to halt for a longer than intended span -- but GameDaysPassed is referenced in over 200 individual scripts (in Fallout New Vegas alone), so the probable impact of correcting its timing is pretty big.