Request For Discussion/Planning MMDLib 2.0 move

MMDLib 2 Structure Proposal.md

MMDLib 2.0 for 1.14+ Design

Key Points

Simple Material System

Material system data is JSON

• Single language for the user across all MMDLib using mods
• Meta-entries for requirements
• Entries can point to classpaths

Simplified registration system

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

Code-wise interfacing

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...)

Design

Package and Namespaces

Top Level

com.mcmoddev.lib

Immediate Sub-packages

• 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

integration package

• 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

GUI package

• 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