Difference between revisions of "Making Tools"

From Forge Community Wiki
m (Text replacement - "{{Colored box|title=Important|content=" to "{{Tip/Important|")
(Use tip template instead of colored box)
Line 25: Line 25:
  
 
{{Tip/Important|An ingredient should be wrapped in a supplier to avoid calling the object directly. Tiers are loaded before registries are populated, so the call to the item needs to be deferred.}}
 
{{Tip/Important|An ingredient should be wrapped in a supplier to avoid calling the object directly. Tiers are loaded before registries are populated, so the call to the item needs to be deferred.}}
 
  
 
== <tt>ToolItem</tt> ==
 
== <tt>ToolItem</tt> ==
Line 33: Line 32:
 
Each tool has four parameters: tier, attack damage, attack speed, and properties. Tiers and properties have already been explained in this and within the [[Making Items|item]] docs. Attack damage specifies how much damage to do above the current base set for that specific tier. Attack speed specifies the speed modifier to apply to your current attack speed (defaults to <code>4.0D</code>).  
 
Each tool has four parameters: tier, attack damage, attack speed, and properties. Tiers and properties have already been explained in this and within the [[Making Items|item]] docs. Attack damage specifies how much damage to do above the current base set for that specific tier. Attack speed specifies the speed modifier to apply to your current attack speed (defaults to <code>4.0D</code>).  
  
{{Colored box|title=Tip|content=If you decide to extend <code>ToolItem</code>, there will be a fifth parameter which defines which blocks this tool is effective on. This parameter can just be an empty set as that is now specified on each block itself.}}
+
{{Tip|content=If you decide to extend <code>ToolItem</code>, there will be a fifth parameter which defines which blocks this tool is effective on. This parameter can just be an empty set as that is now specified on each block itself.}}
 
 
  
 
== Registering ==
 
== Registering ==
Line 40: Line 38:
 
A tool must be [[Registration|registered]] the same as an item. If using one of the subtypes of <code>ToolItem</code>, that is all that is required. If not, you will need to chain <code>addToolType</code> onto your properties. This will take in a <code>ToolType</code> and a harvest level. The type is held within <code>ToolType</code> itself. The harvest level will be the value from your tier using <code>IItemTier#getHarvestLevel</code>.
 
A tool must be [[Registration|registered]] the same as an item. If using one of the subtypes of <code>ToolItem</code>, that is all that is required. If not, you will need to chain <code>addToolType</code> onto your properties. This will take in a <code>ToolType</code> and a harvest level. The type is held within <code>ToolType</code> itself. The harvest level will be the value from your tier using <code>IItemTier#getHarvestLevel</code>.
  
{{Colored box|title=Tip|content=If you would like to use a custom tool type, you can call <code>ToolType::get</code>. All strings passed in should have their modid appended to them to remove any conflict issues (e.g. <code>examplemod::custom_tool_type</code>). If a standard implementation across mods is used for compatibility, no namespace is needed.}}
+
{{Tip|content=If you would like to use a custom tool type, you can call <code>ToolType::get</code>. All strings passed in should have their modid appended to them to remove any conflict issues (e.g. <code>examplemod::custom_tool_type</code>). If a standard implementation across mods is used for compatibility, no namespace is needed.}}

Revision as of 09:42, 15 February 2021

Tools are simply an extension of the Item class. All of the logic is handled directly through one class with the others just being helpers to specify an exact tool type. Their implementations rely mainly on extending a specific class, it's properties, and the use of a tier system.

IItemTier

To create any tool that does not derive from vanilla tiers, you will need your own implementation of IItemTier. This is the basis of which all tool levels are created. If you would like to use a vanilla tier, then you should specify one of the enums within ItemTier.

Here are what each methods defines:

Method Return Type Description
getMaxUses Integer The durability of all items in this tier.
getEfficiency Float The efficiency multiplier of all items in this tier.
getAttackDamage Float The base attack damage of all items in this tier.
getHarvestLevel Integer The harvest level of this tier. Vanilla uses values 0-4.
getEnchantability Integer How enchantable an item of this tier is.
getRepairMaterial Ingredient What ingredient can be used to repair this item.

Important

An ingredient should be wrapped in a supplier to avoid calling the object directly. Tiers are loaded before registries are populated, so the call to the item needs to be deferred.

ToolItem

ToolItem is the base of which all tool items extend. You do not necessarily have to use this or any of its supertypes/subtypes. However, it is convenient if you are looking for standard behavior. The subtypes normally referenced are AxeItem, HoeItem, PickaxeItem, ShovelItem.

Each tool has four parameters: tier, attack damage, attack speed, and properties. Tiers and properties have already been explained in this and within the item docs. Attack damage specifies how much damage to do above the current base set for that specific tier. Attack speed specifies the speed modifier to apply to your current attack speed (defaults to 4.0D).

If you decide to extend ToolItem, there will be a fifth parameter which defines which blocks this tool is effective on. This parameter can just be an empty set as that is now specified on each block itself.

Registering

A tool must be registered the same as an item. If using one of the subtypes of ToolItem, that is all that is required. If not, you will need to chain addToolType onto your properties. This will take in a ToolType and a harvest level. The type is held within ToolType itself. The harvest level will be the value from your tier using IItemTier#getHarvestLevel.

If you would like to use a custom tool type, you can call ToolType::get. All strings passed in should have their modid appended to them to remove any conflict issues (e.g. examplemod::custom_tool_type). If a standard implementation across mods is used for compatibility, no namespace is needed.