Unable to retrieve value of manually Queued stick event

Unity Engine
,
1

Hello,
I have difficulties to understand how the queing of event of the input system works.

For the context we are trying to implement a way to record inputs then replay them. Our system needs to be replayed on the exact same fixed frame it was first played. We were not able to obtain this with the InputSystem record/replay system so we are looking at ways to do it ouserlves.
But we encountered this problem:
We are able to send input events and trigger the callback but the end value we receive is not the one we sent, and it does not seem to fit calculation we could do with the deadzone (which is the default 0.125 <> 0.925).
There is also some (0, 0) values being sent that I did not queued.

Is there something I don’t understand, some hidden preprocessor being applied?

Here is the Log and the project used to produce it, it uses a default playerAction built via the playerInput and the callback is triggered with unity event by the playerInput. I disabled the gamepad and created a virtual one to make sure there is no parasite values.

Unity version: 2021.3.19f1
InputSystem version: 1.5.1

8974315--1233943--upload_2023-4-26_12-7-15.png
8974315--1233943--upload_2023-4-26_12-7-15.png478×600 59.3 KB

8974315–1233958–StickInputQueueTest.zip (54.7 KB)

2

The values do seem consistent with that. Note that deadzoning renormlizes in the given range.

The constant canceling in there I find surprising. Not sure what that is about.

3

I tried doing the math of the deadzone renormalizing and I obtain:
(0.5 - 0.125) * (0.925 - 0.125) = 0.3
which is not what I see on the logs :confused:
Or maybe I make mistake in computing the projection into the deadzone

4

My bad
(0.5 - 0.125) / (0.925 - 0.125) = 0.46875
and it match, the only mystery left is the 0 being sent

5

Yeah, that part I’m also puzzled about. Would probably set a breakpoint on the action callback when it’s canceled and see what’s going on. And check the event trace in the input debugger where there’s actual events in there that in fact do reset the control.

6

Maybe it’s the mouse moving that force a scheme change, I’ll have a look at it today

7

Ok, that’s what was happening, using the mouse (or simply hitting the desk too strong making the mouse move) was triggering the control scheme change, canceling all the in progress inputs

8

Ah I see :slight_smile: