Wait! There's seriously not a held button interaction in the new input system????

I'm trying to learn the new input system so I can just do inputs during fixed update (AWESOME!!!) and I'm finding out that the most basic of all features you could ever imagine doesn't seem to be out of the box and I'm frankly astonished.

If you want to have a button that does something every frame when held, like Input.GetButton, it takes some serious coding it seems.

I have been scouring all over and every answer is a damn term paper.

REALLY???

If I want a button to act as a sprint while holding it down I need to basically do C# events????

REALLY??????

This is something that was NEVER considered during the developing the new input system?

REALLY??????????????????

I MUST be missing something here, but I've been scouring tutorials and I got nothing.

How is this not right there under interactions?

How is there not an option to send a unity event every cycle a button is held?

Someone please tell me I'm dumb here and missed something.

 

https://docs.unity3d.com/Packages/c...UnityEngine_InputSystem_InputAction_IsPressed

 

I think you should be able to get button state through ReadValue().

Also Ctrl+F for "GetKey" here:
https://docs.unity3d.com/Packages/com.unity.inputsystem@1.5/manual/Migration.html

 

I really appreciate the help, but I think my point that this is an glaring oversite still stands.

There is absolutely no good reason why this isn't built into interactions.

 

It's not an oversight. It's an overall better pattern that doesn't rely on backwards practices such as strings and enums.

You can't go into it with the same mindset as the old input system.

 

I've read that.

Do you happen to know how I need to declare a gamepad then?

Code (CSharp):

1. if (Keyboard.current.spaceKey.isPressed || Gamepad.current.buttonSouth.isPressed) JumpBoost();    

Keyboard is fine, it must have a default function.

But the Gamepad seems like it needs to be declared.

I'm assuming something like:

Code (CSharp):

1. Gamepad gamepade;
2.  
3. void Start ()
4. {
5. gamepad = (code to recognize my gamepad)
6. }

 

I've never had to write code like that.

I often just reference the input action reference assets: https://docs.unity3d.com/Packages/c...yEngine.InputSystem.InputActionReference.html (these are the sub objects of your action map asset).

Reference that via the inspector, and just check

.action.IsPressed()

.

So rather than calling a package terrible when you've spent less than an hour on it, have a proper read through the docs.

 

I'm not trying to call it terrible. There's lots of cool stuff in it. But I'm sorry, it really should just have a held button feature.

It should be written from the perspective of being able to have multiple ways to interact with a buttons, dpads, mouse, triggers, analog sticks, etc, and have all of the ways to interact with them handled all the same way.

That's just basic design principles.

I shouldn't have have one method for holding down a button verses tapping it. I should be able to both the same way.

I'm sorry I'm being loud about it, but you know I have a point.

EDIT: Also, in fairness to me the documentation is a small novel. I'm not as good as you at coding and it's a lot to absorb for a novice.

 

It does and I have shown you how to do it twice over now, so I don't know why you keep going on about it when you're wrong.

 

I'm sorry, I don't think I'm explaining myself well.

This is what I'm saying it should have:



I'm really not trying to be a jerk about it. Just frustrated atm.

 

bool isRunning = Keyboard.current.leftShiftKey.isPressed

I'd be very surprised if you never used something like that.

The real oversight is that Input System documentation is complete S***.

The type of interactions you're trying to implement is normally done through code. Action also fires something like three separate callbacks which is probably the reason why there's no "fire every frame".

You'd need to abstract the gamepad through action map and use either InputActionReference or that automatically generated input map class to access the gamepad button.

It is not very convenient when you want to quickly test something, though.

 

Yeah, it took me a minute to work that one out.

I think there could have been put more thought into how to make it accessible and powerful at the same time.

And I'm still struggling to figure out how to not make Gamepad null.

I need to sleep on it.

 

It doesn't make sense to work that way. What you want to do needs to be done via code, aka, 'polling'. The input actions only specify 'how' an action is fired. 'Held' doesn't make sense as an action can only be 'fired' once.

You've only used it less than a day. It's astonishingly powerful once you realise how much low level access you get, and how much you can extend it.

 

You need to make an action map. In the action map you'd need to define "ButtonX" or something. There you add a binding of a real gamepad button AND keyboard button to that action through UI.

Then you access that action you declared through either InputActionReference, or you use the class that input map generates. And poll that "ButtonX", and not the gamepad.

Supposedly "this is the way". According to whoever designed the system. It is debatable whether this is true, especially when you take increased amount of boilerplate into account.

However if you do this it won't matter to you if Gamepad is null. The action wil work whether you use keyboard or gamepad, without you having to change a thing in code.

The new system is like they've tried to remake DirectInput and took it to eleven. Sometimes people prefer something dead simple. SDL-style input polling is a good example of "dead simple". Just a few functions without hundreds of properties with multiple callbacks each.

 

Youre a solid person and I always appreciate all your help, but I'm just going to have to disagree with you on this one.

There's absolutely no reason why this shouldn't be built in. None.

Saying otherwise is like saying "You don't need a turning signal, you can just jump the relay in the fuse box".

Yeah, I need a fuse box and need to be able to work on it, but I don't think I'm being ridiculous expecting to be able to use my turning signal from the driver seat.

 

You shouldn't do FixedUpdate if you want things to happen in every frame. Apparently you do not know how FixedUpdate works. Please, read up and understand, there is no guarantee that FixedUpdate runs in a particular frame or there is only one (there can be many FixedUpdate in one frame).

Second: You can check if an action was executed or held in a frame (polling) or you can hang onto .started and .canceled events and everything happens between the two you handle as button held down.

It's not rocket science, just find the time to read the manual, it is better than people say it is, you just need to take the time to read it and understand the underlying logic.

ps: the Input System has a dedicated subforum where even the developers come and answer your questions. General is still not a support forum.

 

I guess I prefer having a more open API I can use to build a more focused API to my liking... which I did. I have my own internal package I can drop into projects and get inputs running quickly.

Should we be expected to this? Probably not, though Unity has always been frame work first, drop in solution second (for better or for worse).

It is built in. You poll it via code, as you have been told thrice over already.

Interactions specify how an InputAction is fired. Aka, it refers to the

.started

,

.performed

and

.cancelled

event delegates. 'Held' doesn't make sense in this context, as you can't 'hold' a delegate to be true; they are fire-and-forget.

Thus, you poll it with

.IsPressed()

. Thus it is built in.

 

I appreciate it, but I do get FixedUpdate.

The whole reason I want to move to the new system is specifically to do input on FixedUpdate.

With the old system you have to take the input on the Update (Frames) cycle, then apply it to the physics on the FixedUpdate frame. It creates a gap, especially if you have a low FPS. So tying input to FixedUpdate works really well in the right circumstance.

And I should have said cycle, not frame.

 

I think you are missing my point.

Yes, I understand we can do this in code.

My point is we shouldn't HAVE to.

My point is it should be an option under the input actions menu in unity itself.

It has tap, double tap, hold, slow tap, etc.

It should have one that calls every frame it's held.

Right there.

In the menu.

Not in code.

 

Well I've explained to you why a 'held' option there doesn't make sense, which you seem to argue despite having used the New Input system for less than a day.

Have fun. I'm out.

 

So... you don't want to do something in every frame after all. That's another story, just beware, that you can easily miss inputs if you only read it in fixed update but you use it things that runs in the update cycle... when you are seriously low FPS (because of hardware limitations) it won't do you any favor. When there is a hw limitation, you will may have multiple input in one frame, you will have to be careful not to miss them in the regular update cycle.

The ones there have nothing to do with frames. They have everything to do with events. You can force the system to call your code at certain points.
If you want to do something in FixedUpdate, you write the thing in FixedUpdate, you don't need another event calling your code in FixedUpdate. That's what FixedUpdate does.

 

Uh, I prefer an API where I can do everything I need in 10 lines of code. The bare bones SDL API could do that. It is simple as a brick and equally efficient.

Building a facade can be lots of fun, sure, but I'd rather not end in a situation where I HAVE to do it. based on my experience with input system, it is in the state where you have to waste a ton of time before you can use it.

That's in a opinion, of course.

Also:

You SHOULDN'T handle input in fixed update. It does not fire at fixed intervals, and can fire in bursts if FPS is low. In bursts, meaning multiple times between frames. Or it can skip frames and not fire. If you handle input there, you can get odd effects.

Also, like Lurking-Ninja correctly said, Input system is event-based. For example, imagine writing a handler for a typewriter. It is a royal pain to do with polling (and it won't work if IME is involved).

 

Okay, that makes a little sense, but why can’t those events just get sent out on update/FixedUpdate?

 

I’m really not trying to upset you, but I can’t help but feel you are so dug in on this you are simply refusing to entertain what I’m saying.

I get these are events. Just make it so that it runs the event every update. It’s not that complicated.

 

There's no point in that because that functionality already exists. Ergo,

InputAction.IsPressed()

.

Again, the point of Interactions is to specify what requirements should be met before an event is fired. 'Held' isn't a requirement, it's merely a state. A button is either pressed, or it isn't.

 

Bruh.

 

Also if it bothers you so much, just implement it yourself: https://docs.unity3d.com/Packages/c...nityEngine.InputSystem.IInputInteraction.html

 

They could, but it introduces an overhead for something which is redundant and idiomatically inconsistent.

If you're using the events, then something is "held" between the started and stopped/cancelled (whatever it is called) events, just set a flag for your ongoing thing to use (isSprinting = true, change a property (currentSpeed = runSpeed), or otherwise as needed.IIf your code is designed around events then you don't need to be re-told about the action state each frame.

If you're not using polling, check it each tick using IsPressed() or whatever it is, just as you would with the old system.

You wouldn't typically design something which intentionally mixes these approaches.

 

Honestly, I could see a use for a "give me an event every N seconds while HELD" Interaction and then let the Action Map hold the N parameter (and allow it to be very very very small if desired). It mimics the Keyboard repeat rate.

One thing I think the "just code it with polling" crowd here is overlooking is that anything in the Action Map should (eventually) be something that end users have control over, to change to their liking even during runtime. There's value in letting the code just deal with a single approach, receive events, and then letting the user manipulate the control scheme to their liking, including HELD or AUTOREPEAT or whatever you wanna call it. The behavior of the Input System is supposed to be dictated by the data, à la ScriptableObject philosophy. That's how Steam Input / Big Picture works, and that's what you're gonna need for Handicap/Accessibility gains too.

(Man, I can't believe I made an argument FOR ScriptableObjects, I hate that stuff.)

 

@Not_Sure, I did find this older thread talking about a Hold interaction and an experiment they went through calling it "Continuous." They decided at that time the overhead was too high. But I think they will eventually have to come around and do something similar again, or as @spiney199 said, you can write your own interaction. For now, though, polling is the answer, as unsavory as that may be for a data-driven input configuration.

https://forum.unity.com/threads/new-input-system-how-to-use-the-hold-interaction.605587/

 

After some sleep, could yall at least concede that a held function that triggered on every update, fixedupdate, or on it's own time iteration for things like rapid fire makes a LOT of sense?

 

Every Update AND FixedUpdate? No, it doesn't make a lot of sense.

 

I think he meant or, not and. User choice.

 

That would be nuts

 

Just wait till you discover they don't have the basic gestures for mobile either. While I understand the point others here are trying to make the new input system is designed with the intent of having multiple workflows. If you want a high level one instead of a low level one it's supposed to be providing that.

https://docs.unity3d.com/Packages/com.unity.inputsystem@1.5/manual/Workflows.html

 

Fair call, I can see potential utility for that. Though the more I think of it... well, see below a bit.

I think this is a great option to have, but I surely don't think that players necessarily "should" get access to "anything" (everything?) in the action map, particularly if it's being used for stuff mentioned here such as configuring fire rates. Unless you put another layer of code in there anyway, then data in your action map becomes directly tied to your game logic and balance.

I guess that's one of my thoughts as to maybe why it's not in the action map already*? Even if the action map does have a "held" or "continuous" or "repeat" action or something, with a field to determine the interval, does it actually save us from writing any code at all? If I were to implement that in my game then there's a bunch of other logic I'd need to tie into it anyway:
- During which game states do I want to do something with it? It's not all of them.
- How does the timer respond to scaling of time?
- What other in-game events might interrupt, pause or restart the timer?

As soon as I have to address any of those (i.e. as soon as my thing goes past a simple prototype) I almost certainly need at least one or two gameplay-domain variables which don't belong in my input map to be associated with it (e.g. attack rate of a weapon should be a property of the weapon, not dictated by the input system), have to add my own logic to deal with the above cases (and likely more which haven't sprung to mind), and likely even want to ignore the repeat rate from the input system and revert to using the start/cancelled events (at which point, having the unused variable in the action map is noise at best, and potentially confusing).

All of that aside, I certainly see value in a player-facing** repeat rate property on all action types where it makes sense (e.g. pressed actions), because there are players who have trouble repeatedly pressing buttons, holding them, letting go in time, etc. for various reasons or in various circumstances, and making that kind of thing customisable is helpful for accessibility.

When you start thinking about that kind of thing, it's helpful (personally, I'd say important) to make sure you've got clear boundaries in place between input signaling (i.e. the action map, e.g. "the player has started firing") and input handling (i.e. what your game logic does with that information, e.g. "the player currently has a weapon with an attack rate of X, so I will now spawn a projectile every 1/X seconds until they stop"). Yes, this makes your code a little more verbose, but I've always found separation of concerns to make things easier to solve (unless people get silly with it, of course).

* Another thought being that they maybe did want it there and just didn't get to it, just as with better documentation.

** And completely transparent to our use of the input API. The entire point of an action map is that our code does not have to care what the player is physically doing to signal those actions.

 

@Not_Sure, this post might be of use to you - @Invertex seems to have written and shared an interaction which calls .performed continuously instead of just once.

Aside from that, one of the devs of the new input system said that there was a continuous callback in there, and it got removed because of edge cases and code complexity. I don't have time to check myself, but it'd be cool to know how much of the other not-completely-fleshed-out stuff (e.g. being able to get the duration of an action, but not its progress) has been addressed in the intervening time.

 

Regarding repeating rapid fire action, I could swear that I saw something like that in the docs, using string initialization syntax. However, I do not remember the syntax, don't remember where I saw that, and there's high chance that I'm misremembering something.

I think the issue here is that with the new input system, it is not clear what it is trying to abstract.

Ideal usecase seems to be when the action map is used as an abstract input device, that acts as a facade for several real life devices. For example, you can define that you have a "jump" button, and then action map provides a button that is a "universal jump button" and can be controlled by multitude of devices, plus user can configure it.

This reasonable enough logic is shattered when you notice that action map is also trying to provide support for "hold", "tap", etc. Because this is not something that a "universal gamepad" is supposed to be handling, this is game logic level. As a result we get people who try to implement game logic actions through action maps rather than "virtual buttons".

 

Indeed, a button is tapped, an action is not. That's why the started / performed / cancelled thing makes sense to me and I don't personally expect any other events from that area.

The language around this is really tricky though, right? I'm not even 100% sure what you mean by this, and it's hardly helped by the Input System itself not being clear (e.g. "Button" being an "Action Type"). Regardless, I agree that gameplay info should not live in the Input System.

While the system doesn't enforce this, my personal application of the Input System vs. gameplay responsibilities is this:

• The Input System decides when the player has started or ended an action, without knowing, caring or influencing what impact they have on the game rules.

• Gameplay systems take that information and apply it to the games rules, without knowing, caring or influencing what input each action originated from.

Neither system cares how the other does its thing, and I don't want to pollute either system with info related to the others' responsibility. My "shooting" action does not know about how many different guns there are or how they work, each of which could be completely different, and my Weapon class does not care if "shooting" actions start or end from a button, a voice command, the accelerometer, or some other random thing. This isn't just about keeping things "neat", it's about making sure that the people designing and implementing different parts of the game aren't constantly breaking each others' stuff.

 

The way I understand it game input can be split into two parts:

* Peripherals. The actual device a player interacts with. Actual buttons, joystiicks, axes, pedals, whatever. Physical device.
* Actions you're trying to perform within the game. With their in-game semantic meaning. "Jump", "Crouch", "Shoot". You could call t hose "Commands", I guess, though this is not ideal.

"Hold", "Tap" and so on. normally should be implemented somewhere between "Peripheral" and "In-game actions", because they're used to allow one physical button to trigger multiple in-game actions.

Unity Input System fails to separate Peripherals and Action and mixes them into one pile. It s documentation also appear to encourage implementation of "Game Action" through action map, which I think is a bad idea, as this leads to GTA input configuration, which is a nightmare to deal with (you have hundreds of actions on option screen, all entangled together and conflicting). And with my limited experience, Input System works better when you ignore all the nonsense with held button it is offering and threat it as a peripheral abstraction layer.

Systems like DirectInput worked as Peripheral Abstractors as well. They were trying to provide a common "facade" interface which can be used with any input device in existence. That worked fairly well. The only thing that does not quite fit into this is text input, which needs to be handled a bit differently and needs to be handled as a typewriter, because of existence of IMEs. Also, like I said, I really liked the way SDL Input worked. You can enumerate all devices, request their number of button/axes/etc, then query each one of them when you need it. And for text input you get message-based events. It was simple and robust.

 

This is barely tested for edge cases from my end, but it seems to be working for a simple "Hold shift to sprint" scenario. Assuming you're using "Invoke Unity Events" behavior in your Player Input (which is the best way to use the input system IMO) , you can use the following extension method to toggle a boolean when a button is held:

Code (CSharp):

1. public static class ExtensionMethods
2. {
3.     public static bool IsInputPhaseHeld(this CallbackContext ctx, bool state)
4.     {
5.         return ctx.phase switch
6.         {
7.             InputActionPhase.Started => true,
8.             InputActionPhase.Performed => state,
9.             InputActionPhase.Canceled => false,
10.             InputActionPhase.Disabled => false,
11.             InputActionPhase.Waiting => state,
12.             _ => state,
13.         };
14.     }
15. }

Usage example:

Code (CSharp):

1.  
2.     bool _isSprintHeld = false;
3.     //This is the method you callback during a Sprint action event in your Player Input component
4.     public void SetSprint(CallbackContext ctx)
5.     {
6.         _isSprintHeld = ctx.IsInputPhaseHeld(_isSprintHeld);
7.     }

Also as a note, the input system makes sense that it doesn't fire an event on every update, performance wise. You just have to be smart with how you read the data you get from the events with the different phases, and use it as you need. It doesn't do everything for you. Think "outside the box".

 

I am REALLY sorry if I have totally missed the point of all this, and I do acknowledge that I am replying to a six month old post... but... Just use a Action type of Button, with an Interaction of Press And Release. The event (I am using a PlayerInput component on my player game object, set to SendMessage) gets called when the button is pressed, and again when it is released. I only need to set a member variable of type bool depending on the value of input.isPressed in the called method, and that gives me my sprint/walk functionality.
..but sorry if I have missed the point entirely!

 

Well, guess the thread starter was looking for an out of the box solution without needing to use a custom variable, but your solution solves the issue of course.

Btw. unless an Update method isnin use anyways, don't do an "if (sprinting)" in an update and instead launch a coroutine on the button press which ends on release. That can be more performant, at least for buttons that are used only occasionally (am mentioning this cevat because while coroutines avoid the constant polling of the Update(), they incur a small amount of memory garbage).

 

Why would you choose a coroutine which allocates over an Update() where you just set enabled = false when it's not needed?

 

Hmm, didn't think of disabling the script. It's an interesting thought, yeah.

 

^^^
This is the best way I've been able to do it too, and since I had a hard time researching it myself to get it how I liked and no good examples have been provided in the thread imo besides this description, here's my setup:

Code (CSharp):

1. // Move
2. public void MoveInput(InputAction.CallbackContext context) {
3.     movementInput = context.ReadValue<Vector2>().normalized;
4. }
5.  
6. // Jump
7. public void JumpInput(InputAction.CallbackContext context) {
8.     if (context.performed)
9.         if (isGrounded) {
10.             velocity.y = Mathf.Sqrt(jumpHeight * -2f * gravity);
11.             timeSinceLastBored = 0;
12.         }
13. }
14.  
15. // Run
16. public void RunInput(InputAction.CallbackContext context) {
17.     if (context.started)
18.         runPressed = true;
19.     if (context.canceled)
20.         runPressed = false;
21. }

Which lets you do this for ex.

Code (CSharp):

1. // Update is called once per frame
2. void Update() {
3.     PlayerMovement();
4.     FallOffMap();
5. }
6.  
7. // Handle player movement
8. private void PlayerMovement() {
9.     // Get movement direction from input
10.     Vector3 movementDirection = new Vector3(movementInput.x, 0f, movementInput.y);
11.  
12.     HandleCollision();
13.     ApplyVelocity();
14.     HandleMovement(movementDirection);
15. }

Along with this Input System Events setup:

Which is also nice because it separates how the functions show up:


I assigned all the events to an InputManager script on the same gameObject, so that the scrips using the input were easier to manage, but it's not necessary as you can just assign the scripts using the input

Code (CSharp):

1. [SerializeField] ThirdPersonMovement thirdPersonMovement;
2. [SerializeField] PlayerTrigger playerTrigger;
3. [SerializeField] TrashPicker trashPicker;
4. [SerializeField] PointGenerator pointGenerator;
5. [SerializeField] UIController uiController;
6. [SerializeField] RemoveGridTexture removeGridTexture;
7. [SerializeField] CamFollowZoom camFollowZoom;
8. [SerializeField] RadioController radioController;
9.  
10. // ThirdPersonMovement
11.  
12. // Move
13. public void OnMove(InputAction.CallbackContext context) {
14.     thirdPersonMovement.MoveInput(context);
15. }
16.  
17. // Jump
18. public void OnJump(InputAction.CallbackContext context) {
19.     thirdPersonMovement.JumpInput(context);
20. }
21.  
22. // Run
23. public void OnRun(InputAction.CallbackContext context) {
24.     thirdPersonMovement.RunInput(context);
25. }
26. //For mobile it should be based on distance knob goes out with markings to tell the diff
27.  
28. // Interactable functions
29.  
30. public void OnInteract(InputAction.CallbackContext context) {
31.     if (context.performed) {
32.         //oldPlayerTrigger.SphCast();
33.         playerTrigger.TriggeredInteractable();
34.  
35.         trashPicker.TrashInteract();
36.     }
37. }

And don't forget you do still have to:

using UnityEngine.InputSystem;

on any script that you want to call these input functions on

 

Just a side note, input System actions has inProgress state. So that can be used as held state, besides watching for up and down edges of the input.

 

Just to get on topic with the OP I'm baffled the same way that there is no interaction/processors that will trigger the input action in time defined cycles. Or anything that was thought for that. This is just plain ABC game UI stuff, hold a button to go through a list of items, or whatever. And no, no arguments that were put here saying its "normal" are convincing.

We are in the business of making games, unity should help make them. A very common interaction in a new input system on one off the most used engine in the industry might find a way to do that. So in the meatime we'll each of us ofc have to reinvent our own wheel. Hence it's worth mentionning that it's badly missing.

 

Shouldn't IsPressed be used instead ? I'm afraid that inProgress will just stop at the interaction first cycle ?