Research Categories are defined by a key (which is usually in uppercase,
although this is unenforced as I'm not sure if it needs to be enforced),
a parent research that must be completed (or a blank string which is
converted to null/null), a string reference to a resource location
(specific textures, i.e., "thaumcraft:textures/misc/vortex.png"), and
likewise for both background elements.
It is not a simple matter of merely using the API to load new research,
as the API specifically searches the file structure of the domain of the
resource location for a file matching the path. Attempts to use things
such as Resource Loader failed.
My solution was to partially re-implement the initial loading function,
and then use Reflection (with Methods cached) to access and call the
relevant functions for parsing the JSON into Research Entries, then then
to insert them into the relevant category.
With caching, and presuming that only a few dozen categories and entries
will be created, I don't believe that Reflection will add any
significant overhead to the loading process.
Research Categories and entries are specifically loaded through the
LATE_ADDITIONS in order to ensure that the Thaumcraft files are loaded
first. I didn't actually test to see what would happen if these
categories were inserted first, what impact it may have on the layout of
the Thaumonomicon, etc.
This was done in response to a request by DemoXin in #modtweaker and
because I thought it would be both an interesting challenge and
something that I may use in a modpack in the future. Hopefully the code
is up to snuff!
Please let me know of any issues.
Final note to this already long one: I feel there's currently no need for removing categories or, for that matter, entries, at least at this time.
Research Categories are defined by a key (which is usually in uppercase, although this is unenforced as I'm not sure if it needs to be enforced), a parent research that must be completed (or a blank string which is converted to null/null), a string reference to a resource location (specific textures, i.e., "thaumcraft:textures/misc/vortex.png"), and likewise for both background elements.
Example:
mods.thaumcraft.Research.addCategory("PERIPHERY", "UNLOCKAUROMANCY", "thaumcraft:textures/misc/vortex.png", "thaumcraft:textures/gui/gui_research_back_2.jpg", "thaumcraft:textures/gui/gui_research_back_over.png");
(Example shameless stolen from Periphery, the only Thaumcraft addon I had to hand and with which to reference).
Research Entries are defined by specifying the name of a JSON file the accords the relevant file in the
scripts
folder, following the syntax outlined at: https://github.com/Azanor/thaumcraft-api/blob/master/research/_example.json.txtExample:
mods.thaumcraft.Research.addResearch("myresearch.json");
It is not a simple matter of merely using the API to load new research, as the API specifically searches the file structure of the domain of the resource location for a file matching the path. Attempts to use things such as Resource Loader failed.
My solution was to partially re-implement the initial loading function, and then use Reflection (with Methods cached) to access and call the relevant functions for parsing the JSON into Research Entries, then then to insert them into the relevant category.
With caching, and presuming that only a few dozen categories and entries will be created, I don't believe that Reflection will add any significant overhead to the loading process.
Research Categories and entries are specifically loaded through the LATE_ADDITIONS in order to ensure that the Thaumcraft files are loaded first. I didn't actually test to see what would happen if these categories were inserted first, what impact it may have on the layout of the Thaumonomicon, etc.
This was done in response to a request by DemoXin in #modtweaker and because I thought it would be both an interesting challenge and something that I may use in a modpack in the future. Hopefully the code is up to snuff!
Please let me know of any issues.
Final note to this already long one: I feel there's currently no need for removing categories or, for that matter, entries, at least at this time.