The contents of the package are as follows:

• Config
• InputSystsem.inputsettings.asset - a default configured input setings asset. you should set this as your projects input system asset in order for this package to function properly
• InputSystemActions.cs - this is the unity-generated C# file that drives the event dispatch. I opted for generated C# events as they're the most performant, don't incur any GC collection, and since the intent is to have globally accessible events generated, we don't need the convenience of messages or unity events
• InputSystemActions.inputactions - This is literally just the default input actions asset that gets added by adding the new input system as a dependency. You can feel free to customize this asset, or use your own. Just make sure that whichever asset you're generating from is the asset that is referenced by your input system configuration asset
• Scripts
• InputActionGenerator.cs - This is the core script that generates the code which will bind to your input action maps
• LazySingleton.cs - This is a simple lazy-instantiated singleton I implemented in order to have the most convenient event binding. The generated events will be purely static, but in order to relay the input system events through these static events, an instance needs to exist to interface with the event dispatcher. This instance gets created the first time your code accesses InputEvent.Instance, which is required to enable or disable any input action maps.
• Generated(folder) - This may not exist when you first install the package, but this directory is where your generated event bindings will be created. Among those files you will see the following:
• InputEvent.cs - This is the root binding class. It inherits from LazySingleton, stores a public static {MapName}InputActions member for every input action map in your input action asset, which can be treated as a scope resolution for all of your input action events for the associated map. ex. InputEvent.Player.Shoot is the static event that gets bound to the "Shoot" event on the "Player" map on the default asset. Additionally, for each input action map in your asset, an Enable{MapName}Input and Disable{MapName}Input method are generated to enable/disable the input action map, respectively.
• {MapName}InputActions.cs - you will have one of these classes generated for every input action map in your input action asset. Additionally, in each of those generated classes are public static events that can be subscribed to. This class separation is entirely for readability as well as avoiding potential aliasing in the event that multiple maps have the same event names. The private contents of this class is all of what I refer to as the "relay" binding. It takes the Unity-generated InputSystemActions objetcs, adds a private listener for them, and that private listener invokes the associated static event. This is what allows us to achieve the "global" portion of NisGab

How to use:

The usage of this addon is incredibly simple. Once you have the input action asset that you wish to bind, right click it, and towards the bottom of the right-click context menu, you will see an option for "Generate Input Action Binding". Click this, and what you should see is the "NisGab/Scripts/Generated" folder be created and populated with your necessary files. To use your input system at this point, you need to do two things:

1. Enable the input action map you want to start listening to input for. ex.

InputEvent.Instance.EnablePlayerInput();

note: since we're accessing the instance, this creates the singleton on the fly, which handles all necessary initialization. Best practice is to put this enable/disable code in some sort of game state manager or game mode initializer/de-initializer

2. Bind your input callback to the relevant global event, either with a lambda or a method

InputEvent.Player.Shoot += (ctx) => { Debug.Log("Player Shooting Lambda Callback"); }

OR

InputEvent.Player.Shoot += OnPlayerShoot;

private void OnPlayerShoot(InputAction.CallbackContext ctx)

{

    Debug.Log("Player Shooting Method Callback");

}

while lambdas are convenient, method-based callbacks are preferable from a performance and maintainability standpoint. Just make sure to remove the callback at the appropriate time (if adding in awake/start, remove in OnDestroy, if adding on Enable, remove on Disable)

private void OnDestroy()

{

    InputEvent.Player.Shoot -= OnPlayerShoot;

}