How to Make Devices
Last updated
Last updated
This page outlines the steps required to make your own devices.
NOTE: Devices make use of “standard UI” to populate their buttons/settings menus. See Standard/Data Driven UI for more details on this.
An item is defined using a J_ItemPrimaryAsset.
If you want to make a new item, use Right Click -> Miscellaneous -> Data Asset.
The naming convention for items is PDA_Item_{ItemName}
For now, the main fields to consider are the Display Name, the Icon, and the Custom Item Details. For more details on the Custom Item Details list, see Custom Item Details.
In the Custom Item Details list, add a J Use Item Details entry. This is used to provide the details required by use items (devices). If no J Use Item Details object is provided, the item will not be treated as a device, so will not be allowed on your quickbar.
Once the Use Item Details has been provided, you can provide use item specific details, such as the abilities associated with the item. We’ll go into these more in the 3. Give the item an ability section.
Add a BP_QuickbarWidgetItemDetails entry to the CustomItemDetails list of the item if you want to give the item “info text” - this is shown in when the device is selected.
If you want your item to be interpreted as a specific “item type”, or have additional details that aren’t present in a base item, you can create a new item detail type, and add it to this list.
When you make the item detail type, make it inherit from J_ItemDetailsBase
When you do this, your new detail type can be added to the list, and any variables in this type can be configured from the J_ItemPrimaryAsset
You can then access the detail from a given item asset, using the GetCustomItemDetails function. This will return null if the item asset does not contain those details (so this can also be used to check whether the item is of the specified type - e.g. you can check for the presence of J_UseItemDetails to know whether the item is a use item.
The ItemExecutor is the class that handles what functionality is done when a given item is selected. It has the following details that can be overridden in blueprints, to make your item do specific functionality:
Class Defaults → Specify Abilities:
If this is true, we will control the abilities used by the item here, in the Ability Assets field. (It will ignore any abilities defined in the Item Asset)
This is useful if the Item Executor expects/depends on a particular ability for the given item.
Event Initialize Executor:
This is an overridable event called after the item in your Quickbar has been selected, once the executor has been set up, and has loaded all the abilities.
The default behavior for this event is to "activate" all the abilities, e.g. turning on targeting or the like (see Morpheus Ability System. If you don’t want this behavior, don’t call Parent: Initialize Executor - you can instead manually call Handle Activate when you want.
You can use GetAbilitiesList after this point to get the loaded abilities defined from the Ability Assets list.
Event Tear Down Executor:
Similar to the above, this is an overridable event, called when the item has been deselected, and can be used to clean up any state/created objects used by the item.
(The default behavior does nothing)
If you want to listen to input events on the item executor (e.g. listening to left click to activate your item's ability), you can use the ListenToInputs method in the EventInitializeExecutor event on the client.
Once this is called, InputAction events on the executor's blueprint graph will be triggered.
If you are using "enhanced input", you will need to provide the mapping contexts of the input actions you're wanting to listen to in the MappingContexts field.
Event Primary Input:
This is an overridable event called when the primary input (currently Left Mouse Click) is modified - Pressed = true when it is pressed, Pressed = false when the button is released.
By default, this event will execute the first ability in the abilities list (if one exists). If you want this behavior (e.g. you have an ability, and want left click to perform the ability), you don’t need to implement the event.
If you want other behavior on left click pressed/released (e.g. clicking modifies an ability, that right click then performs), you can override the event.
Event Secondary Input:
Same as Event Primary Input, but on the secondary input (currently Right Mouse Click). By default, it’ll attempt to execute the second ability in the abilities list, if there is one.
To create the menu used to control the device (e.g. any buttons, toggles, or submenus), you need to add a standard UI data element to your executor. Once this is set up, the data will be found by the inventory system, and the UI will be built and updated automatically.
Make a variable extending M2_StandardButtonDataBase, e.g. a M2_StandardButtonListData
Make sure it has the Details->Advanced->Instanced box checked, so that you can create the subobject within your executor
Implement the M2_UsesStandardButtonsInterface, and pass through your created standard UI data
In your list data, you can provide buttons by adding M2_StandardButtonData (don't forget to provide an icon, an Id and some text!), or add settings by adding the appropriate device setting (e.g. BP_DeviceSetting_ColorSelect
(More details on how standard button data works can be found here: Standard/Data Driven UI)
Then in your executor, you can get and listen to the buttons being clicked like so:
You can get and listen to the settings like so: (NOTE: Further details on “item settings”, including pointers on making your own can be found here: Device Settings)
And if you need to e.g. update a button, you can call UpdateDetails to modify its text or icon:
For details on how to make morpheus abilities, see Morpheus Ability System.
The ability asset can either be set via the item details, or the item executor
In the executor, you can trigger the ability using ExecuteAbility. If you need to pass specific information when triggering the ability (i.e. sending additional info to the server/other clients), you can set it here.
If you’re wanting to see how devices work, fastest approach would probably be to walk through a simple existing device, see how it is set up, and go from there. A good example to check out would be PDA_Item_Soundboard
Its various assets:
PDA_Item_Soundboard
BP_ItemExecutor_Soundboard_List
BP_DeviceSetting_SoundList
PDA_Ability_Soundboard_List
BP_SoundboardAbility
NOTE: The other way of adding key bindings is using standard UI buttons. That flow for configuring button data in your item executor is outlined in Configure the “button data”, and you can set up shortcuts by following .
As mentioned in , the old flow for item executors bound LMB to “primary input”, and RMB for “secondary input”, if you have the BindQuickbarActionsInHandler capability. This flow is deprecated in favor of Adding input events to the executor.
PDA_Ability_[AbilityName], and are simple data assets that point to the ability blueprint (e.g. BP_ForceNavigateAbility
BP_ItemExecutor_ImpulseGlove_Approachability.
