Legacy Reference

Setting Up Controls and Action Maps

This section describes how to create and modify action maps to customize the controls to the needs of your game.

Action map profiles for all supported operating systems and devices are located in Game\Libs\Config\Profile\DefaultProfile.xml. This default XML file organizes controls into the following sections, each of which is controlled by its own action map:

  • multiplayer

  • singleplayer

  • debug

  • flycam

  • default

  • player

  • vehicle

  • land vehicle

  • sea vehicle

  • helicopter

Each action map can be enabled or disabled during runtime from Flow Graph, in Lua scripts, or in C++ code.

See the topic Default Controller Mapping for an overview of the controls in the SDK package.

Action Maps

An action map is a set of key/button mappings for a particular game mode. For example, there is an <actionmap> section for helicopter controls called "Helicopter", which means that everything inside that section consists of key and button bindings that apply only when flying a helicopter. To change your common in-game bindings, go to the section starting with <actionmap name="default">. There are also sections for multiplayer-specific bindings and, of course, any other vehicles or modes you need.

The following is an overview of a standard action map, in this case the standard debug one:

<actionmap name="debug" version="22"> <!-- debug keys – move to debug when we can switch devmode--> <action name="flymode" onPress="1" noModifiers="1" keyboard="f3" /> <action name="godmode" onPress="1" noModifiers="1" keyboard="f4" /> <action name="toggleaidebugdraw" onPress="1" noModifiers="1" keyboard="f11" /> <action name="togglepdrawhelpers" onPress="1" noModifiers="1" keyboard="f10" /> <action name="ulammo" onPress="1" noModifiers="1" keyboard="np_2" /> <action name="debug" onPress="1" keyboard="7" /> <action name="thirdperson" onPress="1" noModifiers="1" keyboard="f1" /> <!-- debug keys – end --> </actionmap>


<actionmap name="debug" version="22">

When the version value is incremented, Lumberyard ensures that the user profile receives the newly updated action map. This is quite useful when deploying new actions in a patch of a game that is already released. If the version stays the same, changes or additions to the action maps are not propagated to the user profile.

Activation Modes

The following activation modes are available:

  • onPress – The action key is pressed

  • onRelease – The action key is released

  • onHold – The action key is held

  • always – Permanently activated

The activation mode is passed to action listeners and identified by the corresponding Lua constant:

  • eAAM_OnPress

  • eAAM_OnRelease

  • eAAM_OnHold

  • eAAM_Always

Modifiers available:

  • retriggerable  

  • holdTriggerDelay  

  • holdRepeatDelay  

  • noModifiers – Action takes place only if no Ctrl, Shift, Alt, or Win keys are pressed

  • consoleCmd – Action corresponds to a console command

  • pressDelayPriority 

  • pressTriggerDelay 

  • pressTriggerDelayRepeatOverride 

  • inputsToBlock – Specify the input actions to block here

  • inputBlockTime – Time to block the specified input action

Action Filters

You can also define action filters directly in your defaultProfile.xml file. The following attributes are available:

  • name – How the filter will be identified.

  • type – Specify actionFail to cause an action to fail. Specify actionPass to allow the action to succeed.

A sample action filter follows:

<actionfilter name="no_move" type="actionFail"> <!-- actions that should be filtered --> <action name="crouch"/> <action name="jump"/> <action name="moveleft"/> <action name="moveright"/> <action name="moveforward"/> <action name="moveback"/> <action name="sprint"/> <action name="xi_movey"/> <action name="xi_movex"/> <!-- actions end --> </actionfilter>

Controller Layouts

Links to the different controller layouts can also be stored in this file:

<controllerlayouts> <layout name="Layout 1" file="buttonlayout_alt.xml"/> <layout name="Layout 2" file="buttonlayout_alt2.xml"/> <layout name="Layout 3" file="buttonlayout_lefty.xml"/> <layout name="Layout 4" file="buttonlayout_lefty2.xml"/> </controllerlayouts>


The "file" attribute links to a file stored in "libs/config/controller/" by default.

Working with Action Maps During Runtime

In Lumberyard, you can use the console command i_reloadActionMaps to re-initialize the defined values. The ActionMapManager sends an event to all its listeners to synchronize the values throughout the engine. If you're using a separate GameActions file like GameSDK, make sure this class will receive the update to re-initialize the actions/filters in place. Keep in mind that it's not possible to define action maps, filters, or controller layouts with the same name in multiple places (for example, action filter no_move defined in defaultProfile.xml and the GameActions file).

To handle actions during runtime, you can use flow graphs.

  • Flow Graph – Input nodes can be used to handle actions. Only digital inputs can be handled from a flow graph.