• News

• Industries

• Learning & Support

• Community

• Marketplace

# Let's see how smart you folk are...

So I have a day night cycle on my Skybox that already calculates the time of day in Military time (0:00 - 24:00) However that variable is a float and is 0 - 2400 rather than actually being in a usable time format. If i take that 2400 and divide it by 100 I can successfully get the hour of the day (24:00 for example) However, I suck horribly with math and algorithms, so I was hoping one of you geniuses out there could give me a hand coming up with an algorithm or equation that could take that “24” and break it down to get the minutes and seconds of the “Length of Day Cycle” variable (Currently set to 30 Minutes for the entire day night cycle) However. I want it to be able to get whatever value is set in the Length of Day variable (Whether its 30–default-- or 12 for a different persons preference and so on…) and still return accurate information. I’m sorry if this isn’t exactly clear. I’ll break it down a little more, if you get it you dont have to read the next paragraph lol

My Time Values come from Delta Seconds on an Event Tick Node
If I have to leave the Length of Day at 30 Minutes, that’s fine too I just want something to calculate minutes and seconds accurately.

Basically I have a Variable Called “Time of Day” That variable is a float and ranges between 0.0 and 2400.0.
Then I have another Variable called “Length of Day” (which is in real life minutes) That value by default is set to 30(minutes)
What I am shooting for is, Divide the Time of Day variable by 100 to get the value in a more realistic format (Example, 2400/100 = 24)
Then I want some magic Algorithm that can take the Variable Length of Day and equate the variables at play to determine the Minutes and Seconds according to the “Time of Day” float variable.

As you can see, this isn’t exactly easy (or at least I’m making it more difficult than I have to) Please help!! My brain hurts.

There are 1440 minutes in a day, or 86,400 seconds.

I would move away from storing time as a 24 hour float, because numerical values are designated 0 - 100, and time is designated as 0 - 59. When you say something like 1850, you don’t really mean 18.5 hours, you mean 18 hours, 50 minutes, which is something more like 18.8 or something.

Start by calculating your multiplier on Event begin play. This will be your length of day in real world minutes, times 60 to get the seconds. 86400 divided by that number will give you your multiplication ratio. On a 30 minute ‘day’, your multiplication ratio would be 86400 / (30x60), which is 48. This makes sense, because if your day is 30 minutes long, and there are 24 hours in a day, each in game day will be 48x faster, or 1/48th as long as one real world day.

Once that’s done, use Event tick to count the seconds, and increment the variable by delta time each frame (modified by your multiplier for the speed of your day). Have a branch at the end of the code flow that takes 86400 away from seconds if seconds is equal to or greater than 86400, effectively setting it back to almost 0. The reason we don’t just set it to 0 is so that we account for the fraction of a second that may have passed between ticks. It’s pretty negligible either way, but easy to account for.

Finally. Every tick, we can also take our total seconds and divide them by 3600 to get the current hour. We then Floor that (Round down), and that is our current hour integer. We then use the modulus function to find the remaining seconds left over and divide that by 60 to get minutes. The remainder of that operation will be the seconds we have left over. We can also map Current Seconds any way we want using the map range clamped. In this scenario I’ve mapped it to a range of 0 - 1 that we could then use to drive any lerp alpha functions we might need, like a progress bar or anything else you can think of.

Let me know if anything’s unclear, but I really think you’ll make it easier storing the variables as seconds rather than hours. Anything smaller than seconds can actually be divided by 10, unlike hours and minutes which are more difficult to work with.

Cheers

VaSSiLi is right about moving away from floats. (And you are using it as an integer, anyway ).

One thing, though. Use Timer, not Tick, to count the seconds. Spamming Tick like this can be very expensive, and your day/night cycle would depend on the framerate, and you would have a cycle that would take twice as long if your PC/console could only work at 30 FPS. Or half as long if someone had a 120Hz monitor.

Also, consider looking into the existing time nodes, it will save you from overdoing the blueprint wire gymnastics:

This prints: 13:46:40h

Awesome, thanks for the advice guys I really appreciate the notes. I’ll have to try and apply these settings and see if I can get the result I am looking for.

Would it be smart to put this setup in my Level Blueprint? Or should I store these variables on my Character Blueprint? Game State… lol Not sure where I would store this time of day setup at. (this is a multiplayer game so it needs to be replicated and I’m assuming, controlled by the server)

Kleiner Baer has a really good complex day night cycle. this was the first large BP i ever built and it took me 6-7 hours to build back in 2015, iv’e since modded it for seasons, weather, dynamic light levels/color per day and im running on timers.
you can also check out the community ocean project, that has a nice cycle in it too.

i do suggest doing Kleiner Baer’s tutorial, it will teach you heaps about not just blueprints but the algorithms for time.

Awesome thanks!

Game state makes sense to me. Especially for multiplayer. Game state is replicated to all players by default.