From @srs-bsns on March 26, 2016 11:4

• Figure out everything that needs to be done to implement GUI configs.
• Figure out if anything needs to be done in the GUI classes that would pertain to world-specific configs. (Point of discussion; Plan for future)
• Make a list of, and check, all config settings for ones that would require Minecraft to be restarted. (Probably not many, if any)
• Check list of configs settings/sections for ones that can be omitted from the GUI. (ie. debugging and unimplemented volcano settings)
• Figure out how best to implement the mod-specific configs (In their own GUI section, showing only mods that are loaded?)
• Localise all text and button names using en_US.lang as fall-back if the current language doesn't have a localisation file.
• Decide if certain settings would be better off with sliders with sane min/max values (ie. I:"Maximum distance between villages")
• Decide if this should be backported to 1.7.10
• have some 🍕 and 🍺

Copied from original issue: Team-RTG/1.9-Realistic-Terrain-Generation#22

From @topisani on April 26, 2016 6:27

that prefix annoyed me

anyway, the new config system takes care of everything. Making a GUI for it should be extremely simple. still on it srs? or should i do a quick implementation

Are the biome configs going to included in this?

I remember Zeno mentioning something about having manually 'reset' some or all of the static variables RTG's using to prevent settings getting carried across worlds unintentionally, but I think you might have that covered already in the 'require Minecraft to be restarted' task.

Re: backporting to 1.7... obviously this would be great to have in 1.7, but if there's a lot of work involved, I think it would be fine to keep it a 1.9-only feature.

From @srs-bsns on March 26, 2016 12:33

Are the biome configs going to included in this?
I remember Zeno mentioning something about having manually 'reset' some or all of the static variables RTG's using to prevent settings getting carried across worlds unintentionally, but I think you might have that covered already in the 'require Minecraft to be restarted' task.

I hope to be able to add them, if possible, but we still need some discussion on how best to implement some form of persistence for config settings on a per-world basis to prevent changes from possibly damaging worlds that have already been created. I've already got it covered for the situation where one might try to alter settings in a running world.. just disable the config GUI in the main Config GUI Factory. (Or possibly even disabling the config button itself if the server is running.)

Re: backporting to 1.7... obviously this would be great to have in 1.7, but if there's a lot of work involved, I think it would be fine to keep it a 1.9-only feature.

I don't think there will be a great deal of work involved, but there will be some as 1.9 is moving towards getter/setter and making data fields private, but it's not really going to be a lot of code, so it shouldn't be a problem. My context was less of "Can it be done?" than "Do we want it?" If we want it, then it will be done. 😄

Closing this issue in 1.7.10, so just dropping it here for reference as it contains some links that might come in handy.

#589