Summary
Input is currently handled by the legacy InputManager within placement modes; Supporting both systems like this would be messy and add another layer of friction when adding new modes.
Reworking input handling is also an ideal opportunity to add support for editing mode controls and close #7
Solution
Centralise input in a wrapper class that branches based on the input system in use with compilation conditions.
Input consumers should be system agonistic by using an enum for input effects:
// Agnostically consume input
if (ToolInput.Get(ModeAction.Place))
PlaceObject();
New Input System
Input maps are stored in an Input Action Asset, it would be nice to generate this at install time so it doesn't add bloat to projects using the legacy system. A shortcut button on the overlay could open the action asset for editing natively, negating the need for custom GUI.
Main consideration of this design is that the action and internal enum name must match to avoid conflicts.
Example wrapper methods
. . .
#if ENABLE_INPUT_SYSTEM
public static bool Get(ModeAction action)
{
var map = _actions.FindActionMap(action.ToString());
var act = map.FindAction(action.ToString());
return act?.triggered ?? false;
}
public static Vector2 GetVector(ModeAction action)
{
var map = _actions.FindActionMap(action.ToString());
var act = map.FindAction(action.ToString());
return act?.ReadValue<Vector2>() ?? Vector2.zero;
}
#else
. . .
Input Manager
The wrapper could define a list of ModeInputs that contains a sublist of Input structs which modes read from, this could be edited either directly in the overlay or its own window.
Summary
Input is currently handled by the legacy InputManager within placement modes; Supporting both systems like this would be messy and add another layer of friction when adding new modes.
Reworking input handling is also an ideal opportunity to add support for editing mode controls and close #7
Solution
Centralise input in a wrapper class that branches based on the input system in use with compilation conditions.
Input consumers should be system agonistic by using an enum for input effects:
New Input System
Input maps are stored in an Input Action Asset, it would be nice to generate this at install time so it doesn't add bloat to projects using the legacy system. A shortcut button on the overlay could open the action asset for editing natively, negating the need for custom GUI.
Main consideration of this design is that the action and internal enum name must match to avoid conflicts.
Example wrapper methods
Input Manager
The wrapper could define a list of
ModeInputsthat contains a sublist ofInputstructs which modes read from, this could be edited either directly in the overlay or its own window.