I love clean code: who doesn't? And it's why I love the InputSystem. My favorite Component of the whole bunch is PlayerInput: you hook it up and you're ready to go. But I've made 2 threads about issues with it and now I've come across another one, so let me write down exactly all my gripes with this beautiful but flawed component. 1: InputValue vs InputAction.CallbackContext. PlayerInput lets you pick its notification behaviour, between messages and events. What I do not understand is why the messages send an InputValue and the events a CallbackContext, as CallbackContext can do everything InputValue can and more (I use CallbackContext to get the device and add distinct behaviour for mouse vs joystick). It's also much easier on iteration to use a single type and not have to go back and refactor some methods to accomodate for a simple change in notification behaviour. 2: Notification Behaviour isn't flags. This one says it all. Although I can understand on one hand why this would be bad design, on the other hand I think designers should have the option. And if flags create ambiguity between Send Messages and Broadcast Messages... then just remove Send Messages, if designers are looking for performance they should be using events or direct hook up anyway. 3: Multiple PlayerInputs is made impossible. If it were up to me, I'd put a PlayerInput on my Player, my Car, my Minigames, my Breakdance Scene and my interactive credits. Like I said: the thought of hooking it up and going is amazing. Unfortunately I'm scared, because 2 PlayerInputs immediately tells the InputSystem that this is a multiplayer game and should do something with splitscreen if I'm not careful. It doesn't help that disabling PlayerInput throws index errors. I have a lot of trouble understanding how PlayerInput is meant to be used because of this, because I feel like both single player and multiplayer games should be able to support more than X amount of PlayerInputs but I'm quite unsure now. Like this post if you agree and want @Rene-Damm to know what's up. Sorry Rene, I really enjoy everything else. EDIT: The index errors were my fault. When the PlayerInput was disabled I still read one of its values, which I couldn't do because it was disabled. I've appended that method with checking if the callbackContext.performed is true.