Is 0.4 sec the maximum value for deltaTime?

For such a thing why do you rely on animations still…
The animation notifications are not for this purpose. In my view, Your approach is totally wrong. But its hard to tell if we don’t know what do you want exactly?

If you want to check if something “will” overlap your sword then check it in the first frame. But it only works if your animation is very fast.

(You were talking about fast attacks and i don’t know what do you mean by that)

Please take a look at this:
https://youtu.be/ny7mLmslkCg

That is the kind of game I want to make.

As you can see a slash attack might be as short as 4 frames long (when running at 30 fps I believe)

So what I want is to make collision detection that responds when the sword actually hits the enemy! (like when someone records the game as a video and then plays that back in slowmo)

But I still want it to not “break” if the stupid antivirus program starts hogging or the player drags the window when an enemy is about to attack (as an exploit / cheat)

If you don’t rely on the animations you don’t have to worry about the anti-virus programs because your enemy will not start attacking faster. The whole game gets slower.

About slowmo guys: I think at this attack speed they can’t move or do anything against it so what would they do?

I hope it helps

Oh, and I have figured out that you can set global dilation so that the players can practice on the game in slowmo, if they want to.

No the animations are not part of the physics simulation. You can just attach physics attachments to bones.

Hehe, if you fight 1 you are supposed to be able to go nuts an bully it with spectacular combos, but when fighting several at the same time it will be more like this;
https://youtu.be/0rkd5-n1N-c

And what will they do?

Some will have invincible/berserk attacks where they don’t take any damage but can deal massive damage

The 0.4 seconds is hardcoded into the engine’s world tick method. It is basically intended to prevent the kind of problems you have if the realtime tick is extremely long for any reason - it clamps it to be no more than 0.4, though obviously this is still a long tick.

The core point though is that this only happens when for some reason the real world time between successive frames is that long - ie. huge system lag. If it was instead clamped to 1/30, then that would mean that any time the system wasn’t able to maintain 30 fps, your game would go into slow motion. Arguably this is in general worse than having a very long tick, hence the engine clamping at a fairly high value.

Your main concern should not be what happens when you get a long tick, but how to avoid it happening. That said, if this happens when dragging a windowed game even in standalone/shipping, I’d say that might be a bug. Ideally the game would continue stepping in that scenario, rather than halt and deal with a single huge tick after dragging is finished.

If you really need to change it, you can just modify the line in UWorld::Tick and build the engine source. There is also a configurable property on UGameEngine called MaxDeltaTime which I think would do the same thing, however it appears not to be used when running within the editor.

The behavior I would want as a Gamer playing an intense action game, is that It should go into slow motion if anything unexpected starts happening, (as Windows is not a realtime OS).

Clamping to 1/30 would mean that if I know that some code breaks if something turns more than 179 degrees between ticks, then I would know how crazy/intense I can make my animations.

I already find that getting exactly the same experience when playing at 30 and 200+ fps rather challenging!

I guess another problem with the effect of slow motion is that for networked games it would lead to the client getting out of sync with the server. That said, I agree for non-networked games a bit more control would be good - maybe setting a threshold which when crossed causes the game to be paused so a warning message can be shown.

I like that idea!

Is it possible to add a callback somewhere that setts pause state to be entered before 0.4 is passed to the tick of everything from game logic, to physics, to animations?

It would be pretty easy to do if you’re happy rebuilding the engine from source. Just override UWorld::Tick I guess.
Whether you can hook in at that level without a source build, or specify your own UWorld class, I don’t know. I think you can specify your own UEngine derived class, so it might be doable.

And they really need to change Answer Hub settings to stop marked answers from being reset any time someone adds a comment!

For anyone looking for this in 4.27:
image