Material system data is JSON
- Single language for the user across all MMDLib using mods
- Meta-entries for requirements
- Entries can point to classpaths
Registration via IMC
- No need for anything even close to core-mods or annotation lookups
- Simple callback system like JEI uses can cover a lot
- Potentially allows for phased callbacks
- "Has to happen after all other registrations" or other similar timing
- "Must happen before material loading"
- Many more bits possible
- Item Types and Classes done here as well
- If wanted/needed MMDLib can shift around mod container stuff to put items and blocks in the correct resource domains
Static Interfaces
- UI containers and widgets get static interfaces for registering
- Materials, Items and Blocks get static interfaces for registering in-code, if needed
- Capabilities get static registration/query interfaces
- Same for all other features (entities, recipes, etc...)
com.mcmoddev.lib
- Material
- wrapper for generic "material" classes that provide a basis for the entire system
- Interface should be simple but largely complete
- Potentially only a single class, but allows for multiple to cover extras needed for various other features
- Capability
- Any basic capabilities provided by MMDLib go here
- Energy (@FaceOfKat has provided a very nice system for MMDLib 1.x that we can port)
- Fluid
- Entity
- With the Energy system that exists in MMDLib 1.x we have a basic TE system that can do furnaces already...
- A basic "mob" system would not be amiss here
- Also wrappers for Arrows/Bolts as needed
- Command
- Wrapper around the new, vanilla command system to provide some uniformity
- GUI
- Currently spread among several top-level packages
- Wrapper top-level to add some logical separation
- Block
- Same as current (largely - some merging/removal of custom classes is likely)
- Item
- Same as current (largely - some merging/removal of custom classes is likely)
- Recipe
- Same as current (largely - some merging/removal of custom classes is likely)
- Registry
- Same as current (largely - some merging/removal of custom classes is likely)
- integration
- Complex - matches, somewhat, the existing system but needs extension and expansion to cover a more complete interface set per mod
- Should get the Waila/Hwyla/Top/JEI integration as well
mods
- Contains base code for integrating with various mods, such as Tinkers' Construct, IC2 and EnderIO
- These should be largely static classes, possibly
final
at this point as well
waila
/information
- All WAILA/HWYLA integration code
- If
information
or similar chosen, all integrations with "information provision" mods like JEI, WAILA and TOP
jei
- Self explanatory
- Possibly merged to a sub-package of
information
if such is the chosen route
top
- Self explanatory
- Possibly merged to a sub-package of
information
if such is the chosen route
crafttweaker
- In Depth integration with CraftTweaker - far more than the Crusher Registry
- Home for all GUI bits - largely already exists as
com.mcmoddev.lib.container
- Retain current naming ?
"Potentially allows for phased callbacks" - Consider something along the lines of a dictionary of delegates (or java equivalent) with an integer column of priority order, it would then put the power in the hands of the developer to be more flexible with the sequence stuff gets called in, or if end developers are likely to cause chaos with that just do that internally for flexibility and externally expose an enumeration like 1 to 5 priority