Cross-mod Integration

No response

Feature Description

No response

Design Philosophy

Package Structure

GTCEu/api -> GTCEu Classes/Interfaces
GTCEu/client -> GTCEu Local Client Behavior
GTCEu/common -> GTCEu Types/Enums
GTCEu/data -> GTCEu Minecraft Declaration
GTCEu/addon -> GTCEu Addon-Exclusive Code
GTCEu/integration -> Non-GTCEu Mod Integration (with GTCEu)
GTCEu/mixins -> All Mixins (Maybe incorporate into ./integration)
GTCEu.java -> Main Mod Data
GTCEuInit.java -> Runs all the registry (commonproxy.java)
GTCEuConfig.java -> Config java file (instead of folder)

Ideal Content

API & Client are responsible for all interfaces and classes.

• Energy Handling, Machine Rendering, Things that should never be seen by minecraft players, especially back-end resources.
• "How stuff works"

Common is responsible for specialized classes that have direct analogs in-game.

• Coding analogs of minecraft-related items, such as types of machines.
• "How to abstract concepts of minecraft"

Data is responsible for registering all default GTCEu things that are seen directly in-game.

• Data like Multiblocks definitions, In-Game Machine Types, Items/Blocks, Element Types, Materials.
• "How to implement specifics into minecraft"

In the Integration and Addon folder, the only new material should be wrappers around API & Common code, as well as handling of code specifically handling Integrations and Addons.

To Be Blunt

At no point should any integration or addon should have redundant code as the main GTCEu stream, and instead should only be wrappers around the main code for best intractability and compatibility.

TODO List

GTCEu/api/

• Move addon/event/KJSRecipeKeyEvent to integration/kjs/KJSRecipeKeyEvent
• [ ]

Title 2

• [] Item