Download

How to display time via UMG (countdown) correctly?

I was trying to convert seconds into Hours/Minutes/Seconds to display via UMG. I almost have it working except for the darn 1 hr and 60 mins part… I want it to display it like a regular clock would. 00 :: 59mins :: 59 seconds… instead of 1::60:0

4916a41d4260eaeb9f6c6d10848444f4b2c995a4.jpeg
a72c0ba99b067492b6efd6a5f90926ecba83e75c.jpeg
00a2089b07e2972ffa9eb6c0d7950073888aeb61.jpeg
d937df788baa7d4b5e91c3bb0c1065bd66c752c2.jpeg

Anyone have any tips?

You definitely don’t want to accumulate time like that. You’re assuming the timer callback calls back exactly every 1 second and that there’s never any error, but this is not true, your timer will accumulate error over time and by the end of the match you’ll be off several seconds. You should record Start Time when the game starts, and every time you display the time, simply take Current Time - Start Time to determine how long the game has been running. Once it has met or surpassed Match Duration, you know the match is over.

For formatting, use the googles, http://stackoverflow.com/questions/3856293/how-to-convert-seconds-to-time-format

Alright, so I have very little idea what you mean when it comes to how it could be generating errors (noob programmer, which is why I am in Blueprints). But, you’re the dev, so let’s take your word for it;) It’s accumulating errors every second or tick?

Then there’s the running time…But then don’t I have it running when the game starts with Event Begin Play?

Then there’s the formatting… I did Google…and that’s why I have hours/minutes/seconds formatted…but it’s obviously wrong, which is why I need the help trying to figure out where I went wrong.

At the end of the day. I want to be able to set a time. And have it countdown from there. Like 24 hours…and have it displayed in UMG. And then be able to call events at certain times

The issue with your time formatting is that you are not reusing your divisions: you should first divide the number of seconds by 60 and floor it to get the minutes. Then you subtract 60minutes to your initial value to get the remaining seconds.
You then do the same for hours: minutes/60, floor to get hours, then minutes - 60
hours to get the final number of minutes.
For instance, if your time is 4567 seconds: minutes = floor(4567/60) = 76, and seconds = 4567 - 7660 = 7.
hours = floor(76/60) = 1, and minutes = 76 - 1
60 = 16.
The time is 1:16:07.
(You can also go the other way around: divide by 3600 to get hours, subtract to get remaining minutes, divide by 60 to get actual minutes, and subtract to get seconds. The first way may be “easier” in that you don’t have to multiply 606024*etc. if you go higher than hours/days.)

As for the error, I think it accumulates every tick, because floating point calculations mean you always get some error.
By always subtracting the current time from the start time, the error will stay the same, and will be insignificant.

Took at a look at the timer manager, looks like our timers are smarter than I thought. They use a running absolute expire time that they push forward the (number of calls this frame) * the tick rate. So you’re not going to get the kind of accumulated error I’m talking about. Floating point error isn’t really the issue. Not all timer systems do what ours does, some use a much more simplified approach. They may just have a time in the future, and when that time becomes the past, they execute the callback. Then they set a new time that’s Rate + current time in the future, for the next call, losing time because they don’t account for the overshoot. Point is, not all callback systems keep perfect time, so never hurts to plan accordingly.

It took a little bit to get what you were saying into my blueprint (it works!), but not sure if it’s optimized as best as possible and I am not sitting around for 24 hours staring at my screen (I did 5 minutes instead to check for hickups). Regardless, thanks a lot for the help!

And here’s the easy Time Conversion function for others: