Talk:Day Cycle

This talk page is for discussing Day Cycle.
Sign and date your posts by typing four tildes (~~~~). Put new text below old text.	Be polite. Assume good faith. Don't delete discussions.

Trivia

Originally put into the article by a one-day drive-by editor 18 months ago, I corrected some incorrect assumptions. I did the timing measurements again because they didn't match an earlier article edit, and thought something might have changed in v1.4. What I got was in between, so who knows? Without the point the other editor was trying to make, I'm not sure if anyone cares. But I've used the game-hour and game-increment timings to my benefit in playing, squeezing out the last possible thing before 2 A.M. So I like to know accurately, and thought maybe someone else would too. Butterbur (talk) 23:03, 4 December 2019 (UTC)

Oh. One useful way to use the small-size measures is to calculate times for buffs. The wiki supplies buff times in real time, but I like to know what that is in game time too. Butterbur (talk) 23:13, 4 December 2019 (UTC)

The fundamental game-based conversion rate is one game-time hour is 42 real-time seconds, because the game sets a ten-minute interval to be 7000 milliseconds. Relevant code:

• In Game1.cs public const int realMilliSecondsPerGameTenMinutes = 7000;. A nice well-labeled constant that launched me on this trail, except it's really a red herring: this constant is never implemented anywhere. Instead, the same 7000 number is hard-wired in a few different places.
• Game1::UpdateGameClock(), in particular the line if gameTimeInterval > 7000 + currentLocation.getExtraMillisecondsPerInGameMinuteForThisLocation() that triggers performTenMinuteClockUpdate(). Where getExtra... is 0 by default (but hints at complications, see below).
• Buff::Buff has millisecondsDuration = minutesDuration / 10 * 7000;. At one point I thought, aha, this is justification to document buff times in game-time minutes, because that's the "true" input data (at least for cooked items read from ObjectInformation.xnb). But nothing is ever so simple....

Doing stopwatch tests of true real-time versus game-time always shows longer values, 43.5-ish seconds. I suspect the difference is essentially non-game-related (background) processes using CPU cycles. So the game's CPU cycles take exactly 42 real-time seconds to process, but our multi-tasking, overworked platforms have to give some CPU cycles to everything else. In which case, the true real-time rate is probably platform-dependent as well as inherently highly variable.

As far as buff duration conversions, 42 seconds is the correct value, not 43+ seconds -- because it's the game internally comparing its "expected" elapsed real time with game time. For example, Bean Hotpot has duration of 7mins. Which is a game-time duration of 10 hours -- and that's exactly what I get in game. (Meanwhile, the actual elapsed real time as measured with a stopwatch was more than 7 minutes).

Except it's not a universal 42 second conversion rate. That mention above of currentLocation.getExtraMillisecondsPerInGameMinuteForThisLocation() is a mega-complication. The only time that "extra" value ever gets set is in Skull Cavern (aka MineShaft.cs) where it gets set to 2000 (except not if multiplayer and not if getMineArea()==121, e.g., a Prehistoric Floor). So in those cases, a ten-minute interval is 7+2=9 real seconds; one hour is 54 seconds. Yes, I stood drinking coffee in Skull Cavern for a few hours: hours really do pass more slowly, and buffs really do expire sooner (vs game time).

As for this article, I don't know what to do. I think the wiki needs a central place documenting a bunch of time-related information (e.g., ten-minute interval is a fundamental time unit, in particular for processing machines, plus buff durations, etc.) But is "Day Cycle" the best place for that information? Nebulous Maestress (talk) 19:26, 5 April 2020 (UTC)

Yeah, code again. Sorry. I timed things as stated in my comments against my wall clock (not computer), and repeatedly got consistent results. I don't know anything about why the code does such weird things with timing in this game, but if it's anything like fishing, selection of what fish is caught each time, and selection of fish quality, well, the code can be a mess. I can't say this is another mess, but if you're seeing code that says something straightforward, prove it against a real clock. Then maybe you'll get better guidance about how much code to read. Butterbur (talk) 05:44, 6 April 2020 (UTC)

So here's another question: Why is the Bean Hotpot buff time given as 7 ["game's real-time"] minutes? Because "real time" is not really real time. If the buff is really 10 in-game hours, why not just call it that? (But that's not right either, is it?) I assume that time will run according to the player's location, so it won't matter if something else is going on somewhere else. (Or what's the alternative?) And processing machines don't shift location - not while they're processing, that is. So time measured for a machine is time as it exists at that location? It better be! I vote for doing nothing with the article descriptions until the game runs time in an explainable manner. It's best not to try to explain our way around a lot of bugs, misdirections, or arcane behavior. Butterbur (talk) 20:56, 6 April 2020 (UTC)

Oh, and btw Nebulous, if your stopwatch is timing at 43.5 seconds, just like my wall clock, what's your game platform? Mine is Windows 10 PC through Steam. If there is some "extra" 1.5 seconds created around internal processing (on which machine or machines?), why is it so consistent, even on just one machine? Anyone's platform could be involved in interleaved processes at any time - OSes do that. If it's the server, why are my times consistent? And is Steam always operating at the same efficiency? I doubt it. Consistency argues for another explanation. Butterbur (talk) 21:05, 6 April 2020 (UTC)

I'm playing on an iPad. I did laptimes on invididual game hours and got values of 43.8, 43.7, 43.9, 43.8 -- where the variability is as likely to be my response time as anything else. I only did enough tests to be confident that it was more than 42 and in the same ballpark as what had been reported here. Also, I didn't happen to get any news alerts or other obvious interference during the tests -- I know my frame rate goes haywire during those types of events (wreaks havoc on fishing minigames), but I don't have the patience to try to catch one of them with a timer. Nebulous Maestress (talk) 23:34, 6 April 2020 (UTC)

In Game1.cs public const int realMilliSecondsPerGameTenMinutes = 7000;. A nice well-labeled constant that launched me on this trail, except it's really a red herring: this constant is never implemented anywhere. Instead, the same 7000 number is hard-wired in a few different places.

This is a result of decompiling. In the source code on ConcernedApe's machine, this constant is (probably) used throughout the method, however after decompiling the code the use of the constant is lost. This is incredibly frustrating when digging into the code... BlaDe (talk) 01:32, 7 April 2020 (UTC)

I have to recommend that this is all a tilting at windmills. The truth is that timing and time measurement is all mixed in several incompatible ways, so that all remains obscure whatever you do. And none of it has any direct connection with real time. Besides, the game itself does not reveal any connections to real time, so the obscurity is all hidden anyway. Of what possible use can it be to anyone playing? There is no way to track game progress except the game-time clock, and the very relation of buffs to that is variable depending on conditions you cannot see. All the best to you, but I can't see the point. Butterbur (talk) 04:33, 7 April 2020 (UTC)

For clarification, my primary intent here was to explain/justify that I'm using 42 seconds/game-hour elsewhere on the site (e.g., Buffs#Buff Duration), while acknowledging that a different value is used on this article. Beyond that, my comments were meant as feedback and/or answers to questions directed at me -- I'm not arguing for any type of action. Nebulous Maestress (talk) 17:44, 7 April 2020 (UTC)

Please pardon any misunderstanding I have had. I had thought you were pursuing a way to reconcile the timings by looking into the code, and I just thought it would prove fruitless. I entirely agree that things are best left untouched. I am responsible for the 43.5-second approximation, and I see that the code itself is not consistent. Both figures are in the ballpark, and if wiki readers get the idea that they might run into variances, that at least is true. Thanks for pursuing this so far. Your digging has certainly brought to light the complexities. Butterbur (talk) 05:02, 8 April 2020 (UTC)