Minecraft-Console-Client/MinecraftClient/Inventory/EnchantmentMapping.cs

338 lines
14 KiB
C#
Raw Normal View History

Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
using System;
2022-10-12 19:51:01 +02:00
using System.Collections.Generic;
using System.Linq;
2022-10-12 19:51:01 +02:00
using MinecraftClient.Protocol.Handlers;
using MinecraftClient.Protocol.Message;
2022-10-12 19:51:01 +02:00
namespace MinecraftClient.Inventory
{
public class EnchantmentMapping
{
#pragma warning disable format // @formatter:off
2022-10-12 19:51:01 +02:00
// 1.14 - 1.15.2
2024-09-11 19:12:31 +02:00
private static Dictionary<short, Enchantments> enchantmentMappings114 = new()
2022-10-12 19:51:01 +02:00
{
//id type
2024-09-11 19:12:31 +02:00
{ 0, Enchantments.Protection },
{ 1, Enchantments.FireProtection },
{ 2, Enchantments.FeatherFalling },
{ 3, Enchantments.BlastProtection },
{ 4, Enchantments.ProjectileProtection },
{ 5, Enchantments.Respiration },
{ 6, Enchantments.AquaAffinity },
{ 7, Enchantments.Thorns },
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
{ 8, Enchantments.DepthStrider },
2024-09-11 19:12:31 +02:00
{ 9, Enchantments.FrostWalker },
{ 10, Enchantments.BindingCurse },
{ 11, Enchantments.Sharpness },
{ 12, Enchantments.Smite },
{ 13, Enchantments.BaneOfArthropods },
{ 14, Enchantments.Knockback },
{ 15, Enchantments.FireAspect },
{ 16, Enchantments.Looting },
{ 17, Enchantments.Sweeping },
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
{ 18, Enchantments.Efficiency },
2024-09-11 19:12:31 +02:00
{ 19, Enchantments.SilkTouch },
{ 20, Enchantments.Unbreaking },
{ 21, Enchantments.Fortune },
{ 22, Enchantments.Power },
{ 23, Enchantments.Punch },
{ 24, Enchantments.Flame },
{ 25, Enchantments.Infinity },
{ 26, Enchantments.LuckOfTheSea },
{ 27, Enchantments.Lure },
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
{ 28, Enchantments.Loyalty },
2024-09-11 19:12:31 +02:00
{ 29, Enchantments.Impaling },
{ 30, Enchantments.Riptide },
{ 31, Enchantments.Channeling },
{ 32, Enchantments.Mending },
{ 33, Enchantments.VanishingCurse }
2022-10-12 19:51:01 +02:00
};
// 1.16 - 1.18
2024-09-11 19:12:31 +02:00
private static Dictionary<short, Enchantments> enchantmentMappings116 = new()
2022-10-12 19:51:01 +02:00
{
//id type
2024-09-11 19:12:31 +02:00
{ 0, Enchantments.Protection },
{ 1, Enchantments.FireProtection },
{ 2, Enchantments.FeatherFalling },
{ 3, Enchantments.BlastProtection },
{ 4, Enchantments.ProjectileProtection },
{ 5, Enchantments.Respiration },
{ 6, Enchantments.AquaAffinity },
{ 7, Enchantments.Thorns },
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
{ 8, Enchantments.DepthStrider },
2024-09-11 19:12:31 +02:00
{ 9, Enchantments.FrostWalker },
{ 10, Enchantments.BindingCurse },
{ 11, Enchantments.SoulSpeed },
{ 12, Enchantments.Sharpness },
{ 13, Enchantments.Smite },
{ 14, Enchantments.BaneOfArthropods },
{ 15, Enchantments.Knockback },
{ 16, Enchantments.FireAspect },
{ 17, Enchantments.Looting },
{ 18, Enchantments.Sweeping },
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
{ 19, Enchantments.Efficiency },
2024-09-11 19:12:31 +02:00
{ 20, Enchantments.SilkTouch },
{ 21, Enchantments.Unbreaking },
{ 22, Enchantments.Fortune },
{ 23, Enchantments.Power },
{ 24, Enchantments.Punch },
{ 25, Enchantments.Flame },
{ 26, Enchantments.Infinity },
{ 27, Enchantments.LuckOfTheSea },
{ 28, Enchantments.Lure },
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
{ 29, Enchantments.Loyalty },
2024-09-11 19:12:31 +02:00
{ 30, Enchantments.Impaling },
{ 31, Enchantments.Riptide },
{ 32, Enchantments.Channeling },
{ 33, Enchantments.Multishot },
{ 34, Enchantments.QuickCharge },
{ 35, Enchantments.Piercing },
{ 36, Enchantments.Mending },
{ 37, Enchantments.VanishingCurse }
2022-10-12 19:51:01 +02:00
};
2024-06-16 01:19:09 +02:00
// 1.19 - 1.20.4
2024-09-11 19:12:31 +02:00
private static Dictionary<short, Enchantments> enchantmentMappings119 = new()
{
//id type
2024-09-11 19:12:31 +02:00
{ 0, Enchantments.Protection },
{ 1, Enchantments.FireProtection },
{ 2, Enchantments.FeatherFalling },
{ 3, Enchantments.BlastProtection },
{ 4, Enchantments.ProjectileProtection },
{ 5, Enchantments.Respiration },
{ 6, Enchantments.AquaAffinity },
{ 7, Enchantments.Thorns },
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
{ 8, Enchantments.DepthStrider },
2024-09-11 19:12:31 +02:00
{ 9, Enchantments.FrostWalker },
{ 10, Enchantments.BindingCurse },
{ 11, Enchantments.SoulSpeed },
{ 12, Enchantments.SwiftSneak },
{ 13, Enchantments.Sharpness },
{ 14, Enchantments.Smite },
{ 15, Enchantments.BaneOfArthropods },
{ 16, Enchantments.Knockback },
{ 17, Enchantments.FireAspect },
{ 18, Enchantments.Looting },
{ 19, Enchantments.Sweeping },
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
{ 20, Enchantments.Efficiency },
2024-09-11 19:12:31 +02:00
{ 21, Enchantments.SilkTouch },
{ 22, Enchantments.Unbreaking },
{ 23, Enchantments.Fortune },
{ 24, Enchantments.Power },
{ 25, Enchantments.Punch },
{ 26, Enchantments.Flame },
{ 27, Enchantments.Infinity },
{ 28, Enchantments.LuckOfTheSea },
{ 29, Enchantments.Lure },
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
{ 30, Enchantments.Loyalty },
2024-09-11 19:12:31 +02:00
{ 31, Enchantments.Impaling },
{ 32, Enchantments.Riptide },
{ 33, Enchantments.Channeling },
{ 34, Enchantments.Multishot },
{ 35, Enchantments.QuickCharge },
{ 36, Enchantments.Piercing },
{ 37, Enchantments.Mending },
{ 38, Enchantments.VanishingCurse }
};
2024-06-16 01:19:09 +02:00
// 1.20.6+
2024-09-11 19:12:31 +02:00
private static Dictionary<short, Enchantments> enchantmentMappings = new()
2024-06-16 01:19:09 +02:00
{
//id type
2024-09-11 19:12:31 +02:00
{ 0, Enchantments.Protection },
{ 1, Enchantments.FireProtection },
{ 2, Enchantments.FeatherFalling },
{ 3, Enchantments.BlastProtection },
{ 4, Enchantments.ProjectileProtection },
{ 5, Enchantments.Respiration },
{ 6, Enchantments.AquaAffinity },
{ 7, Enchantments.Thorns },
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
{ 8, Enchantments.DepthStrider },
2024-09-11 19:12:31 +02:00
{ 9, Enchantments.FrostWalker },
{ 10, Enchantments.BindingCurse },
{ 11, Enchantments.SoulSpeed },
{ 12, Enchantments.SwiftSneak },
{ 13, Enchantments.Sharpness },
{ 14, Enchantments.Smite },
{ 15, Enchantments.BaneOfArthropods },
{ 16, Enchantments.Knockback },
{ 17, Enchantments.FireAspect },
{ 18, Enchantments.Looting },
{ 19, Enchantments.Sweeping },
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
{ 20, Enchantments.Efficiency },
2024-09-11 19:12:31 +02:00
{ 21, Enchantments.SilkTouch },
{ 22, Enchantments.Unbreaking },
{ 23, Enchantments.Fortune },
{ 24, Enchantments.Power },
{ 25, Enchantments.Punch },
{ 26, Enchantments.Flame },
{ 27, Enchantments.Infinity },
{ 28, Enchantments.LuckOfTheSea },
{ 29, Enchantments.Lure },
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
{ 30, Enchantments.Loyalty },
2024-09-11 19:12:31 +02:00
{ 31, Enchantments.Impaling },
{ 32, Enchantments.Riptide },
{ 33, Enchantments.Channeling },
{ 34, Enchantments.Multishot },
{ 35, Enchantments.QuickCharge },
{ 36, Enchantments.Piercing },
{ 37, Enchantments.Density },
{ 38, Enchantments.Breach },
{ 39, Enchantments.WindBurst },
{ 40, Enchantments.Mending },
{ 41, Enchantments.VanishingCurse }
2024-06-16 01:19:09 +02:00
};
#pragma warning restore format // @formatter:on
2022-10-12 19:51:01 +02:00
2024-09-11 19:12:31 +02:00
public static Enchantments GetEnchantmentById(int protocolVersion, short id)
2022-10-12 19:51:01 +02:00
{
if (protocolVersion < Protocol18Handler.MC_1_14_Version)
throw new Exception("Enchantments mappings are not implemented bellow 1.14");
2024-06-16 01:19:09 +02:00
var map = protocolVersion switch
{
>= Protocol18Handler.MC_1_14_Version and < Protocol18Handler.MC_1_16_Version => enchantmentMappings114,
>= Protocol18Handler.MC_1_16_Version and < Protocol18Handler.MC_1_19_Version => enchantmentMappings116,
2024-12-06 16:45:48 +01:00
>= Protocol18Handler.MC_1_19_Version and < Protocol18Handler.MC_1_21_Version => enchantmentMappings119,
2024-06-16 01:19:09 +02:00
_ => enchantmentMappings
};
2022-10-12 19:51:01 +02:00
2024-06-16 01:19:09 +02:00
if (!map.TryGetValue(id, out var value))
throw new Exception($"Got an Unknown Enchantment ID {id}, please update the Mappings!");
2022-10-12 19:51:01 +02:00
2024-06-16 01:19:09 +02:00
return value;
2022-10-12 19:51:01 +02:00
}
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
private static Dictionary<Enchantments, short>? reverseEnchantmentMappings;
private static Dictionary<int, Enchantments>? dynamicEnchantmentIdMap;
private static readonly Dictionary<string, Enchantments> nameToEnchantment = new()
{
{ "protection", Enchantments.Protection },
{ "fire_protection", Enchantments.FireProtection },
{ "feather_falling", Enchantments.FeatherFalling },
{ "blast_protection", Enchantments.BlastProtection },
{ "projectile_protection", Enchantments.ProjectileProtection },
{ "respiration", Enchantments.Respiration },
{ "aqua_affinity", Enchantments.AquaAffinity },
{ "thorns", Enchantments.Thorns },
{ "depth_strider", Enchantments.DepthStrider },
{ "frost_walker", Enchantments.FrostWalker },
{ "binding_curse", Enchantments.BindingCurse },
{ "soul_speed", Enchantments.SoulSpeed },
{ "swift_sneak", Enchantments.SwiftSneak },
{ "sharpness", Enchantments.Sharpness },
{ "smite", Enchantments.Smite },
{ "bane_of_arthropods", Enchantments.BaneOfArthropods },
{ "knockback", Enchantments.Knockback },
{ "fire_aspect", Enchantments.FireAspect },
{ "looting", Enchantments.Looting },
{ "sweeping_edge", Enchantments.Sweeping },
{ "efficiency", Enchantments.Efficiency },
{ "silk_touch", Enchantments.SilkTouch },
{ "unbreaking", Enchantments.Unbreaking },
{ "fortune", Enchantments.Fortune },
{ "power", Enchantments.Power },
{ "punch", Enchantments.Punch },
{ "flame", Enchantments.Flame },
{ "infinity", Enchantments.Infinity },
{ "luck_of_the_sea", Enchantments.LuckOfTheSea },
{ "lure", Enchantments.Lure },
{ "loyalty", Enchantments.Loyalty },
{ "impaling", Enchantments.Impaling },
{ "riptide", Enchantments.Riptide },
{ "channeling", Enchantments.Channeling },
{ "multishot", Enchantments.Multishot },
{ "quick_charge", Enchantments.QuickCharge },
{ "piercing", Enchantments.Piercing },
{ "density", Enchantments.Density },
{ "breach", Enchantments.Breach },
{ "wind_burst", Enchantments.WindBurst },
{ "mending", Enchantments.Mending },
{ "vanishing_curse", Enchantments.VanishingCurse },
};
/// <summary>
/// Set the dynamic enchantment ID map from server RegistryData.
/// Called during configuration phase when receiving minecraft:enchantment registry.
/// </summary>
public static void SetDynamicEnchantmentIdMap(Dictionary<int, string> idMap)
{
dynamicEnchantmentIdMap = new();
foreach (var kvp in idMap)
{
var name = kvp.Value.StartsWith("minecraft:") ? kvp.Value.Substring("minecraft:".Length) : kvp.Value;
if (nameToEnchantment.TryGetValue(name, out var enchantment))
dynamicEnchantmentIdMap[kvp.Key] = enchantment;
}
reverseEnchantmentMappings = null;
}
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
public static Enchantments GetEnchantmentByRegistryId1206(int id)
{
if (dynamicEnchantmentIdMap != null && dynamicEnchantmentIdMap.TryGetValue(id, out var dynValue))
return dynValue;
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
if (enchantmentMappings.TryGetValue((short)id, out var value))
return value;
return (Enchantments)(-1);
}
public static int GetRegistryId1206ByEnchantment(Enchantments enchantment)
{
if (reverseEnchantmentMappings == null)
{
reverseEnchantmentMappings = new();
if (dynamicEnchantmentIdMap != null)
{
foreach (var kvp in dynamicEnchantmentIdMap)
reverseEnchantmentMappings[kvp.Value] = (short)kvp.Key;
}
else
{
foreach (var kvp in enchantmentMappings)
reverseEnchantmentMappings[kvp.Value] = kvp.Key;
}
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
}
return reverseEnchantmentMappings.TryGetValue(enchantment, out var id) ? id : -1;
}
2024-09-11 19:12:31 +02:00
public static string GetEnchantmentName(Enchantments enchantment)
2022-10-12 19:51:01 +02:00
{
Fix enchantment name display for 1.20.6 structured components EnchantmentsComponent (used by both regular and stored enchantments) was directly casting the registry VarInt ID to the Enchantments enum via (Enchantments)id. However, the Enchantments enum is ordered alphabetically (AquaAffinity=0, BaneOfArthropods=1, ..., Sharpness=32) while the 1.20.6 registry uses a completely different order (protection=0, fire_protection=1, ..., sharpness=13). This caused all enchantment names to display incorrectly (e.g. Sharpness V shown as "Unknown Enchantment with ID: 32"). Changes: - Parse now uses EnchantmentMapping.GetEnchantmentByRegistryId1206() to properly map registry IDs to enum values via the existing 1.20.6+ mapping table - Serialize now uses EnchantmentMapping.GetRegistryId1206ByEnchantment() to convert enum values back to registry IDs (reverse lookup) - Fixed translation key prefix: "Enchantments.minecraft." (wrong) -> "enchantment.minecraft." (matches en_us.json resource keys) - Fixed 3 long-standing typos in the Enchantments enum that prevented translation lookup from matching resource keys: - DepthStrieder -> DepthStrider (depth_strieder vs depth_strider) - Efficency -> Efficiency (efficency vs efficiency) - Loyality -> Loyalty (loyality vs loyalty) Verified on vanilla 1.20.6 server: items with sharpness, efficiency, unbreaking, fortune, mending, and bane_of_arthropods all display correct localized names (锋利, 效率, 耐久, 时运, 经验修补, 节肢杀手). Made-with: Cursor
2026-03-19 02:01:15 +08:00
var translation = ChatParser.TranslateString("enchantment.minecraft." + enchantment.ToString().ToUnderscoreCase());
2024-06-16 01:19:09 +02:00
return string.IsNullOrEmpty(translation) ? $"Unknown Enchantment with ID: {(short)enchantment} (Probably not named in the code yet)" : translation;
2022-10-12 19:51:01 +02:00
}
public static string ConvertLevelToRomanNumbers(int num)
{
2024-06-16 01:19:09 +02:00
var result = string.Empty;
var romanNumbers = new Dictionary<string, int>
{
2024-06-16 01:19:09 +02:00
{"M", 1000},
{"CM", 900},
{"D", 500},
{"CD", 400},
{"C", 100},
{"XC", 90},
{"L", 50},
{"XL", 40},
{"X", 10},
{"IX", 9},
{"V", 5},
{"IV", 4},
{"I", 1}
};
foreach (var pair in romanNumbers)
{
result += string.Join(string.Empty, Enumerable.Repeat(pair.Key, num / pair.Value));
num %= pair.Value;
}
return result;
}
2022-10-12 19:51:01 +02:00
}
}