Core Modules

This group is not about how a shared API is designed. It is about how Croparia IF's core gameplay modules actually run in code.

If you already have a rough understanding of:

• Repo API
• Recipe API
• Network API

then this section is the better place to answer questions like:

• where the main entry class of a concrete module lives
• how the block, block entity, menu, screen, recipe, and networking pieces connect
• which layer you should touch first when changing behavior or adding compatibility

Covered modules

• Crop Transmuter
• a complete module with a block entity, menu, screen, and C2S interaction
• Greenhouse
• a module focused more on automated processing and storage
• Infusor
  • a typical "block state + dropped-item recipe" module
• Ritual Stand
  • a dropped-item-driven module that depends more heavily on structure validation and recipe matching
• FakePlayer
• an execution helper used by core modules for world interaction

Suggested reading order

• If you want to see how GUI, menus, and networking work together, start with Crop Transmuter
• If you want to see how dropped-item-driven recipe handling is built, start with Infusor and Ritual Stand
• If you want to see how block entities expose storage and automation, start with Greenhouse

Shared patterns across these modules

Even though these modules do very different things, they follow several consistent design habits:

• interaction entry points tend to stay on the block class
• persistent state tends to stay on the block entity
• shared capabilities are exposed through reusable APIs instead of being fused into one module
• complicated workflows are split into entry, state, matching, and output layers

So while reading these pages, the most useful thing to watch is usually not one method name, but:

• where each module draws its responsibility boundaries
• why it depends on one shared API
• which layer you should hook into when extending it