You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The feature of tipped/enchanted arrows is mentioned in ideas for new additions.txt; the features of utility arrows and arrow counter are also mentioned in #566. In the current implementation, only simple arrows with fixed damage and different material levels of bows are in the game. There are different trials and implementations of arrow hit limit mentioned in ideas for feature updates.txt by #19, #45, #50. Currently, arrows are always consumed when fired out, which may be unbalanced and decrease the usefulness of bows. The mentioned feature of arrow bundle in #545 would be useful in this system. Arrow counting in the inventory might be expensive as it is calculated and checked for each firing action, instead of only check if an arrow has successfully consumed.
Describe the solution you'd like
An arrow would only handle a certain amount (with a few random variation) of damage before consumed when fired out. Arrows would be returned if the arrow has not handled any damage (or a damage arrow would be returned instead), hit on a tile or no collision occurred within a maximum distance travelled.
The arrow bundle would be used and required (or simplify arrow counting mentioned instead of being necessary) when using a bow to fire an arrow. The arrow counting would also be done using the bundle (if available) for prioritized arrow selection.
We can have a dedicated workstation for (utility) arrows, costing some materials and the base arrows in making utility arrows. The utility arrows can have different abilities depending on the type of utility. For example, explosion, healing, poison, fire, strength, weakness, harming, slowness (or ice), can be used as the utilities. Some may consume potions and some may consume other materials. Probably enchanting or arrow grading could be used to enhance the strengths of the utilities.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The feature of tipped/enchanted arrows is mentioned in
ideas for new additions.txt
; the features of utility arrows and arrow counter are also mentioned in #566. In the current implementation, only simple arrows with fixed damage and different material levels of bows are in the game. There are different trials and implementations of arrow hit limit mentioned inideas for feature updates.txt
by #19, #45, #50. Currently, arrows are always consumed when fired out, which may be unbalanced and decrease the usefulness of bows. The mentioned feature of arrow bundle in #545 would be useful in this system. Arrow counting in the inventory might be expensive as it is calculated and checked for each firing action, instead of only check if an arrow has successfully consumed.Describe the solution you'd like
An arrow would only handle a certain amount (with a few random variation) of damage before consumed when fired out. Arrows would be returned if the arrow has not handled any damage (or a damage arrow would be returned instead), hit on a tile or no collision occurred within a maximum distance travelled.
The arrow bundle would be used and required (or simplify arrow counting mentioned instead of being necessary) when using a bow to fire an arrow. The arrow counting would also be done using the bundle (if available) for prioritized arrow selection.
We can have a dedicated workstation for (utility) arrows, costing some materials and the base arrows in making utility arrows. The utility arrows can have different abilities depending on the type of utility. For example, explosion, healing, poison, fire, strength, weakness, harming, slowness (or ice), can be used as the utilities. Some may consume potions and some may consume other materials. Probably enchanting or arrow grading could be used to enhance the strengths of the utilities.
The text was updated successfully, but these errors were encountered: