Comments (20)
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"
}
from 5e-database.
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. :)
from 5e-database.
@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.
from 5e-database.
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.
from 5e-database.
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.
from 5e-database.
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:
- 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)
- 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
from 5e-database.
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.
from 5e-database.
To recap a bit, currently there are three cases in data:
- melee weapon with
range
- melee thrown weapon with
range
andthrow_range
- 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:
- melee weapon with
reach
- melee thrown weapon with
reach
andrange
- 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.
from 5e-database.
I think, to the strict language of rules, these would be:
- melee weapon with reach
- melee thrown weapon with reach and range
- ranged weapon with range
I think this would be a suitable compromise.
from 5e-database.
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?
from 5e-database.
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).
from 5e-database.
@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"
}
from 5e-database.
This would also let us free up some other fields like armor_category
.
from 5e-database.
No strong opinion on equipment categories, since these are more about API than adhering to rules.
Notes on the latest example:
- Not having Reach in
"properties"
feels inconsistent, since it is one. - 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).
from 5e-database.
@fergcb What do you think?
from 5e-database.
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 :)
from 5e-database.
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.
from 5e-database.
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.
from 5e-database.
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. :)
from 5e-database.
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.)
from 5e-database.
Related Issues (20)
- Restructuring Rules.json HOT 13
- Inconsistent Shapechanger handling HOT 4
- Innate spellcasting missing required components HOT 1
- Monster variants in data that are not SRD content HOT 1
- GitHub deploy action trying to run in a fork HOT 6
- 1.2.6 tag missing in main branch HOT 2
- Missing monster flavor text HOT 1
- Frontend Webpage down on Heroku
- Docker build gives Illegal Instruction (Core Dump) with Latest and v2.1.1 tag HOT 3
- Additional Response Headers HOT 3
- Giant Centipede XP value is incorrect
- Bone Devil monster has wrong challenge rating? HOT 1
- Acolyte has no starting gold
- Add number of spells cast field HOT 2
- Proficiency Bonus is missing in the Monster api HOT 1
- Minor errors found in spell data HOT 1
- Spells with multiple damage types aren't represented HOT 1
- MongoDB 5 Requires AVX Instruction Set to Boot HOT 1
- Magic missile spell: Damage at slot level are incorrects
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from 5e-database.