![]() |
tModLoader v2025.06
A mod to make and play Terraria mods
|
ModConfig provides a way for mods to be configurable. ModConfigs can either be Client specific or Server specific. When joining a MP server, Client configs are kept but Server configs are synced from the server. Using serialization attributes such as [DefaultValue(5)] or [JsonIgnore] are critical for proper usage of ModConfig. tModLoader also provides its own attributes such as ReloadRequiredAttribute and LabelAttribute. More...
Inherits ILocalizedModType.
Public Member Functions | |
virtual bool | AcceptClientChanges (ModConfig pendingConfig, int whoAmI, ref NetworkText message) |
Called on the Server for ServerSide configs to determine if the changes asked for by the Client will be accepted. Useful for enforcing permissions. Called after a check for NeedsReload. In advanced situations pendingConfig can be modified here and the changes will be applied and be synced. More... | |
virtual bool | AcceptClientChanges (ModConfig pendingConfig, int whoAmI, ref string message) |
virtual bool | Autoload (ref string name) |
virtual ModConfig | Clone () |
tModLoader will call Clone on ModConfig to facilitate proper implementation of the ModConfig user interface and detecting when a reload is required. Modders need to override this method if their config contains reference types. Failure to do so will lead to bugs. See ModConfigShowcaseDataTypes.Clone for examples and explanations. More... | |
virtual void | HandleAcceptClientChangesReply (bool success, int player, NetworkText message) |
Called on multiplayer clients after the server accepts or rejects ServerSide config changes made by a client. Can be used to update UI attempting to manually save changes to a ServerSide config (using SaveChanges(ModConfig, Action<string, Color>, bool, bool). For rejections this is only called on the client who requested the changes. player indicates which player requested the changes (see Main.myPlayer). success indicates if the changes were accepted and message is the corresponding message from AcceptClientChanges. | |
virtual bool | NeedsReload (ModConfig pendingConfig) |
Whether or not a reload is required. The default implementation compares properties and fields annotated with the ReloadRequiredAttribute. Unlike the other ModConfig hooks, this method is called on a clone of the ModConfig that was saved during mod loading. The pendingConfig has values that are about to take effect. Neither of these instances necessarily match the instance used in OnLoaded. More... | |
virtual void | OnChanged () |
This hook is called anytime new config values have been set and are ready to take effect. This will always be called right after OnLoaded and anytime new configuration values are ready to be used. The hook won't be called with values that violate NeedsReload. Use this hook to integrate with other code in your Mod to apply the effects of the configuration values. If your NeedsReload is correctly implemented, you should be able to apply the settings without error in this hook. Be aware that this hook can be called in-game and in the main menu, as well as in single player and multiplayer situations. | |
virtual void | OnLoaded () |
This method is called when the ModConfig has been loaded for the first time. This happens before regular Autoloading and Mod.Load. You can use this hook to assign a static reference to this instance for easy access. tModLoader will automatically assign (and later unload) this instance to a static field named Instance in the class prior to calling this method, if it exists. | |
void | Open (Action onClose=null, string scrollToOption=null, bool centerScrolledOption=true, bool playSound=true) |
Opens this config in the config UI. Can be used to allow your own UI to access the config. onClose can be used to run code after the config is closed, such as opening a modded UI or showing a message to the user. scrollToOption can be used to scroll to a specific member of the config and highlight it. It can also be used to scroll to the header above a member using the format "Header:{MemberNameHere}" . If the member has [SeparatePage] then the subpage will open automatically as well. Set centerScrolledOption to false if you'd like the config option to be at the top of the list when focused instead of at the center. More... | |
ConfigSaveResult | SaveChanges (ModConfig pendingConfig=null, Action< string, Color > status=null, bool silent=true, bool broadcast=true) |
Attempts to save changes made to this ModConfig. This must be called on the active ModConfig instance. If pendingConfig is provided, it will be used as the source for the changes to apply to the active config instance. If status is provided, it will be called with text and a color to indicate the status of the operation. If silent is false, sounds will play indicating success or failure. If broadcast is false, the chat message informing all players when a ServerSide config is changed saying "Shared config changed: Message: {0}, Mod: {1}, Config: {2}" will not appear on clients. Mod code can run this method in-game, but there are some considerations to keep in mind: Calling this method on a ConfigScope.ServerSide config from a multiplayer client will result in ConfigSaveResult.RequestSentToServer being returned and the actual save logic being performed on the server. HandleAcceptClientChangesReply(bool, int, NetworkText) will be called on all clients after the server accepts or denies the changes. Calling this method on the server for a ServerSide config is also supported. Attempting to save changes that would violate NeedsReload will fail and ConfigSaveResult.NeedsReload will be returned. If there is a chance that the changes won't be accepted, or if you want to provide a UI for the user to make changes without them taking effect immediately, you should use a clone of the ModConfig and pass it in as pendingConfig instead of modifying the active ModConfig directly. To make a clone, call the ConfigManager.GeneratePopulatedClone(ModConfig) method. See ExampleFullscreenUI.csfor a complete example of using this method. | |
Properties | |
virtual LocalizedText | DisplayName [get] |
string | FullName [get] |
=> $"{Mod.Name}/{Name}" More... | |
virtual string | LocalizationCategory [get] |
The category used by this modded content for use in localization keys. Localization keys follow the pattern of "Mods.{ModName}.{Category}.{ContentName}.{DataName}". The Localization wiki pageexplains how custom ModType classes can utilize this. More... | |
Mod | Mod [get, set] |
The mod this belongs to. More... | |
abstract ConfigScope | Mode [get] |
string | Name [get, set] |
The internal name of this instance. More... | |
![]() | |
abstract string | LocalizationCategory [get] |
The category used by this modded content for use in localization keys. Localization keys follow the pattern of "Mods.{ModName}.{Category}.{ContentName}.{DataName}". The Localization wiki pageexplains how custom ModType classes can utilize this. More... | |
![]() | |
string | FullName [get] |
=> $"{Mod.Name}/{Name}" More... | |
Mod | Mod [get] |
The mod this belongs to. More... | |
string | Name [get] |
The internal name of this instance. More... | |
ModConfig provides a way for mods to be configurable. ModConfigs can either be Client specific or Server specific. When joining a MP server, Client configs are kept but Server configs are synced from the server. Using serialization attributes such as [DefaultValue(5)] or [JsonIgnore] are critical for proper usage of ModConfig. tModLoader also provides its own attributes such as ReloadRequiredAttribute and LabelAttribute.
|
virtual |
Called on the Server for ServerSide configs to determine if the changes asked for by the Client will be accepted. Useful for enforcing permissions. Called after a check for NeedsReload.
In advanced situations pendingConfig can be modified here and the changes will be applied and be synced.
pendingConfig | An instance of the ModConfig with the attempted changes |
whoAmI | The client whoAmI |
message | A message that will be returned to the client, set this to the reason the server rejects the changes. |
|
virtual |
tModLoader will call Clone on ModConfig to facilitate proper implementation of the ModConfig user interface and detecting when a reload is required. Modders need to override this method if their config contains reference types. Failure to do so will lead to bugs. See ModConfigShowcaseDataTypes.Clone for examples and explanations.
|
virtual |
Whether or not a reload is required. The default implementation compares properties and fields annotated with the ReloadRequiredAttribute. Unlike the other ModConfig hooks, this method is called on a clone of the ModConfig that was saved during mod loading. The pendingConfig has values that are about to take effect. Neither of these instances necessarily match the instance used in OnLoaded.
pendingConfig | The other instance of ModConfig to compare against, it contains the values that are pending to take effect |
void ModConfig.Open | ( | Action | onClose = null , |
string | scrollToOption = null , |
||
bool | centerScrolledOption = true , |
||
bool | playSound = true |
||
) |
Opens this config in the config UI. Can be used to allow your own UI to access the config. onClose can be used to run code after the config is closed, such as opening a modded UI or showing a message to the user. scrollToOption can be used to scroll to a specific member of the config and highlight it. It can also be used to scroll to the header above a member using the format "Header:{MemberNameHere}"
. If the member has [SeparatePage]
then the subpage will open automatically as well. Set centerScrolledOption to false if you'd like the config option to be at the top of the list when focused instead of at the center.
onClose | A delegate that is called when the back button is pressed to allow for custom back button behavior. |
scrollToOption | The name of a field of the ModConfig to scroll to. |
centerScrolledOption | |
playSound | Whether SoundID.MenuOpen will be played when the UI is opened. |
|
get |
=> $"{Mod.Name}/{Name}"
Implements IModType.
|
get |
The category used by this modded content for use in localization keys. Localization keys follow the pattern of "Mods.{ModName}.{Category}.{ContentName}.{DataName}". The Localization wiki pageexplains how custom ModType classes can utilize this.
Implements ILocalizedModType.
|
getset |
The internal name of this instance.
Implements IModType.