Time related issues (fire rate, jumping, smoothness, scheduler)

Cheo

Active member
Hello, here is a long video that demonstrates several issues related to Unity's and UCC's time scales :


To summarize :
-The fire rate is not correctly affected by UCC's low time scales.
-A very low Unity time scale can prevent a simple immobile jump form being performed correctly, and may affect gravity (needs more testing on that).
-Some animations are smoother in slow motion when using UCC's time scale rather then Unity's - at the moment I can only confirm that it is the case for jumping and hanging which have a little bit of jitter. Most things are okay with a low Unity time scale.
-Mouse controls are heavility affected by low time scales, especially with UCC's time scale.
-The Scheduler relying on Unity's time scale creates an annoying conflict when it comes to grenades (and probably other things), which are spawned from a character and inherit its UCC time scale. That leaves us with the impossibility of having a slow individual character throwing slow grenades with a longer countdown - I'd say this alone would justify adding an option to the Scheduler to make it follow a UCC character's time scale.

With all of this making a game like Max Payne with UCC3 is just not possible at the moment, so it really deserves some attention.
 
Thanks -
-The fire rate is not correctly affected by UCC's low time scales.
I'll fix this.

-Some animations are smoother in slow motion when using UCC's time scale rather then Unity's - at the moment I can only confirm that it is the case for jumping and hanging which have a little bit of jitter. Most things are okay with a low Unity time scale.
This should be a bug report for Unity as the controller doesn't have any control over the animation playback smoothness when setting Unity's timescale.

-A very low Unity time scale can prevent a simple immobile jump form being performed correctly, and may affect gravity (needs more testing on that).
This is the result of the jump force not providing enough lift to get past the ground stickiness. If you use a timescale that low you should also adjust the stickiness value.

-Mouse controls are heavility affected by low time scales, especially with UCC's time scale.
It looks like the inspector wasn't calling an event to update the timescale for the PlayerInput component.

-The Scheduler relying on Unity's time scale creates an annoying conflict when it comes to grenades (and probably other things), which are spawned from a character and inherit its UCC time scale. That leaves us with the impossibility of having a slow individual character throwing slow grenades with a longer countdown - I'd say this alone would justify adding an option to the Scheduler to make it follow a UCC character's time scale.
This is a new feature request since the scheduler is a static class. Right now I am not adding any new features but have made a note of this.
 
This should be a bug report for Unity as the controller doesn't have any control over the animation playback smoothness when setting Unity's timescale.
I made a beginner mistake sorry, I only changed the time scale and didn't think of the fixed delta time - when adding this after a time scale change :

C#:
Time.fixedDeltaTime = Time.timeScale * 0.02f;

The character now animates smoothly at all time. BUT it introduces a new physics issue, as a low fixed delta time values allows the player to jump at ridiculous heights !

I first made a few tests with empty characters playing the jump blend tree and transfer up animation, and their animations were smooth at low time scales with no fixed delta time correction, but apparently UCC characters need it to stay perfectly smooth during certain animations. So I don't know how to approach this, there's an issue whether we're using time scale only or with fixed delta time. Any thoughts on this ?

This is the result of the jump force not providing enough lift to get past the ground stickiness. If you use a timescale that low you should also adjust the stickiness value.
Adjusting fixed delta time solves this as well ! Just which stickiness value are you referring to ? When using time scale only, changing the Stick to ground distance value at runtime while the character is grounded may allow for the next jump to be correctly performed, but not the following ones, even if it is set to something very low like 0.001.
It looks like the inspector wasn't calling an event to update the timescale for the PlayerInput component.
Sorry but I'm not seeing any timescale in PlayerInput nor Unity Input - the video I recorded was in the demo scene using the old Input System by the way.
 
Allow me to bump this with an interesting piece of info - the fire rate issue did not exist back in V2, I just checked by using both the time orb and Time.timeScale. Maybe something whithin V3's item system is causing the issue ?

In any case please adress this issue when you can, I literally reported it last summer and we can't implement some basic bullet time because of it !
 
Just to confirm that I get them all, what issues are you currently having with the time scale? There was some back and forth and I'm not sure what is still an issue.

In the locomotion demo I noticed that the character jumps slightly higher with a fast timescale compared to normal and slow motion. With normal and slow motion the character jumps at the same height.
 
Apart from the animation smoothness, everything is still relevant. To give a few more details :
-A slow time orb affects mouse controls, but not a fast one, or barely.
-The fire rate is also affected by Unity's time scale.
-When using a low Unity time scale, the character can jump extremely high.
 
When I try to post my response to this thread I am getting a 500 error so I'll PM you and see if that works.
 
I'm posting this here because I can't reply in convo - the fire rate is still affected by the frame rate in UCC 3.1, the difference is still visible when going from 60 to 30. I can look at other assets like JU TPS 3 and see how they handle firing and fire rate, and perhaps even time scale.

There's one more thing I have to check about the time scale, I'll come back to it when I can.
 
Top