Different behaviour of time dilation in 4.14

First of all there already is a [report][1] about this issue. However it has been closed and the problem was not really addressed so here is another try.

It seems time dilation behaviour has changed with 4.14 in several regards.

  • A Delay Node will now correlate with GlobalTimeDilation only, whereas CustomTimeDilation was factored in in 4.13.

The following example shows a simple SlowMo function inside a Pawn Blueprint. GlobalTimeDilation is set to 0.3f. CustomTimeDilation is set to the invert value so that SlowMo affects everything but the Pawn. After a Delay the effect is reverted.

In 4.13 the Delay would complete after 10sec as expected. Conveniently we could simply hard code the value. Since GlobalTimeDilation was canceled out so we could just use a realtime value. In 4.14 now the delay takes 33.3sec to complete and we have to multiply CustomTimeDilation before each and every Delay to achieve the expected behaviour.

  • GetWorldDeltaSeconds function also does not take Custom Time Dilation into account anymore. We had to rewire several Blueprints cause you have to use the DeltaSeconds from out of the Tick now or calculate them yourself.

Both of these points might be by design but a search for “Dilation” and “Delay” did not yield any results in 4.14 changelog nor in the 4.9 changelog mentioned by TJ Ballard in the [other report][1]. Either way I would expect a Delay to correspond to the context it is implemented in.

It would be nice if anyone could take a look at this issue again and confirm whether this is by design and if we have to expect another change to this.

Hi Max,

I’m sorry if my answer in the other post wasn’t clear enough. I pointed the user to the 4.9 Release Notes. I should have quoted specifically this part of them:

An Actor’s Custom Time Dilation does not apply to the Tick Interval. The frequency with which the tick is dispatched remains constant regardless of whether the individual Actor has its own Time Dilation, that Time Dilation is only applied to the DeltaTime passed in to the tick function.

The Delay node is considered a Tick function and Custom Time Dilation no long applies to it. You will need to add in the math like you described in order to make this work as before.

Let me know if you have any other questions.

Cheers,

TJ

Hi TJ,

Thanks for the response.

I assume you meant the 4.9 Release Notes because thats were your quote is from. The behaviour definitely changed during the migration from 4.13 to 4.14 though and I found nothing comparable in the 4.14 Release Notes

Also I have a little trouble connecting your explanation to the actual change.
Does it mean that the Delay is delayed by a certain amount of Tick calls rather than a sum of DeltaSeconds?

The current change implies that WorldDeltaSeconds are used now instead of an Actor’s DeltaSeconds.

Sorry about that, yeah I meant the 4.9 Release Notes. I’ll edit my answer for clarification if someone else has this issue.

So after further testing I think I pinned down what is going on. The 4.9 change above is correct. Testing in 4.12 and 4.13 confirmed that the actual delay time with your setup is not exactly 3 seconds but something like 3.3 seconds (this can vary).

What you are now seeing in 4.14 is closer to 9.9 seconds with the same setup. I believe this is caused by a change that is logged in the 4.14 Release Notes.

The “Delta Seconds” passed to Tick functions when using a “Tick Interval” will now represent the amount of world time that has passed since the last tick of the function.

Previously the delta time value of a Tick Interval tick function was the same as if the function had no tick interval.

This means tick functions that were relying on getting just the frame time need to get the delta time from the world rather than using the value passed into the Tick function.

I’m sorry this has caused issues in your project but I’m sure the developers made this change as an overall improvement and to future proof Delta Seconds/Tick functions.

Let me know if this clarifies things a bit.

Okay yeah I get it now. It makes sense in that way. I still personally feel a delay should be bound to the actor it is implemented in so you can depend on it being in sync with animations and other actor time driven stuff. Also you can not dilate a running delay by custom dilation anymore like you could before, even when recalculating the delay time. But I understand that this is about more than just the delay node.

Anyway good to know that this is not just a bug that crept in. Lots of thanks for your time.

Have a good one!
Max