setting Inputsystem to fixedupdate and timescale to 0

Hi there. I wanted to set my input system to work on fixedupdate so it works better with physics. This works well until I pause and set FixedUpdate to 0. This stops input completely. So i can't unpause because i can't get the event OnPause, and clicks and hover in uitoolkit isn't working. I'm using two player input components, one for the character and one for the UI. Where am I going wrong?

 

If your input system uses FixedUpdate and you set Time.timeScale to 0, you won't get FixedUpdate anymore because time is stopped! Working as intended.

You can switch the InputSystem updateMode to DynamicUpdate while paused, or you can simply call InputSystem.Update() yourself when you need to process events.

https://docs.unity3d.com/Packages/c...ml#UnityEngine_InputSystem_InputSystem_Update

 

And how do you change the update mode in runtime??

 

A search through the docs usually yields an answer: https://docs.unity3d.com/Packages/c...tyEngine_InputSystem_InputSettings_updateMode

 

Hi guys,

Is this a unique thing to FixedUpdate? Is this rly intended?
The New Input System claims to be Framerate independent.
FixedUpdate is not related to Framerate,but a similar case could come up in normal Update, no ?
Where a frame 8 seconds long, i would expect the input to still "tick".

With this in mind, shouldnt the "Input" be not coupled with the TimeScale of FixedUpdate?

 

Where does it claim this?

The majority of Unity happens in the overarching player loop which is a frame-by-frame thing. The Input System is part of this loop.

Common misconception. Fixed Update is done by an accumulator,and it's internal timer is very much dependant on the passage of frames/time. This why you sometimes get multiple Fixed Update calls between two Update calls. It's not truly 'frame-rate independant' and is really only there for the physics engine.

 

Thank for the link.

The claim happens here https://unity.com/features/input-system under Key Features-> "Advanced options out of the box"

That means there is no Framerate Independancy ?

And while it could still be achived as suggested in here to switch to another of the 2 update Systems, in a scenario where both Update System are slow/ or 0, this would mean you couldnt read input.

Exotic Example:
In other words, if you would blind the Player with a targeted FrameRate of 0 so nothing renders and Freeze Time for Physics too, you would end up with a Deadend and the player couldnt even open the Menu to leave?
(If we were to use "Manual" Input Update calls, they would naturally go into the normal Update, so they couldnt help either.)

 

This is probably a case where 'frame-rate independant' means the result doesn't change at different frame rates. Eg, you won't get slower or faster inputs if the frame-rate is low or high.

However like nearly everything in Unity, it happens at some stage of a frame inside the player loop, as evidenced by the bindings. Eg, we make things like movement 'frame-rate independant' by multiple values by

Time.deltaTime

, but ultimately things are still happening on a frame-by-frame basis.

Thing is you can still have input updated via the regular Update timings, and read it in FixedUpdate, though this should only be used to poll values, imo. But the best practice is still always "Read Input in Update, and act upon those inputs in FixedUpdate" where physics is concerned.

And you can have callback style inputs read during Update that impart physics, of which just won't take effect until the next FixedUpdate call.

 

I consider this as a bug since the Input System's behavior is different in

Update

and

FixedUpdate

. This is true both polling it (naturally) and subscribing to the

performed

event.
Because of this I have submitted a bug report. I will post the result when I hear back from Unity.

 

Well, what can I say, it doesn't really build up confidence in Unity when your bug report is sitting there in "Open" status untouched by anyone since July 28. IN-49458 if anyone interested. Anyway.

 

FYI, I got an answer, the guys at QA explained to me how

FixedUpdate

works and how the InputSystem blindly tight to it without thinking about the case of game pause using the

timeScale

set to zero method. I won't paste the answer here because it isn't worth it, classic misunderstanding or thinking the user's are too dumb for their own good. So I sent a follow up question specifically asking about how this whole fixed update input processing is useful if people shut themselves out from input processing the moment application pause is there. I'll post the answer when it comes in.

Until then, I think the official stance on this is not to use

FixedUpdate

as input processing if you also want your application paused by

timeScale

.

 

Sorry but that's a pretty naïve response.

I do wish Unity had used the term "PhysicsUpdate" instead of "FixedUpdate", but it is a legacy term dating all the way back to Unity 1.0.

You're welcome to poll the input system manually if needed, and it'd be quite simple to do so with a single script.

ie:
void Update(){
if(Time.timeScale == 0)
InputSystem.Update();
}

The alternative would be to have similar script that switches the input system's polling mode on game-pause.