HDRP crashes with new input system

InvalidOperationException: You are trying to read Input using the UnityEngine.Input class, but you have switched active Input handling to Input System package in Player Settings.
UnityEngine.Rendering.DebugManager.SampleAction (System.Int32 actionIndex) (at Library/PackageCache/com.unity.render-pipelines.core@7.0.1/Runtime/Debugging/DebugManager.Actions.cs:111)
UnityEngine.Rendering.DebugManager.UpdateActions () (at Library/PackageCache/com.unity.render-pipelines.core@7.0.1/Runtime/Debugging/DebugManager.Actions.cs:168)
UnityEngine.Rendering.DebugUpdater.Update () (at Library/PackageCache/com.unity.render-pipelines.core@7.0.1/Runtime/Debugging/DebugUpdater.cs:18)


Would love to disable the HDRP debugging thing that I really don't want too.

 

I reported that some time ago as well. As a temp workaround, you can just enable both input systems from your player settings.

The answer to my original report was along the lines that since input system was in preview, it wasn't any priority to support it yet.

 

HDRP Namespace is out of preview and 1.0 Input System is pretty much here, so get a move on Unity!

 

Perhaps they are hiding from the hippo in the new forum

High Definition Render Pipeline

In all seriousness, stuff from other forums has been migrated to that one, but not anything from this graphics experimental previews forum as best I can tell. Time to consolidate?

 

I am there now to terrorise.

 

Hippo, your Image little bit incorrect, you forgot about DOTS

 

Does anyone know if there's a bug raised for this oversight that I could monitor?

 

Thought I'd play with all the new toys. 2019.3 b5. Input System 1.0. Universal RP. Starting a new project so... why not. Considering this is surely going to be the standard setup in a few months, it's quite strange to think this is causing an issue. Changed it across to both systems to get rid of the errors, but seems counter-intuitive at this stage of development. ABSOLUTELY get that I shouldn't be too critical of a beta version. But Hippo (and others) raised this 2 months ago.

 

Well, I think I saw at least one step towards this. In the editor beta release notes for 2019.3:

Scripting: Add ENABLE_INPUT_SYSTEM and ENABLE_LEGACY_INPUT_MANAGER defines so code can be written to work in both input systems

Obviously they still need to code their systems to make use of this, but it looks like the groundwork is there.

 

Has this been fixed? And if not does anyone have a fixed version/how do I get rid of the render pipeline.

 

Just ran into this as well. Kind of amazing that it's been 2 months without a proper fix still.

 

Code (CSharp):

1.         void Start()
2.         {
3.             //temp to remove unity's debug updater which crashes with new input
4.             GameObject go = GameObject.Find("[Debug Updater]");
5.             if (go != null) DestroyImmediate(go);
6.         }

 

How is it not fixed yet, same for URP...

 

URP bug official acknowledgement here: https://forum.unity.com/threads/uni...es-with-new-input-system.735179/#post-5215022
URP bug ticket here: https://issuetracker.unity3d.com/is...input-handling-is-set-to-input-system-package

 

change in the player settings, the Input System (new) section for Both and that solves it

 

Not sure this is still a problem for anyone but I think I found the solution (aside from selecting "both" within the Player Input Settings as described by gericktoro above).

For me, this issue occurred as a result of me trying to port a project that was using the old input system over to the new input system. Most all the tutorials out there that explain how to do this cover all the steps except for one important step. Here it is:

If you have an existing EventSystem in your scene, select it. In the "Standalone Input Module" you will see a large red notice symbol with a button below it that reads "Replace with InputSystemUIInputModule." Click that button and it should fix this warning. It did for me.

 

My gratitude to HippoCoder, this bug is fixed with this tiny workaround! And the silly bug appeared in SOME Android builds in 2022.1.0a16 ...

 

It's probably a bug. Feel free to let the staff know on the alpha forum with a post there if you like, perhaps they'll fix it so you don't need a hacky workaround.

 

Ok will do!

 

@hippocoder

It turned out that you need to duplicate your code from Start to Awake and Update or else the error might appear again, so do my experiments indicate. It is a very peculiar anomaly, not always occurs.

If in Update the interval to check narrowed then Input System on the mobile screen STICKS, though a slight tap resets the UI buttons or menus, it is annoying and unprofessional looking.


public class KillDebug : MonoBehaviour
{

public GameObject evesys;
int interval = 20;
float time = 0.0f;

// Silly bug keeps coming back
void Start()
{
//temp to remove unity's debug updater which crashes with new input
GameObject go = GameObject.Find("[Debug Updater]");
if (go != null) DestroyImmediate(go);
}


void Awake()
{
//temp to remove unity's debug updater which crashes with new input
GameObject go = GameObject.Find("[Debug Updater]");
if (go != null) DestroyImmediate(go);
}

// Update is called once per frame
void Update()
{
time += Time.deltaTime;

if (time >1.5f)
{

GameObject go = GameObject.Find("[Debug Updater]");
if (go != null) DestroyImmediate(go);

time = 0.0f;
}

}
}

 

It's definitely something Unity should fix, assuming they know about it. Thanks for sharing back your findings!

 

@hippocoder
Update: The bug disappears in 2022.1.0b2!!!

I suggest that I will post a ticket since the bug is recurring on and off.

Please advise.

 

It's up to you. I suspect it's just the fact you might be on an alpha. You can just leave a forum post there and staff will know & ask for more if it's needed. Thanks for helping!

 

I now confirm this bug for the DEBUG message is not appearing in 2022.1.0b16. I will follow your guidance above after some sleep & my gratitude again.