Usage pattern from ECS Jobs

Hey,

I've been playing around with the new input system and trying to use it from ECS/Jobs code.

I managed to load the bindings file into a job and set up all the bindings using input action callbacks, but I feel that is a lot of unnecessary methods just to set variable I then pass into a job.

Is there a way to poll for the status (started/cancelled) of actions instead of using the performed/started/cancelled events? I see from older examples that there used to be a field called "hasBeenPerformedThisFrame" but that seems to be gone now.

This is an example of what I'm currently doing.

Code (CSharp):

1. protected override void OnCreateManager()
2. {
3.     base.OnCreateManager();
4.      
5.     InputActionAsset asset = Resources.Load<InputActionAsset>("GameInputBindings");
6.     inputManager = new GameInputBindings(asset);
7.     fireAction = inputManager.Gameplay.Fire;
8.     fireAction.started += OnFireStarted;
9.     fireAction.cancelled += OnFireCancelled;
10.     fireAction.Enable();
11. }
12.  
13. private void OnFireStarted(InputAction.CallbackContext context)
14. {
15.     IsFiring = true;
16. }
17.  

I tried polling fireAction.phase and I could see it's being set to Started, but goes straight back to Waiting and never shows Cancelled or Performed.

 

If you're fire action is tied to a Press button, there may be a bug where it Performs exactly once and then never again, unless you have the Continuous flag set to true: https://github.com/Unity-Technologies/InputSystem/issues/470. It's been reported by at least 1 other user in the main input system forum thread.

As for your other issue. I wouldn't pull the actions into the manager directly.

Instead write an ECS-Convertible Monobehaviour component that sets all that up and either caches the event state, or uses the InputActionTrace class to buffer the action results, and then use the System to pull the data out of that.

That's what I've recently re-written my setup to do and it's pretty straightforward after you wrap your head around the conversion pipeline interfaces.

 

Yeah I initially tried using the conversion pipeline to convert maps/actions set in a behaviour into components, but quickly ran into issues since none of these classes are blittable.

I could do the polling in a MonoBehaviour but IMO that's not any better than polling from the job.

What I currently do for Vector2 values is catch the started/cancelled events, save the CallbackContext instance and then call ReadValue<Vector2>() on that in my OnUpdate()

I will look at the InputActionTrace class, thanks.

 

You can add non-blittable classes to an entity via the conversion pipeline, and access them safely in ComponentSystem. Look at EntityManager.AddComponentObject() instead of EntityManager.AddComponentData(). You can also set the ConvertToEntity setting from Convert and Destroy to Convert and Inject GameObject, and that will retain all of the existing MonoBehaviour/Components on the converted GO, without you having to do any extra work in to re-add the Mono components.

Right now I just use InputActionTrace + action maps and action GUIDs to filter and on the main thread into blittable event buffers, then do all my processing on JobComponentSystems.

 

To clarify a bit, I'm not really confused about the nature of ECS here. And I already have a functioning prototype that allows me to use re-bindable input in my ECS project.

I am unhappy about there only being an event-driven model to get the input data.

I want to be able to do things like this:

Code (CSharp):

1. InputActionAsset asset = Resources.Load<InputActionAsset>("GameInputBindings");
2. var gameplayActionMap = asset.GetActionMap("Gameplay");
3. InputAction fireAction = gameplayActionMap.GetAction("Fire");
4.  
5. // This I cannot do atm, or at least I haven't found a way to
6. var isFiring = fireAction.ReadValue<bool>();
7.  

 

When i was messing around with getting the input system into ecs, i had to make a dedicated system to process the inputs and then had a single entity with an input struct with all the necessary actions (Fire_Up, Down, Pressed, etc). The setup also gave me a nice place to handle bespoke actions like combos.

Then i could just get the data for any of the systems that needs inputs rather than setting up awkward events all over for various system that needed inputs. I just need to setup awkward events and stuff in one place

I REALLY hope that one day inputs from ActionMaps etc get way to just poll the inputs...please!

 

I’ll check this out next time! Looks like it’ll make processing events much better for me

 

Thanks! Going to give this a try

That is the pattern I'm following, I just wasn't happy with how I was populating the input struct (component) in the system.

 

So, a bit more than one year later, what are the recommended approaches to using the new input system and DOTS?

 

I would also like to know this. A white paper or blog post would be great. It seems like a bit of a hole right now. Most of the samples are pure simulation.