Timed Config

Description

Looking for a way to adjust and reload mod configs automatically at a certain time, for a custom game mode, map, or modpack? Look no further!

Timed Config (with some help from Configured, upon which this mod is dependent) will set and reload configs for any mod you specify, in any way you specify, at any time you specify. Just set up the Timed Config config (yeah, I know) with the values you want to change and when you want to change them, (and some supplemental info so Timed Config knows where to go) and you're good to go!

Works for both Singleplayer (Timed Config will edit any config file you tell it to) and Multiplayer (timed config will use the server-side configuration to edit the server's configs, clientside timed config is ignored). This hasn't been tested extensively, however, so please report any issues in the comments!

This mod is NOT GUARUNTEED to work for every mod. It only 'should' work for 1) mods that use forge created .toml configs that 2) don't require a game/world restart. Try editing the mods 'by hand' in the in game Configured GUI first and see what happens. If editing them manually gives you the desired effect without restarting anything, it 'should' work for Timed Config as well! Issue might arise, however, if target mods have config values with characters that throw off the parser (this is hit or miss, most should be fine). Working on fixing this.

Configuring Timed Config's config can be a little complex, as 'almost everything' has to be interpreted as a List of Strings and parsed out later. Below are some examples of how that might look in timedconfig-common.toml (Config values are repeated in the example to show you how they should look, in the actual file they are not repeated!)


["Configs for TimedConfig"]

#Number of Triggers that will cause a config change. Set to 0 to disable the mod. Requires 1 Trigger per timepoint per config value change, even if you want to change multiple values at the same time. Num Triggers should always equal the number items per list, and each list should have the same number of items. Default values illustrate 8 timepoints, with 4 defaults triggering at time 0 and 4 new values triggering at later timepoints: two at the same time, and two more at different times.
"Num Triggers" = 0 #Timed Config is off
"Num Triggers" = 2 #Timed Config is expecting all of your below lists to have 2 elements. 

#List of the Trigger Times (in ticks, 0 is when a server starts, 12000 is the first night, etc...) for each Trigger. Config files are overwritten at each Trigger and will NOT AUTOMATICALLY REVERT, so you should always include a default config values in a Trigger at time 0 if you want new worlds, etc... to start at default config values. Also, each unique trigger's information should be stored in the element corresponding to the SAME index across lists.
"Trigger Times" = [0, 24000] #For all of the remaining lists, the first element corresponds to tick 0, and the second element corresponds to tick 24000.

"Trigger Times" = [0, 24000, 0, 24000, 0, 48000] #This has 6 rather than 2 time triggers. 3 of the changes (element 1, 3, and 5) happen simultaneously, but must be encoded separately as three different values are changing. Same for element 2 and 4. 6 changes, but only 3 'moments' when configs change, at tick 0, 24000, and 48000. And again, if you were to use 6 time triggers, each list in this config needs to be 6 elements long!

#List of the target config files for each Trigger as they appear in the config directory. Only works for .toml configs!
"Trigger Config Files" = ["modconfigdir/modconfig.toml", "justthemodconfig.toml"] #first element is a config file inside of a directory (some mods do this, check the config folder after generating the world), second is if the config file sits without a directory in the config folder.

#List of the config path to be changed for each Trigger. Format should be whatever is in brackets at the top of the target section of the config file, then a period, then the targeted config variable.
"Trigger Config Paths" = ["section.key", "section can have spaces.key can have spaces"]

#Master List of the config value to set for each Trigger. Elements can be single values or lists themselves; however, the Master List MUST be a LIST of STRINGS, no matter what datatype you specify for each value below. If you're entering a single datatype for a given value, enclose it in double quotes, string or not (TimedConfig will parse based on the datatype you provide). If you're entering a list for a given value, enclose the list in double quotes but DO NOT leave double quotes WITHIN the list's elements, even if you're inputting a List<String>. See example below. Rule of thumb, there should be no more or no less than 2 double quotes for every element.
"Trigger Config Values Literal" = ["0.0", "1.0"] #Two elements of type Double
"Trigger Config Values Literal" = ["Hey You", "You're Finally Awake"] #Two elements of type String
"Trigger Config Values Literal" = ["[0.0, 1.0]", "[2.0, 3.0]"] #Two elements of type List<Double>
"Trigger Config Values Literal" = ["[Hey, You]", "[You're, Finally Awake]"] #Two elements of type List<String>

#List of the datatypes to interpret the literal of each config value to set for each Trigger. Supports the following (write as listed here): String, Boolean, Integer, Double, Long, List<String>, List<Boolean>, List<Integer>, List<Double>, and List<Long>.
"Trigger Config Values Datatype" = ["Double", "List<String>"] #some examples

#Message to send to the chat when each trigger condition is met. Set element as empty string to not send a message.
"Trigger Message" = ["Value Changed!", ""]  #first element sends a message, second does not.

What means Verified?

• Compatibility: The mod should be compatible with the latest version of Minecraft and be clearly labeled with its supported versions.
• Functionality: The mod should work as advertised and not cause any game-breaking bugs or crashes.
• Security: The mod should not contain any malicious code or attempts to steal personal information.
• Performance: The mod should not cause a significant decrease in the game's performance, such as by causing lag or reducing frame rates.
• Originality: The mod should be original and not a copy of someone else's work.
• Up-to-date: The mod should be regularly updated to fix bugs, improve performance, and maintain compatibility with the latest version of Minecraft.
• Support: The mod should have an active developer who provides support and troubleshooting assistance to users.
• License: The mod should be released under a clear and open source license that allows others to use, modify, and redistribute the code.
• Documentation: The mod should come with clear and detailed documentation on how to install and use it.

How to Install