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 :)

[bagelbits]

You could maybe tuck it into range:

  "range": {
    "normal": 20,
    "long": 60,
    "reach": 10,
  }

That might make the most sense. Though might be weird? But that could just be the semantics term.

[Rarst]

Yeah, as above, there are API convenience considerations. I think it might be best to just bite the duplication and have both derived effective reach property at root (5 or 10 in feet, I vaguely remember magic weapons might extend this? even if there aren't any like that in SRD) and Reach entry in properties list.

To be clear my concern isn't making API minimal, my concern is making language of the API consistent with that of the rules. :)

P.S. against having reach in range because we get full circle to initial problem of melee weapons not having Range. :)

[oznogon]

Bit of an older topic, but improvised weapon rules are an additional complication, and also appear to be missing from the database as a weapon property or rules section:

If a character uses a ranged weapon to make a melee attack, or throws a melee weapon that does not have the thrown property, it also deals 1d4 damage. An improvised thrown weapon has a normal range of 20 feet and a long range of 60 feet.

So RAW, every melee weapon without the thrown property also has at least a 20/60 ft. improvised thrown range, and every ranged weapon has an undefined default, but presumably 5 ft., improvised melee reach.

Improvised attack ranges shouldn't be modeled in the data for every weapon and creature weapon attack---that's on the hypothetical VTT's implementation, which can't necessarily assume that the range value currently provided is a melee weapon's full melee or ranged attack distance extent.

[Rarst]

I disagree that improvised use is a property of a weapon. Improvised stats are set by that rule, so they don't differ between weapons (beyond melee/ranged which is already available information).

Does seem missing from the rules, probably worth a separate issue. :)

[oznogon]

The "Improvised Weapons" section of the SRD is a subsection of the "Weapon Properties" section (along with "Silvered Weapons" and "Special Weapons") which is the only reason why I associated it with the database's weapon properties. Improvised range, melee use, and damage are definitely very closely adjacent rules; they're not a "weapon property", but they're a property of every weapon.

My point is more in agreement with yours on how using reach for range in melee weapons without the thrown property isn't appropriate even for the VTT default use case, because they do have a range, and it's not "5".

(Sorry for the edits; on a phone.)