Cross-mod Integration

No response

Feature Description

No response

Design Philosophy

Package Structure

Between gtceu/api, gtceu/common, and gtceu/data, each package must have a corresponding one in the other categories, majority exactly the same name.

• Example of Identical : api/machine, common/machine, data/machine
• Example of Similar (rarer) : api/pipenet, common/pipelike, data/pipelike

In order to ease the separation to make it more obvious, I have some ideas of what each folder type should contain relative to their purpose.

GTCEu/API Packages

• Interfaces and Default Implementation Types
• "What kind of datatypes are useful for devs?"
• Where all integrations and addon defaults should be in

GTCEu/Common Packages

• Metadata Categorization (Types of X in GregTech)
• "What kinds of datatypes are useful for devs that also appear as categories for players in-game?

GTCEu/Data Packages

• Registration Implementation
• "If I wanted to make a new X from some previous implementation, I would put it here"

As it stands, most packages/files are already following these guidelines, but some still need some refactoring to fit this scheme

Separation of GregTech, GregTech Addons, and Mod Integrations (including Forge).

I would like to see a system where GregTech packages are stored as they currently are, directly within 1st-level packages.
GregTech addons get special treatment over other integrations, and are included as their own folder located in api/addon (and others like Package Structure, if necessary).

• Note: At no point should GregTech code end up in addons, and instead should always be wrappers around the GregTech code, especially if we make changes to GregTech as we go, it makes it more robust.

Mod Integrations do not get such special treatment, and should be located in api/integration, with daughter folders corresponding to each mod they are integrated with, as well as a master java class to reference them all on startup.

• Note: Like GTAddons, at no point should GregTech code end up in addons, and instead should always be wrappers around the GregTech code, especially if we make changes to GregTech as we go, it makes it more robust.

As a final thought, all code relating to integrations/addons that are included in the default GregTech files should be relocated to the corresponding folders from above to meet the criterion of separation.

Removal of API/utils Package

This is entirely something that can be phased out, since there is no reason a "utils" folder/file should exist under a polishing. I seek to remove all of these features and included them in other packages in order to increase readability and reduce headache.

/API

api/addon

• Move events/KJSRecipeKeyEvent to more appropriate directory.
  • Likely to somewhere like api/integration
• Move events/MaterialCasingCollectionEvent to more appropriate directory.
  • Likely to somewhere like api/block
• Rename AddonFinder.java to GTAddonFinder.java
• Refactor GTAddonFinder.java/getInstances() for readability.

api/block

• Rename IAppearance to IAppearanceBlock for consistency.
• Rename IFilterType to ICleanroomFilterType or ICleanroomType for clarity.
• Depreciate IFusionCasingType
• Rename SimpleCoilType to DefaultCoilType for clarity (or implement other types).
• Rename MetaMachineBlock to `MachineBlock' for clarity.
• Find relationship between PipeBlock and MaterialPipeBlock.

api/blockentity

• Rename MetaMachineBlockEntity to MachineBlockEntity

api/capability

• A lot not listed here [TODO]

api/codecs

• What is this 1 file for?

api/compass

• Move relevant files into here.

api/cover

• Flatten cover/filter/ into cover/.
• Make all interfaces have prefix I.

api/fluid

• Rename attribute/FluidAttribute and attribute/FluidAttributes for clarity.
• Rename forge/GTFluidImpl to forge/GTFluidForge
• Move all of /attribute/ into api/fluid directory.
• Move all of /forge/ into api/fluid directory.
• Move all of /store/ into api/fluid directory.

api/gui

• Move all of /gui/compass into api/compass directory.
• A lot else not listed here [TODO]

api/item

• Rename MetaMachineItem to MachineItem
• So much else [TODO]

api/machine

• Thing

api/material

• Thing

api/misc

• Thing

api/multiblock

• Thing

api/pipenet

• Thing

api/recipe

• Thing

api/registry

• Thing

api/sound

• Thing

api/tag

• Thing

api/tools

• Thing

api/transfer

• Thing

api/worldgen

• Thing

api/GTCEuAPI.java

• Thing

api/GTValues.java

• Thing

api/RotationState.java

• Thing