Remove automatic granting of RANGE:10 when equipment has TYPEs of Ranged, Thrown or Projectile

Description

Trying to work out new Output sheet logic, where a weapon with RANGE>1 will display the range blocks. This would allow the rsrd Soulknife to have a proper automatic display of the Mind Blade thrown ability when they reach the correct level.

However, preventing this logic is code that automatically grants a RANGE of 10 if the RANGE is missing from the object.

Data should be policing and controlling those range values. This is a request to remove Code automatically pushing a value into range when absent.

Thanks.

Environment

None

Activity

Show:
James Dempsey
July 11, 2014, 6:13 AM

Removing this causes a failure in the Alice and Fran character tests with the "Tentacles of the Fey" becoming <category>Natural-Natural,Melee</category> rather than <category>Natural-Natural,Both (Melee)</category>. Is that just a data issue?

Andrew Maitland
July 11, 2014, 12:15 PM

I suspect there may be more underlying magic here. This is what the Data has:

But we don't have any viable method to indicate a Range on Natural Attacks. The Category Change is odd to me. But seeing as how we don't have proper RANGE support for NaturalAttacks, I would say this is an all-around a bug causing a feature we never had proper support. (BUG: Type output changes based upon Range is bad)

So, this IMPACTS at least one real monster - but here's the kicker, due to the code behavior and lack of support, this beast is incorrect anyways:

Manticore
What we have:

What displays:
5 or 10 Increments of 10'

What the ability actually says:
Spikes (Ex): With a snap of its tail, a manticore can loose a volley of six spikes as a standard action (make an attack roll for each spike). This attack has a range of 180 feet with no range increment. All targets must be within 30 feet of each other. The creature can launch only twenty-four spikes in any 24-hour period.

Anyway you slice the pcgen output is incorrect.
Our Range = 10 vs. 180
Our Increments are at least 5 vs. 1

We also have the Bebilith:
Web (Ex): A bebilith can throw a web up to four times per day. This is similar to an attack with a net but has a maximum range of 30 feet, with a range increment of 10 feet. This attack is effective against targets of up to Gargantuan size. The web anchors the target in place, allowing no movement.

Another incorrect result
Our Range = 10 vs. 10
Our Increments are at least 5 vs. 3

Retriever:
NATURALATTACKS:Eye Ray,Weapon.Natural.Ranged.Touch,*1,1d0
This should definitely be an SA:
Eye Rays (Su): A retriever’s eyes can produce four different magical rays with a range of 100 feet. Each round, it can fire one ray as a free action. A particular ray is usable only once every 4 rounds. A retriever can fire an eye ray in the same round that it makes physical attacks. The save DC for all rays is 18. The save DC is Dexterity-based.

This is emulating the 'Ranged Touch' without ever mentioning it - Data correctable with SPROP=x

In most instances in my quick search through a portion of the RSRD we aren't using the correct RANGE or the correct number of Increments. In the rest, we're using the Natural Attack to arrive at a Number to tell the user the attack roll (touch ranged) but that information isn't correctly imparted in the existing code (None of the tags are using the new SPROP=x).

Issue #1: (Bug)
Based upon your finding with Alice and Fran - NaturalAttacks with TYPE:Range but no RANGE value are converted by the Code to be non-ranged.

  • Regardless, types should remain persistent.

Issue #2: (Feature Request)
We need a method to adjust the Range on NaturalAttack, otherwise, having Range output is giving an incorrect distance of 10' and defaulting to 5 or 10 increments depending on which filter it triggers.

Issue #3: (Feature Request)
We need a method to set the Increments used whether it is 1, 2, 3, 5, or 10 (Yes, those are the ones I've seen so far). Allowing for dynamic changes would also be nice. (Example, Dagger is Thrown - defaults to 5, add a power which increases the range increments to 10)

Issue #4: (Data Bug/Feature)
We need to correct all the erroneous entries (Or flag them as needing attention)

Ultimately, we need to decide if supporting "Range" on Natural Attacks is a higher priority then yanking a 'bad' feature that is giving us incorrect results for the vast majority in monsters. (Of all the samples I looked at, only one actually arrived at the correct result of 10', but I don't know if the system is granting 5 or 10 increments without looking). In all cases, the NA can be removed in favor of the SA/SQ entry and a CombatBonus entry.

I'm going to look at it this way - If we can set up ranges to only display with a Range>0 then all those NA with range displays will stop displaying anyways. The alternative is to patch or hack on more "bad" code to support the erroneous output by adding a Filter "Ranged + NaturalAttack" so those continue to output the same as they already do.

Either way, we should address this.

Cheers,

James Dempsey
July 11, 2014, 4:18 PM

Thanks for the examples and explanation Andrew. That describes well the impact of pushing the range onto data, why it is good and where the gaps are.

I can correct the category change easily enough now that I know the background. The test characters will have the range of the attack reduced from 10 to 0 feet in line with what you noted above.

The modification of natural attacks has to be separate to this change and considered beside the revamp of natural attacks that has been discussed. As an interim an SPROP seems like a very good idea.

Modification of the ranged block in output sheets will also need a separate issue.

Andrew Maitland
July 11, 2014, 5:17 PM

You're welcome. Always happy to illustrate our shortcomings in the hopes that we may improve them. I intended all the issues to be separate tickets. Bitesize chunks of a project. I do agree, we should weigh the new Natural Attack proposal and see if it handles range and if not, make an fix to include range. Since (if memory serves) I set those up to be like Equipment, adding Range should not be impossible to do.

I already have an OS tracker for the update to RANGE: Change RANGED Display to output only when RANGE value is >0
We'll need a Combo to handle Range Increments - determine whether it's a feasible newtag, or if 's EQVAR will be able to handle that. I can see the EQVAR handling the Equipment side, but the NA side seems best in consultation with Tom to see what he thinks. Should we open a Newtag tracker for this?

I'll open the Data tracker - Systemwide - use of RANGE in NA to be modified with SPROP=x explaining function and ranges as best as possible.

James Dempsey
July 12, 2014, 4:02 PM

Also removed the limitation on the ranged category that it have a range.

Assignee

James Dempsey

Reporter

Andrew Maitland

Labels

None

Theme

None

Epic/Theme

None

Pending User Input

None

Fix versions

Affects versions

Priority

Minor
Configure