UI Integration?

I've been looking at the wiki and such and I haven't come across anything that mentions this. The settings the old system has, where we can set button navigation on a UI canvas to "vertical" or whatnot...what's the equivalent in the new system? If I disable the old system, this functionality goes away.

 

Yup, ATM the old backends have to be kept running for UI support (IMGUI should work but uGUI won't work without). Work on UI integration is planned to commence soon (as in, any day now). It may take a couple steps to get to UI support that's fully independent of any old APIs (ATM we don't yet have IME support in the new system, for example) but it should be useful even before taking it all the way.

 

Gotchya...so on a similar note, I'm not sure, but I think I might have a bug for ye'.

I have a title screen with vertically navigated buttons. I decided to try playing with the new input system, and I unwired the method from the start button itself, as per the old system, and manually called it with the new system like so:

Code (CSharp):

1.  PersistentManagerScript.Instance.map.GetAction("boost").performed += ctx =>
2.         {
3.             if (currentEvent.currentSelectedGameObject == startButton)
4.                 StartButton();
5.             if (currentEvent.currentSelectedGameObject == quitButton)
6.                 QuitButton();
7.         };

The PersistentManagerScript is a singleton, where I created that actionmap (map) so I could just handle that in each scene's script. currentEvent is just a variable holding the EventSystem. So here's the problem....

That worked, and the StartButton() method successfully did its thing and loaded my next scene (a selection screen). When I try to make a selection on that next scene, by pressing the same button, of course (boost), it reloads that 2nd scene! I figured out this was caused by the event subscribing above...so that is calling that StartButton() method even though the script with that method is destroyed.

 

This is one of the gotchas of using delegates and one of the reasons we want to provide an alternate API for responding to actions that does not involve delegates and does not put state on InputActions directly.

With the delegate-based interface, it's important to manually remove your delegates from callbacks when necessary (e.g. in OnDestroy).

We're still working out the mechanics of the alternate API. Polling isn't a good fit for actions (you'd only see the last state whereas the current responses see every state transition) but we'd like to have something of similar convenience.

 

Ah! Showing my programmer inexperience . I know it's good practice to unsubscribe events after relevance regardless...now I just have to...do it....

Thanks!

 

Is there in the current version something for interacting with the UI already?
So far I've been using the Standalone Input Module with the old input system so I was wondering what the best way of migrating from that is as of now?

 

There's UIActionInputModule which should be functional but has not seen a lot of testing yet.

 

Nice, I'll give that a try later. Thanks!

 

Awesome. Let me know if you run into problems.

Regarding use, the general idea with the module is that the various navigation and pointing interactions with the UI are represented as actions. They can be defined either directly on the module component, dragged in as actions from an .inputactions asset (toggle "Use Reference" on and drag in an action), or assigned at runtime by code.

Navigation/submit/cancel are for gamepad-style interaction and point/click/etc are for mouse-style interaction. There's also support for touch- and tracking-style interaction but haven't tried that part myself yet.

 

After playing around with it a little I got it to work.

Minor issues I encountered are:

1.) There seems to be a visual bug with the bindings in the editor. They tend to render at the top of the inspector window instead of the correct position (attached a screenshot)

2.) It seems the viveWand touchpad y axis is inverted and I can't seem to break that up further so to use that here in the UI up is always down for me.

3.) Unrelated to that, it seems even if I set the player settings to only the preview version the old system still works which may be undesired. At least the Input.GetAxis() still works with the mappings I have in the legacy input system (just updated to the new 2018.3.0f2 if that's any help).

4.) Also more a general wish: In the ActionReference window it would be super awesome if Ctrl+s would work instead of having to click that button to save

5.) Every time I remove a binding from the list in the editor it throws an error: InvalidOperationException: Stack empty.
I saw there is a PR that seems to address that already so I guess you are aware.

Other than that I really like the new system so far!
Makes things a lot easier. I hope there is gonna be an easy way to change the ActionReference at runtime to allow users to change bindings in the game.

edit: Since using the new input manager I also get this error spammed:
Assertion failed on expression: 'task.rasterData.indexBuffer == NULL'

with no further details, so not 100% sure it comes from the input manager but quite probable. Any ideas?
It doesn't seem to effect anything in an obvious way but unsure

 

Thanks for the feedback! Much appreciated.

Yup, the UI for when actions are embedded into components still has a couple bugs. Should get fixed soon.

I believe we have a ticket (this one?) open for that. There's a good number of issues that have accumulated with XR devices which are slated to get looked at pretty soon.

Was that with XR devices or other devices? Could be that the XR backend doesn't respect the switch and still pushes data into the old input manager.

Yup, agreed. Shortcuts are on the list. IIRC we were waiting for the new shortcut manager and API to land in Unity. Have lost track of that and need to follow up. I believe it's landed in 2019.1. Might mean that in 2018.3, we won't support shortcuts.

We'll take a look.

Glad to hear

We do have the APIs in place but ATM it doesn't look like we'll have a ready-made UI for use in-game available in time for 1.0-preview. For now, users's will have to roll their own UIs. But something to jumpstart this kind of stuff will come eventually.

Hmm, haven't seen that one before. Will give it a try with 2018.3.0f2 and see if I can repro. Which .NET runtime are you using? 3.5 or 4?