4e D&D's line of site vs. Maptool's

[tmatk]

I think I just noticed an issue, maybe this is common knowledge.

In this image, the bottom token is unable to see the top one. By 4e rules, however, it should have line of sight. Correct?

[Hawke]

You'll notice the reason is that the point is drawn from the center of the square where 4E draws it from each corner. I think the big discussion about it is how to allow for a 4E vision type without quadrupling the number of calculations needed - or how to make it efficient enough that doing such doesn't create a slowdown.

An expert on the matter will likely come by and give a more detailed and/or accurate account.

[tmatk]

You'll notice the reason is that the point is drawn from the center of the square where 4E draws it from each corner. I think the big discussion about it is how to allow for a 4E vision type without quadrupling the number of calculations needed - or how to make it efficient enough that doing such doesn't create a slowdown.

An expert on the matter will likely come by and give a more detailed and/or accurate account.

That makes sense; I figured there had to be an obvious reason.

[Mathemagician]

Calculating line of sight is the most expensive (in time) operation Maptool has. To do 4e styled line of sight, we would need to do 4 times the work because it would have to be calculated at each corner.

I believe that most people here have concluded that, since Maptool's rendition is a little more "realistic" and 4e's was designed to be simple (generally you know which corner will be best, and there's no ambiguity about the center of the token), it is simply natural to use Maptool's version. That's what my 4e group did.

[Blakey]

How do people who use MTs version of this get around "shooting around corners" ?

A person stood behind a corner of a corridor leading from a room should have clear line of sight all the way down that corridor in 4E. MT does not provide that at all. they can only see half a square down the corridor.

Blakey

[Rumble]

How do people who use MTs version of this get around "shooting around corners" ?

A person stood behind a corner of a corridor leading from a room should have clear line of sight all the way down that corridor in 4E. MT does not provide that at all. they can only see half a square down the corridor.

Blakey

There's two issues to consider: Fog and Vision. For fog, the easy solution is to use a "vision" token that can expose fog (like a floating eyeball or something), or to manually expose what the character should see.

For VBL, that's more of an issue since the token won't actually see anything, if vision is on. I see basically two options:

1. You can't shoot around the corner. However, fake it. Put the token that's doing the shooting out where it can see, but give it cover as if it were not.

2. Edit VBL so that you can see down the hall ("notching" the VBL generally works).


It might be possible in the future to have a vision offset (perhaps one you can manipulate by macro) so you could, say, click a macro to offset vision one-half square in the direction of the Facing arrow (that way, you could move the effective center of your vision to one edge of the square, and recalculate what you can see). Clunky, but it would work. Or maybe even let you designate "See From Here" and have it click through the various facing points.

[Phergus]

How do people who use MTs version of this get around "shooting around corners" ?

You can temporarily turn off the snap-to-grid on the token and then position it far enough forward to get the line-of-sight.

[plothos]

I believe that most people here have concluded that, since Maptool's rendition is a little more "realistic" and 4e's was designed to be simple

Not sure where that impression is coming from. My impression was that people were split on the issue. I think all vision being from the center is far from realistic, myself, and much prefer the way D&D does it. But that's just me.

I still think this should be implemented as a toggle. If it becomes a slow-down issue, click if off. If not, people have the option of which vision to use.

[Azhrei]

I still think this should be implemented as a toggle. If it becomes a slow-down issue, click if off. If not, people have the option of which vision to use.

Agreed. You don't like it, you turn it off.

Personally, I wouldn't use it -- center of the token is fine for me. But I can also understand an interest in having the mapping tool actually implement the sight lines prescribed by the game, so some technique needs to be available.

The most flexible scheme might be to let the GM decide. We put up a grid (square or hex) and let the GM click on the grid to indicate where they want vision to originate. And we could provide pre-defined configurations for common game systems.

Would there be any need to clear FoW differently than it's being done now? FoW is based on what you've seen and what you can see is based on light sources. So does this mean that light sources also have to be implemented at each corner? Otherwise, you can't actually see the creature around the corner... So we now have 4x the calculations for sight/VBL and 4x the calculations for light interactions. (Or maybe the two could overlap some how? Maybe the code could look at which goes further, vision or light, and as it's processing sight lines it also does the light source stuff? I have no idea as things like this are definitely not my bailiwick.)

[LaserWolf]

Here's a thought. Realistically you don't need to calculate vision from all four squares all of the time, so there's no reason to slow everything down with those computations.

What if, instead, there was a way to move the origin of vision on the token? Maybe a little overlay that could be called up with a menu option or keyboard command. An X shows up and snaps to any of the vertices or the center of the token's space. Then, when you need to see around a corner, you just drag the vision origin to the appropriate vertex. It costs no more in computation than would moving a token.

[Blakey]

Here's a thought. Realistically you don't need to calculate vision from all four squares all of the time, so there's no reason to slow everything down with those computations.

What if, instead, there was a way to move the origin of vision on the token? Maybe a little overlay that could be called up with a menu option or keyboard command. An X shows up and snaps to any of the vertices or the center of the token's space. Then, when you need to see around a corner, you just drag the vision origin to the appropriate vertex. It costs no more in computation than would moving a token.

Love this idea.

This way you could keep vision to the centre of the token which is fine most of the time for general exploring but when a PC wanted to "peek around a corner" they could move their own vision origin to the corner of their square, and this would redraw the vision for that character from that new origin. Perfect.

[tmatk]

Here's a thought. Realistically you don't need to calculate vision from all four squares all of the time, so there's no reason to slow everything down with those computations.

What if, instead, there was a way to move the origin of vision on the token? Maybe a little overlay that could be called up with a menu option or keyboard command. An X shows up and snaps to any of the vertices or the center of the token's space. Then, when you need to see around a corner, you just drag the vision origin to the appropriate vertex. It costs no more in computation than would moving a token.

I agree, good idea. Could be handled the way facing is, hold down a modifier key and scroll the mouse wheel.

My current solution is to let player's "hop out" into the hallway so they can see around a corner.

[jfrazierjr]

FYI, I talked to Trevor about this somewhat recently when I was working on Vision stuff. I don't want to put words in his mouth, so I hope I got this close to right.

His response was something along the lines of wanting to do this right, and part of this was being coming up with a model to support any grid type or gridless. However, since a token's bounding box will always be square:

Grid.png (136.67 KiB) Viewed 1520 times

This presents a problem for both Hex grids and gridless players(on a side note, this is ALSO the reason why hex halos will probably not be done anytime soon.) The base problem is that the token thinks of itself as a square that might just happen to fit inside a grid cell. The token knows exactly where its bounding box is, but has no idea where the grid is below in relation to the bounding box. Trevor would like to support this, but I really don't see this in 1.3, so perhaps when he rewrites the rendering system in 1.4(which I am sure he said he wanted to do), this might be much easier to deal with(or might not).

[Rumble]

Here's a thought. Realistically you don't need to calculate vision from all four squares all of the time, so there's no reason to slow everything down with those computations.

What if, instead, there was a way to move the origin of vision on the token? Maybe a little overlay that could be called up with a menu option or keyboard command. An X shows up and snaps to any of the vertices or the center of the token's space. Then, when you need to see around a corner, you just drag the vision origin to the appropriate vertex. It costs no more in computation than would moving a token.

Yep. The "see from here" idea I posted up above is essentially this: just click through the possible positions as Vision Origins, and redraw. And as far as where bounding boxes are...I dunno. Let the programmers figure that one out.

[zEal]

FYI, I talked to Trevor about this somewhat recently when I was working on Vision stuff. I don't want to put words in his mouth, so I hope I got this close to right.

His response was something along the lines of wanting to do this right, and part of this was being coming up with a model to support any grid type or gridless. However, since a token's bounding box will always be square:

<snip>Image</snip>

This presents a problem for both Hex grids and gridless players(on a side note, this is ALSO the reason why hex halos will probably not be done anytime soon.) The base problem is that the token thinks of itself as a square that might just happen to fit inside a grid cell. The token knows exactly where its bounding box is, but has no idea where the grid is below in relation to the bounding box. Trevor would like to support this, but I really don't see this in 1.3, so perhaps when he rewrites the rendering system in 1.4(which I am sure he said he wanted to do), this might be much easier to deal with(or might not).

Undoubtedly this won't be happening in 1.3, but perhaps one way around this particular issue is by implementing the user definable bounding boxes that have been brought up previously. Maybe a better term for them could be "user definable bounding areas" so they can support rectangles and both flavours of hex.