Item meta pointing range

[cx384]

Goal of this PR

• Resolves Add per-ItemStack point range #10164
• The author of this issue already made a PR, but it got closed due to inactivity, I think. Add ability to override item's point-range using meta #13566
  (The PR got a Concept approved label, but the issue not.)
• So this PR is a new try to solve it.

How does it work

It uses the item meta key range to determine the pointing range.

To do

This PR Ready for Review.

How to test

Start devtest, and left click with the testitems:telescope_stick to try out different ranges.

[Zughy]

@cx384 rebase needed

[cx384]

Rebase done.

[appgurueu]

Thanks for the PR. The telescope stick works as expected, the code looks good, I only have minor points.

Regarding your note, I think that it would most probably be cleaner to pass the item def manager. There is no performance concern here. That would allow us to get rid of one parameter. The call site would also be more readable: getToolRange(selected_item.getDefinition(m_itemdef), hand_item.getDefinition(m_itemdef), selected_item, hand_item) would simplify to getToolRange(m_itemdef, hand_item, selected_item).

[cx384]

I applied your suggestions.

Regarding your note, I think that it would most probably be cleaner to pass the item def manager. There is no performance concern here.

Now it gets an item def manager and processPlayerInteraction calls selected_item.getDefinition multiple times. If I'm not wrong, it is just a lookup in a red black tree. So as you said, no performance concerns.

All fields stored in MetaDataRef are just strings, so it doesn't matter how they are set, but I changed it for clarification.

[appgurueu]

All fields stored in MetaDataRef are just strings, so it doesn't matter how they are set, but I changed it for clarification.

Indeed, in practice this isn't an issue. FYI there are some ugly details though (for example, your set_string call was relying on number -> string coercion, which in turn was relying on tostring to properly format a float, which in practice only works because we force the C locale for number formatting) so I think using set_float / get_float and letting the engine handle the formatting is the cleanest option here.

[sfan5]

lgtm otherwise

[cx384]

Thanks for the review, I fixed everything and rebased.