Issues with "range" on melee weapons

[Rarst]

Melee weapons in equipment currently say "range": { "normal": 5 }, which is iffy in some regards:

1. Technically melee weapons don't have range (unless they also have thrown), they are specifically not ranged.
2. The numerical data currently doesn't reflect Reach property.

My first thought was to bump this by 5ft on Reach weapons, but after a closer look range isn't accurate at all. For the record there is also a separate throw_range property for thrown.

As far as I can see, the default reach is a rule, not an aspect of any specific weapon:

A melee weapon is used to attack a target within 5 feet of you

So rules-wise this is strictly binary (does weapon have Reach property), not numeric (weapon has X feet reach).

[bagelbits]

@Rarst I think that makes sense and cleans up the data some. Especially if we already have throw_range. And Reach weapons don't have variable reach either. It is a binary state.

[Rarst]

I think that makes sense and cleans up the data some.

That what, precisely? :) I am not sure what's the specific desired change here.

[fergcb]

I think your first thought was a good one. It's useful for users building VTTs, simulators, etc. to know the range of a weapon, whether or not the weapon is a ranged weapon, without having to look at other attributes (e.g. its category, whether it has the Reach property).

Melee weapons still have a range, even though they aren't ranged weapons.

I think it makes sense to keep range on all weapons, bump it by 5 feet for reach weapons, and leave throw_range as-is.

[Rarst]

Melee weapons still have a range, even though they aren't ranged weapons.

No, the rules do not support this. Melee weapon, without thrown property, does not have a range, as defined by the rules.

Range. A weapon that can be used to make a ranged attack has a range in parentheses after the ammunition or thrown property.

So up for discussion:

1. Does it makes sense to have a derived numeric value for a weapon's effective reach (I do see the argument that it can be useful)
2. What is the appropriate structure for that data, if so, because while range can make colloquial sense, it goes against technical wording of the rules

[fergcb]

Forgive me, I was using "range" as a synonym for "reach" here. Just casual English, not rigid rules-based semantics.

To answer the points listed, (1) yes I believe there should be a "derived numeric value" for a weapon's reach; and (2) no, I don't think it adds value to sacrifice the clarity of using "range" to mean the "reach" of a weapon for the sake of being faithful to the wording in the rules, but I think simply renaming the "range" attribute for all weapons to "reach" would be a suitable compromise.

The key thing to avoid, I think, is creating too much disparity between the data structure of melee and ranged weapons.

[Rarst]

To recap a bit, currently there are three cases in data:

1. melee weapon with range
2. melee thrown weapon with range and throw_range
3. ranged weapon with range

Worth noting that, as quote above, there is no separate "thrown range" concept in rules. Weapon is given Range by being inherently ranged or by having thrown property.

I think, to the strict language of rules, these would be:

1. melee weapon with reach
2. melee thrown weapon with reach and range
3. ranged weapon with range

There is also "weapon_range": "Melee" in data, which has same issue with being reasonable colloquial usage, but against the technical language of rules.

[fergcb]

I think, to the strict language of rules, these would be:

1. melee weapon with reach
2. melee thrown weapon with reach and range
3. ranged weapon with range

I think this would be a suitable compromise.

[bagelbits]

There is also "weapon_range": "Melee" in data, which has same issue with being reasonable colloquial usage, but against the technical language of rules.

I think if we use reach and range, the need of that field goes away?

[Rarst]

I think if we use reach and range, the need of that field goes away?

I think that's less of a rules question and more of API design question - how much of things that can be mechanically derived should still be expressed in API for frequent and convenient use.

Feels like explicit melee/ranged distinction is still worth having, though weapon_range property name rubs me the wrong way (for above reasons of melee weapons not having Range property in technical sense).

[bagelbits]

@Rarst Oh! I see what you mean. Since we actually look at all three of these fields:

    "weapon_category": "Martial",
    "weapon_range": "Melee",
    "category_range": "Martial Melee",

Which is a way to set the category. However, this is also redundant since it's setup in EquipmentCategory.

I wonder if it makes more sense to swap equipment_category for equipment_categories. Which would give us this as an example:

{
  "index": "trident",
  "name": "Trident",
  "equipment_categories": [{
    "index": "weapon",
    "name": "Weapon",
    "url": "/api/equipment-categories/weapon"
  }, {
    "index": "martial-melee-weapons",
    "name": "Martial Melee Weapons",
    "url": "/api/equipment-categories/martial-melee-weapons"
  }, {
    "index": "martial-weapons",
    "name": "Martial Weapons",
    "url": "/api/equipment-categories/martial-weapons"
  }, {
    "index": "melee-weapons",
    "name": "Melee Weapons",
    "url": "/api/equipment-categories/melee-weapons"
  }],
  "cost": {
    "quantity": 5,
    "unit": "gp"
  },
  "damage": {
    "damage_dice": "1d6",
    "damage_type": {
      "index": "slashing",
      "name": "Slashing",
      "url": "/api/damage-types/slashing"
    }
  },
  "reach": false,
  "weight": 4,
  "properties": [
    {
      "index": "thrown",
      "name": "Thrown",
      "url": "/api/weapon-properties/thrown"
    },
    {
      "index": "versatile",
      "name": "Versatile",
      "url": "/api/weapon-properties/versatile"
    }
  ],
  "throw_range": {
    "normal": 20,
    "long": 60
  },
  "two_handed_damage": {
    "damage_dice": "1d8",
    "damage_type": {
      "index": "piercing",
      "name": "Piercing",
      "url": "/api/damage-types/piercing"
    }
  },
  "url": "/api/equipment/trident"
}

[bagelbits]

This would also let us free up some other fields like armor_category.

[Rarst]

No strong opinion on equipment categories, since these are more about API than adhering to rules.

Notes on the latest example:

1. Not having Reach in "properties" feels inconsistent, since it is one.
2. As above I am iffy on "throw_range" since there is no such thing in rules, it's just range (the source of it might be ranged or thrown).

[bagelbits]

Oh right. We were just renaming that to range?

{
  "index": "trident",
  "name": "Trident",
  "equipment_categories": [{
    "index": "weapon",
    "name": "Weapon",
    "url": "/api/equipment-categories/weapon"
  }, {
    "index": "martial-melee-weapons",
    "name": "Martial Melee Weapons",
    "url": "/api/equipment-categories/martial-melee-weapons"
  }, {
    "index": "martial-weapons",
    "name": "Martial Weapons",
    "url": "/api/equipment-categories/martial-weapons"
  }, {
    "index": "melee-weapons",
    "name": "Melee Weapons",
    "url": "/api/equipment-categories/melee-weapons"
  }],
  "cost": {
    "quantity": 5,
    "unit": "gp"
  },
  "damage": {
    "damage_dice": "1d6",
    "damage_type": {
      "index": "slashing",
      "name": "Slashing",
      "url": "/api/damage-types/slashing"
    }
  },
  "weight": 4,
  "properties": [
    {
      "index": "thrown",
      "name": "Thrown",
      "url": "/api/weapon-properties/thrown"
    },
    {
      "index": "versatile",
      "name": "Versatile",
      "url": "/api/weapon-properties/versatile"
    }
  ],
  "range": {
    "normal": 20,
    "long": 60
  },
  "two_handed_damage": {
    "damage_dice": "1d8",
    "damage_type": {
      "index": "piercing",
      "name": "Piercing",
      "url": "/api/damage-types/piercing"
    }
  },
  "url": "/api/equipment/trident"
}

[bagelbits]

@fergcb What do you think?

[fergcb]

I don't like the idea that the consumer has to look at the equipment categories and properties to figure out what the weapon's range is. I understand that RAW, melee weapons don't have a "range" or a "reach" by default; but say I was creating a VTT powered by this API - it'd be a dream to just be able to look at one property on the equipped weapon and know which grid squares I can hit.

Earlier in this thread the main objection was just the semantics - "melee weapons don't have a range because they're not ranged weapons", and I think that's fair, but it's a shame to lose useful information as a result.

Otherwise, this schema looks good to me :)