Conversation
|
No actionable comments were generated in the recent review. 🎉 📝 WalkthroughWalkthroughRemoves seven log block declarations and their tag/model/creative registrations; adds many ore block declarations; introduces a REGISTERED_BLOCKS collection and helper registration methods to populate the creative tab via ModBlocks.initialize. Changes
Sequence Diagram(s)sequenceDiagram
participant ModBlocks as ModBlocks (code)
participant Registry as Game Registry
participant Registered as REGISTERED_BLOCKS (list)
participant Creative as ModCreativeTab
ModBlocks->>Registry: register(name, Block, optionally Item)
Registry-->>ModBlocks: registration result
ModBlocks->>Registered: add(block reference)
ModBlocks->>Creative: initialize(MINETALE_CREATIVE_TAB_KEY)
Creative->>Registered: iterate registered blocks
Registered-->>Creative: provide block entries
Creative->>Registry: add blocks/items to creative tab group
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Note Docstrings generation - SUCCESS |
Docstrings generation was requested by @The-Code-Monkey. * #46 (comment) The following files were modified: * `src/client/java/com/tcm/MineTale/datagen/ModModelProvider.java`
…0b52b7 📝 Add docstrings to `feat/add-items`
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
Docstrings generation was requested by @The-Code-Monkey. * #46 (comment) The following files were modified: * `src/main/java/com/tcm/MineTale/registry/ModBlocks.java`
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/client/java/com/tcm/MineTale/datagen/ModModelProvider.java (1)
42-69:⚠️ Potential issue | 🟠 MajorAdd model/blockstate generation for all 48 ore blocks.
The ore blocks (COPPER, ONYXIUM, THORIUM, ADAMANTITE, MITHRIL, COBALT, IRON, GOLD, SILVER variants across different base rocks) have no corresponding
generateBlockStateModelsentries. Without blockstate and model definitions, these blocks will render as missing-texture purple/black cubes in-game.Use
blockStateModelGenerator.createTrivialCube(ModBlocks.COPPER_ORE_BASALT)(or similar) for each ore block, or create a helper loop to iterate over the ore block constants to reduce verbosity.
🤖 Fix all issues with AI agents
In `@src/main/java/com/tcm/MineTale/registry/ModBlocks.java`:
- Around line 166-221: The commented-out blocks for sections 10–17 use
copy-pasted THORIUM identifiers; update each commented declaration so the Java
variable names and registry string IDs reflect the correct mineral (e.g.,
replace THORIUM_ORE_BASALT and "thorium_ore_basalt" with PRISMA_ORE_BASALT and
"prisma_ore_basalt" for section 10) and do the same for SAPPHIRE, TOPAZ, ZEPHYR,
DIAMOND, VOIDSTONE, and EMERALD; specifically edit the commented lines that call
registerOreBlock (look for occurrences of THORIUM_ORE_*, "thorium_ore_*", and
similar copy-pastes) to use the matching mineral constant names (e.g.,
PRISMA_ORE_BASALT, SAPPHIRE_ORE_STONE, TOPAZ_ORE_SANDSTONE, etc.) and their
corresponding lowercase registry IDs (e.g., "prisma_ore_basalt",
"sapphire_ore_stone"), leaving block properties and other arguments unchanged.
- Around line 260-273: The registerOreBlock method currently ignores baseBlock,
itemToDrop, and count; either remove these unused parameters or wire them into
block drop logic—update registerOreBlock (and callers) to either (A) simplify
the signature by removing baseBlock, itemToDrop, and count and stop re-calling
requiresCorrectToolForDrops(), or (B) implement custom drop behavior by
creating/using a Block subclass or loot table that drops itemToDrop with
quantity count (e.g., register an OreBlockWithCustomDrops that overrides
getDrops or register a loot table via a LootTableProvider keyed to blockKey),
ensure the BlockItem registration and REGISTERED_BLOCKS behavior stays the same,
and remove the redundant requiresCorrectToolForDrops() call if the callers
already set it.
🧹 Nitpick comments (1)
src/main/java/com/tcm/MineTale/registry/ModBlocks.java (1)
101-179: All ore blocks share identical properties — is this intentional?Every ore type (copper through silver) uses
strength(2)andItems.COPPER_OREas the drop placeholder. For a mod with distinct ore tiers, you'd typically expect:
- Different hardness/blast resistance per tier (e.g., adamantite harder than copper)
- Different drop items per ore type (even though
itemToDropis currently unused)If this is placeholder code to be fleshed out later, consider adding a
// TODOto make that explicit.
| private static Block registerOreBlock(String name, Function<BlockBehaviour.Properties, Block> blockFactory, BlockBehaviour.Properties settings, Block baseBlock, Item itemToDrop, int count) { | ||
| ResourceKey<Block> blockKey = keyOfBlock(name); | ||
|
|
||
| Block block = blockFactory.apply(settings.requiresCorrectToolForDrops().setId(blockKey)); | ||
|
|
||
| ResourceKey<Item> itemKey = keyOfItem(name); | ||
|
|
||
| BlockItem blockItem = new BlockItem(block, new Item.Properties().setId(itemKey).useBlockDescriptionPrefix()); | ||
| Registry.register(BuiltInRegistries.ITEM, itemKey, blockItem); | ||
|
|
||
| REGISTERED_BLOCKS.add(block); | ||
|
|
||
| return Registry.register(BuiltInRegistries.BLOCK, blockKey, block); | ||
| } |
There was a problem hiding this comment.
baseBlock, itemToDrop, and count parameters are accepted but never used.
These parameters appear intended to configure ore drops (e.g., copper ore dropping copper items), but the method body ignores them entirely. As a result, every ore block will use default drop behavior (dropping itself) rather than the intended item. This is likely a functional bug — if these ores are meant to drop specific items, the loot table or drop logic needs to be wired up.
Additionally, .requiresCorrectToolForDrops() is called on line 263 inside registerOreBlock, but every caller already includes it in the BlockBehaviour.Properties chain (e.g., line 102). The duplicate call is harmless but redundant.
Proposed cleanup (remove unused params or implement drop logic)
If drops should just be the block itself, simplify the signature:
- private static Block registerOreBlock(String name, Function<BlockBehaviour.Properties, Block> blockFactory, BlockBehaviour.Properties settings, Block baseBlock, Item itemToDrop, int count) {
+ private static Block registerOreBlock(String name, Function<BlockBehaviour.Properties, Block> blockFactory, BlockBehaviour.Properties settings) {
ResourceKey<Block> blockKey = keyOfBlock(name);
- Block block = blockFactory.apply(settings.requiresCorrectToolForDrops().setId(blockKey));
+ Block block = blockFactory.apply(settings.setId(blockKey));Otherwise, if custom drops are intended, the parameters need to be wired to a loot table provider or a custom Block subclass that overrides drop behavior.
🤖 Prompt for AI Agents
In `@src/main/java/com/tcm/MineTale/registry/ModBlocks.java` around lines 260 -
273, The registerOreBlock method currently ignores baseBlock, itemToDrop, and
count; either remove these unused parameters or wire them into block drop
logic—update registerOreBlock (and callers) to either (A) simplify the signature
by removing baseBlock, itemToDrop, and count and stop re-calling
requiresCorrectToolForDrops(), or (B) implement custom drop behavior by
creating/using a Block subclass or loot table that drops itemToDrop with
quantity count (e.g., register an OreBlockWithCustomDrops that overrides
getDrops or register a loot table via a LootTableProvider keyed to blockKey),
ensure the BlockItem registration and REGISTERED_BLOCKS behavior stays the same,
and remove the redundant requiresCorrectToolForDrops() call if the callers
already set it.
…187d5d 📝 Add docstrings to `feat/add-items`
Removed the steel ingot item and added new ore items.
1 participant
Summary by CodeRabbit
New Features
Changes
UI