Targetting and LOS discussion wiki page

[RogerN]

The 2 southernmost dots, are not visible. The furthest dot is a borderline case, normally visible, but since it is borderline blocked from 2 opposing sides, is has to be considered non-visible (even if a special exception be made). The dot above it has no line of sight to the center point.

Paul's diagram is not exactly the same as mine. In my diagram, the two southernmost points are 1 tile farther to the right. In the situation as I originally described it, both points clearly have LOS to the center and neither case is borderline.

Diagram to follow...

[PaulBlay]

I'll take issue with that. The 2 southernmost dots, are not visible. The furthest dot is a borderline case, normally visible, but since it is borderline blocked from 2 opposing sides, is has to be considered non-visible (even if a special exception be made). The dot above it has no line of sight to the center point.

This isn't the Digital Field of View method, there is nothing stated in the definition to disallow a LOV just because it touches exactly the point of a wall tile above in one place and below in another.

You're probably right about the dot in the middle, although it should be noted that my diagram is not 100% accurate and should be checked with maths before being taken as gospel.

@#?????
...
###.#
    .
     ? ?

        ?.?

Probably the middle dot shouldn't be there - as shown above.

[PaulBlay]

Paul's diagram is not exactly the same as mine.

Yeah, it's a lot easier to see when you replace the spaces with x's.

@#?????xxxx
...xxxxxxxx
###.#xxxxxx
xxxx.xxxxxx
xxxxx?.?xxx
xxxxxxxxxxx
xxxxxxxx?.?

I'll put up a mark two.

[RogerN]

This is the correct diagram. You can see that the two southernmost points are not borderline (although they are close to borderline); they are clearly visible according to the rules.

[PaulBlay]

This is the correct diagram. You can see that the two southernmost points are not borderline

The third of the horizontal trio is borderline, though. I think it 'just' touches the diamond, so it's safe under the definitions used.

[d_m]

So I added a section on Terminology to the wiki page, which will hopefully clear up some confusion (or at least make some genuine disagreement explicit); please let me know if you don't agree or think I'm crazy.

The thing that I think is important to add to the discussion (which has so far mostly been left out) is how projectile-paths should be implemented in the particular suggestions. Especially in DFOV, there are situations where a wall square won't block a projectile, but players might expect a monster in that square to absorb the missile. E.g.:

@.#   @.#   @.#
#o#   o##   oy#
#p#   #p#   #p#

In each of these, most player would like to imagine that the novice ranger couldn't shoot them. The question is, what is the correct way to implement projectile path? Whatever your answer, consider the following:

@.#   @.#
o.#   .y#
#p.   #p#

Are the player's shots against the novice ranger blocked in both of these cases? Clearly, if the orc/yeek were walls, the shot would be available (according to DFOV). This implies (to me) that projectile paths will need to treat occupied squares and walls differently in terms of path-blockage.

Either that, or that projectiles will be much harder (or impossible) to block, which has very serious (probably unacceptable) problems for game play.

[aeneas]

That is the appeal for reverse targetable implying visible. You get that with symmetry plus visible == targetable. I would like some sort of highlighting method to make obvious which monsters detected through spell or ESP are in, versus not in, reverse LOS.

There would still be a learning curve about stepping into LOS of a monster. If things change, there's no way to avoid that. I suppose you should modify disturb to stop you before it [knowingly] happens when you are running.

I'm still trying to figure out why it should be changed. But I agree that if it is changed it should be changed so that you can target anything you can see. This still poses problems, when you have ESP.

Anyway, I looked over my recent posts with the help of a friend and came to the conclusion that a few of them were not as civil as they should have been. I happen to be missing the part of my personality that cares about civility. So I apologize if you found my earlier posts overly rude. I don't understand that, but I'm willing to take it on faith.

[PaulBlay]

The thing that I think is important to add to the discussion (which has so far mostly been left out) is how projectile-paths should be implemented in the particular suggestions.

Zaimoni probably has the best handle on that (I added a section to the wiki page based on his recent post).

[RogerN]

The third of the horizontal trio is borderline, though. I think it 'just' touches the diamond, so it's safe under the definitions used.

It just looks that way because I drew the diagram so small The line does not touch the diamond at all. I should draw up a larger version...

[PaulBlay]

It just looks that way because I drew the diagram so small The line does not touch the diamond at all. I should draw up a larger version...

It touches in the big version I drew (my piccy in the wiki is reduced to 50% width/height). In fact it is simple geometry that it touches (measure the sides and remember "similar triangles" from comprehensive school ;-)

Just imagine two triangles, the one visible in the diagram and the one formed by the left hand point, the lower diamond point, and the center of the diamond.

[zaimoni]

The question is, what is the correct way to implement projectile path? Whatever your answer, consider the following:

@.#   @.#
o.#   .y#
#p.   #p#

Are the player's shots against the novice ranger blocked in both of these cases? Clearly, if the orc/yeek were walls, the shot would be available (according to DFOV). This implies (to me) that projectile paths will need to treat occupied squares and walls differently in terms of path-blockage.

Zaiband and V both handle this by using a parameter to signal whether occupied squares block (bolt/physical missile) or not (ball, beam).

In V:
* o blocks @'s shot of p but does not block p's shot of @
* y blocks p's shot of @ but does not block @'s shot of p

DFOV indeed would not let either o or y provide cover for anyone. The gameplay effects of this are indeed pervasive.

[RogerN]

Yet another diagram, demonstrating that the LOS does not touch the corners of any intervening diamonds:

[d_m]

DFOV indeed would not let either o or y provide cover for anyone. The gameplay effects of this are indeed pervasive.

Thanks for reviewing V's current project_path() algorithm; I think it's a good place to start talking about projectile paths. It wasn't clear to me that DFOV would have to work any particular way which is why I posed the question.

I can imagine using the current project_path() algorithm but just skipping blockages by walls. I can also imagine either skipping both o and y (as you indicate) or various probabilistic approaches (e.g. where y and o both have a 50% chance of blocking the arrow).

[RogerN]

I can imagine using the current project_path() algorithm but just skipping blockages by walls. I can also imagine either skipping both o and y (as you indicate) or various probabilistic approaches (e.g. where y and o both have a 50% chance of blocking the arrow).

The project_path() algorithm could be rewritten to treat both walls and monsters as diamonds instead of squares. In this case, then neither y nor o will block the arrow. In fact, even if both of them were present at the same time the arrow could still squeeze between them... but that could be handled by a special case since it's probably not desired behavior.

I don't like the idea of having a 50% chance of one of them blocking the arrow. But if both o and y are present, you could randomly choose which one gets hit.

I think it's important to ensure the projection paths are symmetrical. If o or y is blocking for @ then it should also be blocking for p.

[zaimoni]

I think it's important to ensure the projection paths are symmetrical. If o or y is blocking for @ then it should also be blocking for p.

V's problem is, in part, because the calculation of projection paths is inflexibly symmetrical (this is where the one-way cover comes from).