Device Settings
Last updated
Last updated
As well as having simple buttons on an item executor, you can also make more advanced buttons containing submenus for you to configure your item's usage. For instance selecting what color you want your item's effect to have, or the target of your item's effect. Often we'd want these sub-menus to be reusable, for other items that want to do similar things.
These we abstract into "device settings" - classes which extend the normal M2_StandardButtonData
. These are menu buttons, where the sub-menu list contains the settings you can configure. The setting also contains an "info widget" button data, which is added to the screen to show information about the setting even when you're not in the sub-menu.
Adding device settings is the same as adding any other form of button data. In your item executor, if you add a setting to the ButtonData
field in the list, it'll show up as one of your buttons.
Then, similarly to how you would get button data of any other sort, you can find the setting from your data, and interact with it, such as informing it of your executor's state, or listening to the settings being clicked on.
We have a number of existing settings, which may fit your use case if you're making a new device. Have a look, if a setting type isn't fit for purpose, you can make a new one, or request one from the gameplay team.
If you are actively modifying a device setting, which is already in use in an item executor, sometimes the instanced version of the setting inside the executor can get broken. This often presents itself by one of the internal pieces of button data within the setting inside the executor becoming "None".
If this happens, the item may have blank settings, or run into blueprint exceptions/errors when used. If this happens, first thing to check is whether the any of the internals of the setting have unexpectedly become "None". If so, you can revert them, which will regain the correct button data and resolve the issue.
We believe the issue is due to the fact that the executor uses an instance of the setting, so modifying the setting class can sometimes invalidate the existing instances. The exact repro of this issue isn't 100% confirmed yet, and is something we still need to investigate further, but we can work around the issue for the time being.
See Warning: Known issue with device settings - instanced setting shenanigans - if you are modifying a device setting that is in use, or are actively making a device setting and executor at the same time, the executor(s) using the setting may get invalidated. Make sure to test any executors using your setting after making changes to it, to ensure they didn't get invalidated!
Make a new blueprint, that extends BP_DeviceSettingBase
In its SubMenuData
, inside the ButtonListData
, you can fill our its sub-menu with the data you want to show.
If you want the data to be filled in dynamically, you can either make a function to be called by the executor, (e.g. BP_DeviceSetting_ColorSelect::SetColorList
,) or you can populate the list in the InitializeOnClient
event (e.g. BP_DeviceSetting_WhoList
, which gets the options from the M2M_UserTagManager
at runtime).
A device setting also has the InfoWidgetData
field, which is what is found and displayed in the "info widget section" in WBP_DeviceControlsWidget
. If you want something in this section, add button data to this field.
You can then listen to the options in the setting being selected or the like to update the details in this info widget.