steady increasing number (each second) ?

Development Programming & Scripting C++
1

Hey,

'm trying to increase a int32 variable each second a actor is inside a USphereComponent(overlap) I’ve tried to use the tick and its deltaSeconds, but this isn’t steady actually.

Answerhub qestion: Steady increasing number (each second)? - Programming & Scripting - Epic Developer Community Forums
(posting , due to low activity in the answerhub)

anyone has another solution?

2

Have you considered using timers?


GetWorldTimeManager().SetTimer()
3

You can just use current time in seconds.
double IncreasingValue = FPlatfromTime::Seconds();

Round it to an integer if you need to, better to int64, because it can be a big value.

4

this works perfectly for me :slight_smile:

using the platform time would be also an idea, yeah :>

5

When you say that tick isn’t steady what exactly do you mean? What is tick doing (or not doing) that you think is wrong?

6

Id guess because tick is not guaranteed to get called exactly n times per second. Adding deltaTime every tick would lead to lots of rounding errors.

7

Well, delta time is the time elapsed between frames, which probably does vary depending on the frame (I’m new to the engine so not sure), but even so that doesn’t actually stop you from making a fairly reliable timer using it.

Floating point addition does generate rounding errors, but over a relatively short period of time (such as most game uses) it shouldn’t be much of a practical problem.

8

even if it’s minimal, steady.
especially when something happens in the game, and the deltaSeconds suddenly increases.

I’ve used GetWorldTimeManager().SetTimer() and it works perfectly

9

Now the question is if GetWorldTimeManager().SetTimer() uses internally DeltaSeconds to launch your callback, than its exactly the same as the tick solution.

10

I’m glad to hear that the timer manager is working for you. I just wanted to make sure I understood why you didn’t feel that Tick was doing what you wanted.

While DeltaTime in the tick will vary depending on the work you’re doing per frame this can also impact the timer manager. Most of the work being done by the timer manager is actually inside of a Tick function. If there was some underlying problem with the way the engine ticks it would affect the results you see in the timer manager. It isn’t doing anything you couldn’t do inside your objects Tick function but it’s usually more efficient to use the timer manager. The timer manager takes care of issues like long frames (DeltaTime > period of your timer) and updates looping timers to account for the current frame time in the next period. If you’re curious about how it works or need specific behaviour for those cases I’d suggest looking at the implementation in TimerManager.cpp. It’s fairly straightforward and you can always ask more questions .

11

thanks :slight_smile:

yeah, I think I’ll look up for some interesting elements of ue4 in the src code anyway.
But it’s my second week with ue4, so I’m still in the “learning phase” :>
i’ll take things slowly :stuck_out_tongue:

12

IF branch gates too slow for reliable custom timers

I think this is what he was talking about. In theory, this should convert the float to an int, and then perform int%10 and only return true if the result is 0, i.e. only if the result equals 10. This should only trigger the IF branch once every ten seconds, but for some reason you can see the milliseconds leaking through and messes up the rest of the timers.

13

Hi,

Unless I’m misunderstanding what you are attempting, the ‘if’ isn’t the problem (as such).

Rather than triggering once every 10 seconds, it is setup to trigger for the full second, every 10 seconds.

i.e: every 10 seconds, you will get 1 second of it being triggered every frame for that second, then nothing for another 9, then trigger every frame for one second, etc.

Or to put it another way:

If you envision the following frames:

Starting from Get Real Time Seconds (GRTS): 9.5:

GRTS: 9.5 -> Floor 9.5 -> 9 -> 9 % 10 -> 9 -> Branch False
GRTS: 9.7 -> Floor 9.7 -> 9 -> 9 % 10 -> 9 -> Branch False
GRTS: 9.9 -> Floor 9.9 -> 9 -> 9 % 10 -> 9 -> Branch False
GRTS: 10.1 -> Floor 10.1 -> 10 -> 10 % 10 -> 0 -> Branch True

So far so good… But then from then until >= 11.0

GRTS: 10.3 -> Floor 10.3 -> 10 -> 10 % 10 -> 0 -> Branch True
GRTS: 10.5 -> Floor 10.5 -> 10 -> 10 % 10 -> 0 -> Branch True
GRTS: 10.7 -> Floor 10.7 -> 10 -> 10 % 10 -> 0 -> Branch True
GRTS: 10.9 -> Floor 10.9 -> 10 -> 10 % 10 -> 0 -> Branch True

GRTS: 11.1 -> Floor 11.1 -> 11 -> 10 % 10 -> 1 -> Branch False

And now we’re back to expected.

I’m not entirely sure what you’re attempting to do overall, but just wanted to show that it’s not the if being flakey (well I don’t think so, I could be missing the point though :slight_smile: )

  • Mark