Charge - To nearest square? Huh?

Hypersmurf · Jan 9, 2009

Dracorat said:
The distance however, is between the combatants, not between squares beside the combatants.

No, it isn't. He doesn't need to move to the combatant. He needs to move to the nearest square from which he can attack the combatant.

The distance we need to measure is the distance between the charger, and the nearest square from which he can attack the target. Not the distance between the charger and the target.

Let's say we have an open field, no corners in sight. Our charger has a longspear. He has a speed of 6 squares. His target is 8 squares away.

Can he charge? Certainly. Because the distance he needs to move is 6 squares - the distance between where he is, and the nearest square from which he can attack the target. The figure of 8 squares is completely irrelevant, because we don't care about the distance between where he is and where the target is. He isn't moving there.

Let me redraw the monkey scenario and see if it helps you see what I'm saying:

Code:

--------
--abcdB--
--M#####
---#####
---#####
---#####

What is the distance from the monkey to the banana?

When counting the distance from one square to another, start counting from any adjacent square (even one that is diagonally adjacent but around a corner) and then count around solid obstacles that fill their squares.

I start counting from a square adjacent to the monkey (even one that is diagonally adjacent but around a corner). That's square b.

So the squares I count are b, c, d, and the banana's square. The distance is 4.

What's the distance from square a to the banana?

I start counting from a square adjacent to the square a (even one that is diagonally adjacent but around a corner). That's square b.

So the squares I count are b, c, d, and the banana's square. The distance is 4.

So if the monkey moves to square a, his distance to the banana is unchanged. He has not moved towards the banana - he's moved laterally, to use your phrase.

(Of course, as I said before, he's not actually moving to the banana, he's moving to square d. But the logic's the same - from his initial position, it's three squares to square d. From square a, it's three squares to square d. Moving to square a is not moving towards square d.)

-Hyp.

Dracorat · Jan 9, 2009

Hypersmurf said:
No, it isn't. He doesn't need to move to the combatant. He needs to move to the nearest square from which he can attack the combatant.

The distance we need to measure is the distance between the charger, and the nearest square from which he can attack the target. Not the distance between the charger and the target.

Let's say we have an open field, no corners in sight. Our charger has a longspear. He has a speed of 6 squares. His target is 8 squares away.

Can he charge? Certainly. Because the distance he needs to move is 6 squares - the distance between where he is, and the nearest square from which he can attack the target. The figure of 8 squares is completely irrelevant, because we don't care about the distance between where he is and where the target is. He isn't moving there.

Let me redraw the monkey scenario and see if it helps you see what I'm saying:

Code:

-------- --abcdB-- --M##### ---##### ---##### ---#####

What is the distance from the monkey to the banana?

When counting the distance from one square to another, start counting from any adjacent square (even one that is diagonally adjacent but around a corner) and then count around solid obstacles that fill their squares.

I start counting from a square adjacent to the monkey (even one that is diagonally adjacent but around a corner). That's square b.

So the squares I count are b, c, d, and the banana's square. The distance is 4.

What's the distance from square a to the banana?

I start counting from a square adjacent to the square a (even one that is diagonally adjacent but around a corner). That's square b.

So the squares I count are b, c, d, and the banana's square. The distance is 4.

So if the monkey moves to square a, his distance to the banana is unchanged. He has not moved towards the banana - he's moved laterally, to use your phrase.

(Of course, as I said before, he's not actually moving to the banana, he's moving to square d. But the logic's the same - from his initial position, it's three squares to square d. From square a, it's three squares to square d. Moving to square a is not moving towards square d.)

-Hyp.

About to go to bed, so I'll see your response in the morning.

But my response is that in the scenario you drew, I agree that the distance, if counted starting from Monkey is the same as after he moved one square. And yet (an oddity with how the rules are applied) if it's counted starting from the banana, the count comes out different.

One could require the count always be from player to destination. Or they could require it to be from destination to player. The rules dictate neither.

Common sense would have most people count from the person performing the action to their destination. In which case, if you start at a corner you are screwed. But if you start anywhere else you're not.

Is that fair? Probably not. But it's written.

Dracorat · Jan 9, 2009

So I was laying there about to doze off when I realized you are even reading "count around objects" different than I do.

In a drawing similar to one you did earlier...

Code:

..X..
.O.O.
OHHHO
.O.O.
..Y..

That's how you count that, I suppose. (Distance 4)

I always count it as

Code:

..X..
OO.OO
OHHHO
O...O
.OYO.

Distance 6

Which btw, affects how we each would handle bursts and blasts when corners land in the possible affected areas.

.... which places us squarely on the opposite ends of this debate, with no clear resolution in sight. (Least ways I can see)

Hypersmurf · Jan 9, 2009

Dracorat said:
And yet (an oddity with how the rules are applied) if it's counted starting from the banana, the count comes out different.

No, it isn't.

Because the distance from the banana to square b is 3, and the distance from square b to the monkey is 1, so the distance from the banana to the monkey is 4. You measure the most direct path.

This doesn't violate the requirement that you count around a solid obstacle! I'm not counting through a solid obstacle.

See the attached picture.

The red path is not how we count distance. It goes through a solid obstacle, and we must count around the solid obstacle.

The orange path is not how we count distance. It goes around the solid obstacle, but it is not the most direct path. It is, however, how you must travel if you are walking, since you cannot move across the diagonal.

The green path is how we count distance. It goes around the solid obstacle, and it is the most direct path.

The distance between M and B is 7 squares. But one must move through 8 squares to travel between M and B, because one cannot travel the path the distance is counted along.

The distance between two squares is the same whether you count forwards or backwards, because you can count across a diagonal around a corner. You can see, shoot, cast, teleport, or make a melee attack across a diagonal around a corner; the only thing you can't do is move.

So when you count across a diagonal around a corner, you're counting around the obstacle. That single point removes the inconsistency you claim, for counting forwards or backwards, or for starting further from the corner.

-Hyp.

Hypersmurf · Jan 9, 2009

Dracorat said:
That's how you count that, I suppose. (Distance 4)

Exactly.

Which btw, affects how we each would handle bursts and blasts when corners land in the possible affected areas[[.

See the illustration on PHB p281, where the Burst 2 counts diagonally across the corner.

-Hyp.

Dracorat · Jan 9, 2009

Hypersmurf said:
[...]

See the attached picture.

[...]

The green path is how we count distance. It goes around the solid obstacle, and it is the most direct path.

[...]

I gave this some thought this morning, especially after my revelation last night that we were counting "around" differently.

In pretty much any scenario that I can derive, your green path counting method does seem to handle it consistently. To my very legalistic way of looking at things, that does at least offer some comfort.

Interestingly, it doesn't completely answer the question of "can I charge around a corner" with a "no" - in that if one starts sufficiently away from a wall to where they still are getting closer with each step, then they can still "curve" around the wall. But, they can't take a 90 degree turn, which I previously thought possible.

Thanks for dropping the strawman and resorting back to reasonable logic, btw. I feel comfortable with the explanation you just provided. I would not have felt at all comfortable with a strawman "win" - in that I would have viewed it as an easy out.

And that's a pretty good drawing btw. What did you use to draw it? I could do something like that with Photoshop, but for a forum posting I'd not likely spend the time.

Soo.... This is me admitting that in some of the previous points, you were right and I was wrong. With the new information, I see it.

That said, I hope people can at least see where curving is possible too. Straight line isn't still the only valid charge.

And in my game (which is now apparently my own house rule) I'll be counting distance based upon movement as if no enemy blocked squares (still allowing my players to charge around corners).

Hypersmurf · Jan 9, 2009

Dracorat said:
Interestingly, it doesn't completely answer the question of "can I charge around a corner" with a "no" - in that if one starts sufficiently away from a wall to where they still are getting closer with each step, then they can still "curve" around the wall. But, they can't take a 90 degree turn, which I previously thought possible.

This comes back to the word 'directly'.

I'd say that yes, someone can curve around the wall as long as each step brings them closer.

Caliban would say no, someone can't curve around the wall, because they are not travelling in a straight line.

Both of us would cite the word 'directly' as our evidence.

But I think we both recognise that this word is the source of the inconsistency.

Thanks for dropping the strawman and resorting back to reasonable logic, btw.

For what it's worth, what you're calling 'strawman', I'm still calling 'example' - I still don't know what the objection you had to the example was! As far as I'm concerned, I never left the path of 'reasonable logic'!

And that's a pretty good drawing btw. What did you use to draw it?

Photoshop.

That said, I hope people can at least see where curving is possible too. Straight line isn't still the only valid charge.

... depending on how one interprets the word 'directly'.

If 'directly' means 'straight line', then straight line is the only valid charge, because the movement of the charge must be 'directly'.

-Hyp.

Dracorat · Jan 9, 2009

Hypersmurf said:
For what it's worth, what you're calling 'strawman', I'm still calling 'example' - I still don't know what the objection you had to the example was! As far as I'm concerned, I never left the path of 'reasonable logic'!

I had no objection to the examples, but some of your posts were trying to trap me in casual use of language that was never intended to be used as strictly. It was those I was objecting to.

Once that started happening, I had to start trying to be very specific about what points I was agreeing to, down to the word, which didn't seem to really be adding to the conversation.

After my objection, you changed gear to re-elaborating your point.

I appreciated that and as you can see from the resolution, took your arguments seriously.

...

And for the record, I'm amused you used Photoshop. Because to do the level of detail you did is more than I would have done most likely.

It's why I use code tags usually. Heh.

deleteme123456 · Jan 9, 2009

Actually PHB 281 does NOT count diagonally around a corner and the rules specifically cover it if you look up how to count distance for ranged attacks, and then trace the text in burst/blast attacks to counting distance using the ranged method.

Code:

--BSB
-WBBB
-WOBB
BBBBB
BBBWW

Let the top left corner be row 1, column 1, and as you move across L->R you are going across columns, and down T->B is down rows. Let B = a square in the Burst, W = wall, - = not affected by burst, O = origin.

Compare R1, C2 to R4, C1:
R1, C2 does not get affected even though it seems like it's in range if you can cut the diagonal. So why does R4, C1 get affected when it seems too far away? The best answer I can give you is on PHB 273: "When counting distance from one square to another, start counting from any adjacent square (even one that is diagonally around the corner)" (look up a few paragraphs to see that you start counting from the origin square in this case).

Not that it's strictly relevant, but I did want to bring that up.

Bayuer · Jan 9, 2009

PHP p.273

Counting Distance: When counting the distance from one square to another, start counting from any adjacent square (even one that is diagonally adjacent but around a corner) and then count around solid obstacles that fill their squares. You must choose the most direct path to a target when counting squares for range or when determining the extent of an area of effect.

Hyp is right about counting distance. The rules are clear and simple about that. All adjacent to you target counts as 1 square (even around corner). When further obstacles will come, you just count around them as normal.

Also charge is just like counting distance now. Sometimes it gives zig-zags, sometimes not. It's so simple rule that don't have a high impact on game. Rember it's not the 3.x charge anymore and compare it to DDM and you will see that now charge is possible more often thatn before.

The outlined text is just like in charge description but more clearly wrote.

Cheers

Charge - To nearest square? Huh?

Hypersmurf

Moderatarrrrh...

Dracorat

First Post

Dracorat

First Post

Hypersmurf

Moderatarrrrh...

Attachments

Hypersmurf

Moderatarrrrh...

Dracorat

First Post

Hypersmurf

Moderatarrrrh...

Dracorat

First Post

deleteme123456

Explorer

Bayuer

First Post

Similar Threads