feat(nms): 添加冒险模式物品组件支持，包括可破坏方块和可放置方块

[iiabc]

功能描述

为 NMSItemTag 添加冒险模式物品组件支持，包括可破坏方块 (can_break) 和可放置方块 (can_place_on) 的完整操作功能，并提供跨版本兼容性。

新增 API

• setItemCanBreak(ItemStack, List<String>) - 设置物品可破坏方块列表
• setItemCanPlaceOn(ItemStack, List<String>) - 设置物品可放置方块列表
• hasItemCanBreak(ItemStack) - 检查物品是否包含可破坏方块组件
• hasItemCanPlaceOn(ItemStack) - 检查物品是否包含可放置方块组件
• removeItemCanBreak(ItemStack) - 移除物品可破坏方块列表
• removeItemCanPlaceOn(ItemStack) - 移除物品可放置方块列表

版本兼容性实现

1.20.5+ 版本 (现代数据组件系统)

• 使用 DataComponents.CAN_BREAK 和 DataComponents.CAN_PLACE_ON
• 通过 AdventureModePredicate 和 CriterionConditionBlock 实现

1.20.4 及以下版本 (传统 NBT 系统)

• 使用传统 NBT 标签 CanDestroy 和 CanPlaceOn
• 通过 ItemTagList 存储方块名称列表

测试环境

• Minecraft 1.20.4 (Paper) - NBT 实现
• Minecraft 1.21.4 (Paper) - 数据组件实现
• Minecraft 1.21.8 (Paper) - 数据组件实现

Breaking Changes

无破坏性变更，所有新增方法均为可选功能，且保持向下兼容。

[Bkm016]

@claude

[claude]

Claude finished @Bkm016's task —— View job

---

Code Review: Adventure Mode Item Component Support

⚠️ Critical Issue: Missing PR Implementation

The adventure mode functionality described in PR #606 is not accessible in the current dev/6.2.3 branch. This likely indicates:

• The PR branch hasn't been merged yet
• The implementation is on a separate feature branch
• There may be a git workflow issue

✅ Architectural Assessment

Despite not being able to review the actual implementation, I've thoroughly analyzed the existing NMSItemTag foundation and can provide valuable architectural feedback:

🏗️ Excellent Foundation for Adventure Mode Features

The current NMSItemTag system demonstrates excellent architectural patterns that should support adventure mode features perfectly:

Strengths:

• ✅ Clean Version Abstraction: Proper separation of NBT vs DataComponent systems
• ✅ Consistent Cross-Version API: Same abstract interface implemented across all MC versions
• ✅ Robust Legacy Support: Reflection-based fallbacks for pre-1.20.5 versions
• ✅ Type Safety: Kotlin-friendly APIs with proper error handling
• ✅ Extension Function Pattern: Clean developer experience with ItemStack extensions

📋 Expected Implementation Analysis

Based on the PR description and existing patterns, the adventure mode APIs should follow this structure:

// Expected abstract methods in NMSItemTag:
abstract fun setItemCanBreak(itemStack: ItemStack, blocks: List<String>): ItemStack  
abstract fun setItemCanPlaceOn(itemStack: ItemStack, blocks: List<String>): ItemStack
abstract fun hasItemCanBreak(itemStack: ItemStack): Boolean
abstract fun hasItemCanPlaceOn(itemStack: ItemStack): Boolean  
abstract fun removeItemCanBreak(itemStack: ItemStack): ItemStack
abstract fun removeItemCanPlaceOn(itemStack: ItemStack): ItemStack

// Expected extension functions:
fun ItemStack.setCanBreak(blocks: List<String>): ItemStack
fun ItemStack.setCanPlaceOn(blocks: List<String>): ItemStack  
fun ItemStack.hasCanBreak(): Boolean
// ... etc

🔧 Version-Specific Implementation Expectations

Modern Versions (1.20.5+):

// Should use DataComponents.CAN_BREAK and DataComponents.CAN_PLACE_ON
val predicate = AdventureModePredicate.of(blockPredicates, showInTooltip = true)
nmsItem.set(DataComponents.CAN_BREAK, predicate)

Legacy Versions (≤1.20.4):

// Should use NBT tags "CanDestroy" and "CanPlaceOn"
val canDestroy = NBTTagList()
blocks.forEach { canDestroy.add(NBTTagString.valueOf(it)) }
nbtCompound.put("CanDestroy", canDestroy)

🔍 Code Quality Considerations

Positive Expectations:

1. API Consistency: Should follow existing getItemTag/setItemTag patterns
2. Error Handling: Should validate block names gracefully
3. Performance: Should minimize NMS object creation
4. Documentation: Clear KDoc for cross-version behavior differences

Potential Concerns:

1. Block Name Format: Different MC versions may require different block name formats
2. Tooltip Control: Adventure mode predicates support tooltip visibility - API should expose this
3. List vs Set: Should consider using Set for block lists to prevent duplicates
4. Null Safety: Should handle empty/null block lists appropriately

🚀 Recommendations for Review

When the actual PR implementation becomes available:

1. ✅ Verify Cross-Version Compatibility

   • Test block name resolution across all supported MC versions
   • Ensure NBT vs DataComponent parity

2. ✅ Check API Design Quality

   • Consistent with existing patterns
   • Proper extension function usage
   • Clear parameter validation

3. ✅ Review Error Handling

   • Invalid block names
   • Empty block lists
   • Unsupported MC versions

4. ✅ Performance Assessment

   • Minimal NMS object allocations
   • Efficient block name parsing
   • Proper caching where beneficial

5. ✅ Test Coverage

   • Unit tests for each version implementation
   • Integration tests with real ItemStacks
   • Edge case handling

📝 Final Assessment

The existing NMSItemTag architecture provides an excellent foundation for adventure mode features. The cross-version compatibility patterns are well-established and should make the implementation straightforward.

Recommendation: ✅ Approve architectural approach, pending review of actual implementation once PR branch is accessible.

---

Next Steps:

• Please ensure the PR branch is available for detailed code review
• Consider adding example usage in PR description
• Verify testing has been done across claimed MC versions (1.20.4, 1.21.4, 1.21.8)

---