[x] Graph:158 - Return a LinkedHashMap, that way iterating isn't as nearly as expensive.
[ ] DefaultGuiFactory - I need to finish the support for the config annotations with the default ConfigGuiSystem.
If I understand RuntimeOptionCategoryElement correctly, I need to check if it is called per mod, after clicking, if so, then I need to grab what mod is currently selected, pick which ConfigData is relevant to the mod, and then sort the different categories.
[x] ConfigData:42-44 - Clean up that...
[x] ConfigContainer:61 This is just utterly stupid. It works for the only 3 mods that use this system: (DP, TP, and this), but each time a mod uses this system the time will climb. I need to create a single instance of the map, but perform a deep clone on the map. This should save time.
[x] ConfigContainer:84 Clean up that.
[x] ConfigContainer or ConfigData.
The problem I have with the name is that ConfigData is the master class.
It handles all the config crap per mod. EG,
ConfigData
ConfigContainer
ConfigContainer
But as the names imply, ConfigContainer could be the master class.
ConfigContainer
ConfigData
ConfigData
This just makes sense, but ConfigData also makes sense.
(FYI, the top one is currently how it all works. ConfigData is the root. The master class for config data.)
Just that sentence in itself made it seem more fitting.
ConfigData CONTAINS all the config data, while the ConfigContainer, just seems to hold the data for further processing. Which is exactly how it works, so for the time being, I'm keeping it this way.
[x] Config:17 Comment is misleading. It doesn't generate the default config if given a custom config, it will generate the custom one.
[x] Config:26 This interface is fired before ANY annotations are read.
[x] package-info Fix this so it doesn't refer to external code, (CoreProperties won't be shipped with the API, so calling it would fail miserably...)
I'll edit this as I think of more things...
[ ] NetworkAPI - Really need to redo the messaging system. Something more integrated into the world. Instead of working on an abstract layer.
The problem I have with the name is that ConfigData is the master class.
It handles all the config crap per mod. EG,
But as the names imply, ConfigContainer could be the master class.
This just makes sense, but ConfigData also makes sense.
(FYI, the top one is currently how it all works. ConfigData is the root. The master class for config data.) Just that sentence in itself made it seem more fitting.
ConfigData CONTAINS all the config data, while the ConfigContainer, just seems to hold the data for further processing. Which is exactly how it works, so for the time being, I'm keeping it this way.
I'll edit this as I think of more things...