No Input Devices Recognized in Build (2020.2.0b8)

Unity Engine
,
1

As far as I can tell — which is a log full of null reference exceptions — no Input Devices are recognized when I make a build. (At the very least, the Mouse is not recognized. I know that for certain).

Some notes about my Project / Build:

  • I’ve tried this on both 2020.2.0b8 and 2020.2.0b6 and the error persists.
  • I’ve tried both Version 1.1.0-preview.2 and Version 1.0.0 (Verified) of the Input System Package, and the error persists in both.
  • I have tried both 32-bit and 64-bit architectures, the error persists on both.
  • I have already checked that I have selected “Input System Package (New)” as my Active Input Handling solution in Player Settings.
  • All Input Devices are recognized in the Input Debugger in the Editor. (Input also works fine in-Editor).

Here is the error:
Error

NullReferenceException: Object reference not set to an instance of an object
  at FDS.LD.Inputs.ReceivesPlayerInput.FDS.LD.Updating.IUpdateVariable.OnUpdate () [0x00030] in C:\Users\samue\OneDrive\Desktop\MONO Projects\GameJam Game 2 (Main)\Assets\Scripts\__Final\Input\ReceivesPlayerInput.cs:36
  at FDS.LD.Updating.UpdateManager.Update () [0x00098] in C:\Users\samue\OneDrive\Desktop\MONO Projects\GameJam Game 2 (Main)\Assets\Scripts\__Final\_Update Management\UpdateManager.cs:402

(Filename: C:/Users/samue/OneDrive/Desktop/MONO Projects/GameJam Game 2 (Main)/Assets/Scripts/__Final/Input/ReceivesPlayerInput.cs Line: 36)

Here is line 36 that the error is pointing to:

Debug.Log(Mouse.current.position.ReadValue());

To make sure that Mouse.current is null, I printed out this on line 35 directly before the above Debug.Log:

Debug.Log(Mouse.current == null);

It returned True.

Has anybody been experiencing similar problems as me in builds?
I’d really like to have this fixed — but hey, at least the editor seems to work fine. :frowning:

2

I’m having the same problem. After updating to 2020.2.0b8 my devices no longer show up in the debug window, and no input is registered.

I have done some tests with 2021.1.0a2 and there it is the same problem (also in new projects)

In my case it doesnt even work in the editor.

3

Your description sounds very similar to a problem I experienced a while back when I attempted to update to / past version 2020.2.0b4.

Check out this thread:
https://discussions.unity.com/t/810672
It might help you solve the problem!

TL;DR: Check the Player Settings and make sure that Active Input Handling didn’t get switched. It seems like updating past a certain version causes it to switch back to Unity’s default Input System.

1 Like
4

There’s a regression in the 2020.2 beta that resets the player setting as @NotaNaN mentions. It’s being looked into.

////EDIT: There’s a fix making its way through the pipes.

3 Likes
5

Yes, that was it! Thanks alot!!!

I hope your problem gets solved too, as it seems to be a different cause :frowning:

1 Like
6

I just posted in another thread that I noticed the player setting resetting when I updated my project to 2020.2.0b8… Now I have the additional problem of not being able to change that setting, because any attempt to do so only results in this error being written to the console:

Cancelling Display Dialog : This should not be called when a View's DrawRect Method is in progress

Input System is version 1.0.

7

Only thing I can recommened is upgrading to the latest preview version of the Input System Package and seeing if that fixes the problem for you. :frowning:

Hopefully @Rene-Damm will get back to us on these issues and help us troubleshoot. :sweat_smile:

8

I now tried the latest InputSystem preview (1.1.0-preview.2). Same problem…

9

Yup, same thing. There were some changes to player settings made in the 2020.2 beta that led to several regressions impacting the input system package. That error message is one, “Active Input Handling” losing state is another. A fix is being rolled out.

Unfortunately, the fix to “Active Input Handling” losing state is not retroactive. I.e. once the fix is out, projects then migrated to 2020.2 will not see the same regression but projects already moved to 2020.2 will not retroactively restore the state. Luckily, this one’s easy to recover from by manually changing “Active Input Handling” in the player settings.

2 Likes
10

The real question is though, will the fix being rolled out also fix my issue as well? :face_with_spiral_eyes:
I’m guessing no. :frowning:

11

Don’t quite follow :slight_smile: You mean this one ? If so, yes, that’s part of the regression in player settings which is being fixed. Don’t yet know, though, which version exactly it’ll land in.

12

Oh, no.
I actually mean this one . :smile:

13

Ah heh, doh, had my wires crossed here and didn’t see the obvious :slight_smile:

When you connect to the player from the input debugger (the “Remove devices…” dropdown), are any devices showing from the player?

Another important thing is that where devices are queried can make a difference. In the editor, due to the input system always running, devices can be available much earlier than in the player. For example, devices will generally not be available in Awake() but should be available by the time Start() is called.

14

He he, no worries! It happens to me too. :sweat_smile:

You know, I never even knew you could connect the Input Debugger to the Player! (Let alone how to do it).
But after getting intimate with the Input Debugger (by opening every drop-down I could find) I eventually managed to do it!

Unfortunately, the results were unsatisfactory.

Once I connected the Input Debugger to my Build I checked the Debugger and both my Mouse and Keyboard were listed as found devices, just like in the Editor. :frowning:
So yes, devices are being found in the Player.

Ooo. Very interesting.
I hadn’t realized that! :eyes:
Well, unfortunately, the error’s location resides in Update**. So if the Input System is doing a-okay and initializing properly, then I shouldn’t be getting Null Reference Exceptions, right? :frowning:
**Technically, I use a custom update manager to run my scripts, but in this instance the code is being called in Update by the manager, so I’m assuming that’s fine.

If you need my project, I can PM it to you if you think that’s necessary. In the meantime, I’m going to see if this happens in a simple, bare-bones project.

EDIT 1:
I think I found the issue (it’s on my side, and I’m 100% sure the issue is unrelated to the Input System (the Input System is just the one getting angry about it)).

I was unable to make successful reproductions of the issue I was experiencing in a reproduction project, so the input system should be functioning 100% properly! I have concluded the issue is from something I am doing on my end. So feel free to consider this issue as closed @Rene-Damm . (Apologies for for taking up your time!)

EDIT 2:
Still not an issue with the Input System Package, but the issue is deep and very odd.
Those of you who are interested, I’ve tracked the issue to what seems like this root problem: https://discussions.unity.com/t/814673