Input control setup

Input control setup are Data Asset, mainly composed of two parts.

• Input checker: Custom logic used to determine the input events that the character can respond to in a specific state.
• Input processor: If the input checker allows the current input, the input processor is responsible for actual processing of the input event.

Dynamically add/remove Input control setup

The input system component allows you to configure one or more Input control setup by default, and you can also dynamically add/remove input settings during game runtime. (For example, when the character is riding a horse, use another input control setup and restore it after dismounting.)

Note : The last Setup added will become the current Setup.

Input checker

Built-in input checker

Here are some built-in input checkers that have some versatility.

InputChecker_TagRelationship

This checker is suitable for the use of Actors or Components that have implemented GameplayTagAssetInterface .

Once an input occurs, it will sequentially find the Relationship that satisfies the TagQuery based on the GameplayTags owned by the character, and check whether the current input event is in the allowed input list. If the input event is not allowed, the input will be cached or directly rejected.

Note: If TriggerEvents is empty, it means that any input event is allowed , otherwise only the specified input event can pass the detection.

If your project uses GAS (GameplayAbilities), you can inherit it through blueprint or C++ and override the "GetActorTags" function to return the current GameplayTags owned by the character through AbilitySystemComponent.

The following picture is a case study:

Create your own input checker

If the built-in input checker does not meet your needs, you can also create your own input checker to achieve various types of input judgment.

You just need to create a new blueprint or c++ class inherited from GIPS_Inputchecker, then overrides the function of "DoCheckInput". That's all.

Input processor

Input processors allow you to reuse various inputs in the game, and each input control setup can be associated with multiple input processors.

The following image is a classic example of input control setup in a Souls combat game.

Taking AttackInput as an example, it uses a reuseable input processor called "GAS: ProcessAbilityInput". When the InputAction associated with "InputTag.Attack" generates input event, the processor will attempt to activate the first Ability that can be activated in the AbilitiesToActivate list based on the type of TriggerEvents.

Taking MoveForward/Backword as an example, it uses a reusable input processor called "Basic: ThirdPersonMove". When the InputAction associated with "InputTag.Move" generates input event, it will make the player move.

You can choose any custom input processor to reuse, and you can create your own input processor (see below).

Create your own input processor

Create a new blueprint GGF_IP_Character_Jump that inherits from GIPS_InputProcessor, IP is short for InputProcessor.

Each InputProcessor blueprint can handle different input events for InputAction, among which Started and Completed are the most commonly used. You can also override CheckCanHandleInput to determine whether the input is valid.

In order to be reusable, the input processor generally only handles the logical part. The public variables and default values you add can be modified and configured on the instance.

Note: You can also create custom input processors in C++, just override the corresponding events at the C++ level.