[1.15.2] Advice needed on selecting Map<K, V> implementation

[TheThorneCorporation]

Heya,

 

So, I have a class of tool called DrillItem, and I want to add a feature called "ore depletion." It's like stripping wood, except it's for ores. Depleting an ore spawns that ore's specific ItemStack at the player and replaces the ore with the next less depleted form. For example, if I right-clicked with a Diamond Drill on Coal Ore, it would turn into Depleted Coal Ore and give me 1 coal. If I right-clicked on the Depleted Coal Ore, it would turn to Twice Depleted Coal Ore and give me 1 more coal. If I right-clicked on the Twice Depleted Coal Ore, it would turn to Thrice Depleted Coal Ore and give me 1 more coal. If I right-clicked on the Thrice Depleted Coal Ore one final time, it would turn to stone and give me 1 more coal.

 

I want to use an implementation of Map<Block, Block> to control what each ore turns into when depleted, and a Map<Block, Supplier<ItemStack>> to determine what ItemStack comes out. I copied code from the AxeItem class's stripping map to create these maps. However, I am adding a static method registerDepletableOre that would allow other modders to add their ores to the system, and I want the maps to be mutable to that end. The Builder method of creating the map, which I am using now, doesn't do the trick for me. What other mutable implementations of Map should I use to make my map mutable?

[ChampionAsh5357]

Just use diamond syntax on any mutable map constructor (e.g. HashMap). Also, with your current system, you should wrap the Block instances in a lazy supplier so that blocks that you can correctly call the instance when first accessed instead of returning null.

[Draco18s]

That sounds very similar to what I did. My implementation is just "you mine the block" and not a special tool.

I handled the variants as a variant value (the silk-touch and block item issue I dealt with using a custom loot table function).

 

https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/block/ore/HardOreBlock.java

 

I don't necessarily think this was a great solution, but it made more sense to leave the "density" as a query-able block property (for several reasons) rather than separate blocks.

[TheGreyGhost]

Howdy

As per the earlier posts I'd suggest you just use a HashMap without a builder.

Longer term I think it would be a good idea to have your stripping information as a loot table (or possibly a custom recipe type if the loot table becomes unwieldy) so that it can be customised by folks in data packs, no coding required.

 

-TGG