The main aim of this PR is to allow regions to damage tools as part of their upkeep actions.
This allows for things like lumber yards to use an axe's durability slowly instead of it being an infinite reagant as currently is the case.
This should resolve #57
Implementation
Implementation follows the current approach for checking and changing region inputs and reagents so no new patterns to consider.
Design decisions made
What to do when a material is given in the tools section that has no durability (e.g. oak_log). Currently I have it so it is simply ignored as if it wasn't specified in the tools section and a warning is printed in the logs.
Improvements to consider
Currently the are tools not displayed very well in the civ region menu. Currently they occupy the same space as the reagents, meaning if a region has either reagents or tools then it will display the one it has. If the region has both reagants and tools, then it will only display the reagents, and the tools will not be visible. To correct this it will require a better shuffle of the region-type.yml menu than I have done in this PR.
Any enchantments on the tools have no effect on the durability or output of the task, as far as this plugin is considered it is a normal unenchanted tool which will break once all the durability is gone. It might be reasonably easy to account for the unbreaking enchantment but the other enchantments such as mending, silk touch, infinity raises questions as to how to handle these. I think this is a possible improvement for the future but would require a lot of thought as to how to handle all cases. This PR is an MVP for adding the ability to reduce tool durability and so accounting for enchantments is beyond this scope for now.
Arrow traps and similar don't actually use tool durability to function. This would require a rewrite of how org/redcastlemedia/multitallented/civs/regions/effects/ArrowTurret.java works. Possibly to do something along the lines of fire an arrow but don't actually take an arrow by default and instead trigger the upkeeps of that region? This would allow far more customisation of the region, e.g xp reward, money reward/cost, custom item costs for better arrow traps.
Other changes
I have changed any current regions that use tools as a reagant or input to instead have those tools in their new tools section, meaning they will now take damage rather than being either infinite or single use.
I have also reformatted a couple of the example yml regions to bring them inline with the norm of having # at the start of the line followed by the appropriate whitespace instead of whitespace then #. i.e. now reads # inputs: instead of #inputs:
Testing
I have tested this manually but haven't changed any of the automated tests which all still pass.
I have not tested these changes with any other plugins except vault and an economy plugin
Purpose:
The main aim of this PR is to allow regions to damage tools as part of their upkeep actions. This allows for things like lumber yards to use an axe's durability slowly instead of it being an infinite reagant as currently is the case.
This should resolve #57
Implementation
Implementation follows the current approach for checking and changing region inputs and reagents so no new patterns to consider.
Design decisions made
toolssection that has no durability (e.g.oak_log). Currently I have it so it is simply ignored as if it wasn't specified in the tools section and a warning is printed in the logs.Improvements to consider
region-type.ymlmenu than I have done in this PR.org/redcastlemedia/multitallented/civs/regions/effects/ArrowTurret.javaworks. Possibly to do something along the lines of fire an arrow but don't actually take an arrow by default and instead trigger the upkeeps of that region? This would allow far more customisation of the region, e.g xp reward, money reward/cost, custom item costs for better arrow traps.Other changes
I have changed any current regions that use tools as a reagant or input to instead have those tools in their new
toolssection, meaning they will now take damage rather than being either infinite or single use. I have also reformatted a couple of the example yml regions to bring them inline with the norm of having#at the start of the line followed by the appropriate whitespace instead of whitespace then#. i.e. now reads# inputs:instead of#inputs:Testing
I have tested this manually but haven't changed any of the automated tests which all still pass. I have not tested these changes with any other plugins except vault and an economy plugin