targetting and LOS

[Rizwan]

They are certainly treated differently. Surely you recognize the difference between

#####################
# # # # # # # # # # #
## # # # # # # # # ##
# # # # # # # # # # #
## # # # # # # # # ##
# # # # # # # # # # #
#####################

and

#####################
# # # # # # # # # # #
# # # # # # # # # # # 
# # # # # # # # # # # 
# # # # # # # # # # # 
# # # # # # # # # # # 
#####################

You know you are right but somehow I always thought there was more of a space between those walls. Just shows you that you can play Angband for umpteen years and still not see whats right in front of you. Now that I know there is no space between those wall sits going to bug me whenever I enter into such a room. Thanks Pete
So if you can walk between the ones on top then you should also be able to walk between the ones on the bottom because the # representation visually fools you into believing that there is space there. Maybe the solid wall configuration would help? I still say that @ should not be able to see or walk thorough the pillars shown in the top view.

[Pete Mack]

So in Angband

   #           and         #
  #                        #

are treated differently? It seems weird that in the case of vertical or horizontal walls we assume they touch with no gap in between but if you have diagonals then they don't touch. If we put two bricks together in the manner shown on the left then we cannot see through the edge that is touching .
And your diamond representation will not change this?
DFOV mentions polygons right? So could we use hexes instead of diamonds and not have it be a big deal?

They are certainly treated differently. Surely you recognize the difference between

#####################
# # # # # # # # # # #
## # # # # # # # # ##
# # # # # # # # # # #
## # # # # # # # # ##
# # # # # # # # # # #
#####################

and

#####################
# # # # # # # # # # #
# # # # # # # # # # # 
# # # # # # # # # # # 
# # # # # # # # # # # 
# # # # # # # # # # # 
#####################

[Rizwan]

This is about the advantage of hexes over squares. In a hex map, two adjacent tiles share a vertex iff [if and only if] they share an edge. In a square map, it is possible to share only a vertex.

In the current system, diagonally adjacent #'s are assumed not to touch. Changing that would be a big deal.

If you really want to change this, you should widen the discussion to include switching to a hex map where there is no problem, by design.

So in Angband

   #           and         #
  #                        #

are treated differently? It seems weird that in the case of vertical or horizontal walls we assume they touch with no gap in between but if you have diagonals then they don't touch. If we put two bricks together in the manner shown on the left then we cannot see through the edge that is touching .
And your diamond representation will not change this?
DFOV mentions polygons right? So could we use hexes instead of diamonds and not have it be a big deal?

[PaulBlay]

I'll take either of the former, though I'd like to see 'special cases' avoided as much as possible, and this 'special case' is pretty trivial, purely aesthetic, and in the long run, probably more confusing than worthwhile.

At least in the case of room walls of lit rooms I don't see that it would be confusing at all.

[EDIT] Deleted stuff I wasn't quite sure about.

[buzzkill]

I hold that displaying additional walls (such as exterior and corner wall tiles of rooms) does not require making them technically visible or targettable. This applies to the arguments about whether expanding shadows are compatible with 'nice' display of room walls.

I'll take either of the former, though I'd like to see 'special cases' avoided as much as possible, and this 'special case' is pretty trivial, purely aesthetic, and in the long run, probably more confusing than worthwhile.

A simpler way to look at this might just be to ask "How long do you want the hockey stick to be?". The longer the stick, the more permissive the visibility and targeting will be. The current 1x2 HS yields only 20' of visible wall when standing adjacent to it, 40' visibility at 10' distant, etc. Once we establish this number, then mechanics and special cases can be worked out. Poll anybody? [cringes]

[PaulBlay]

I hold that displaying additional walls (such as exterior and corner wall tiles of rooms) does not require making them technically visible or targettable. This applies to the arguments about whether expanding shadows are compatible with 'nice' display of room walls.

For clarity I've suggested some changes to the wiki page and I'd like to know whether anybody really thinks it's a good idea to expand visibility/targetability for walls displayed as a "special case".

Here's an example of what I mean from the "diamond wall blocks" system.

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

Our hero has just walked into a room. The '?' grids are wall tiles that are naturally 'out of sight'.

#G##.####
#...@....
#........
#........

Same situation, but room walls are displayed as a special case. Although they are displayed, they are not targetable and a ghost in the position shown would not be shown (nor would it be able to target the @).

#G##.####
#...@....
#........
#........

Same situation but displayed room walls are specially made visible and targetable. The G can target the @ and the @ could target the G (if there were spells that hit G's in walls). However if the @ casts a stone to mud where the G is it will no longer be a special case and will 'disappear' (no longer be able to target, or be targetable). I don't see why anyone would want this to happen - but if people do speak now or forever hold your peace.

[Nick]

I don't know how long you've been playing bands, but I wonder if you remember Lev. He was King of Bands at one point. He won Z in <50K by abusing every game mechanic he could. I'm still pretty impressed with Lev- he was a very good player. But I have a different philosophy- I only abuse a certain number of things .

One of the big questions about Angband is what constitutes abuse. As far as I am concerned _any_ digging meant to establish a better tactical position is abuse. Yeah- it's in the game. But it allows you to reduce the worst enemies in the game to walking treasure boxes. I don't consider any win that used ASCs at any point a real win.

I've only been playing about 6-7 years, and maintaining less than four. My view on this currently is that I will change LOS/targetting/whatever in FA when I see a compelling reason to do so - and I haven't yet.

As things stand, I tend to see LOS abuse as more a player decision than a maintainer one. This fits my general philosophy of giving the player as much choice of playstyle as possible - I think that even with the most egregious abuse possible it's a pretty hard game. But then I'm just a variant maintainer

[zaimoni]

A symmetrized viewability/projection algorithm would end up with the following for @

But you don't use that in Zaiband, right?

Currently (Zaiband 3.0.9).

I'm almost annoyed enough with PowerDiver's insistence on advocating a subtly invalid argument with an already-constructed counterexample, to create a birth option for symmetrizing LOS/projectability for Zaiband 3.0.10. It may go in anyway, but I have a personal distaste for making decisons out of anger/annoyance/frustration.

[I have almost made the decision to ditch savegame import from earlier versions into Zaiband 3.0.10; 3.0.8 |-> 3.0.9 corrupts item memory, and trying to fix that currently causes rather catastrophic import bugs. I have made the decision that this isn't a release blocker, two days ago.]

[PaulBlay]

Ok...here we go:

Thanks, that was very useful.

A symmetrized viewability/projection algorithm would end up with the following for @

But you don't use that in Zaiband, right?

[zaimoni]

Could we see some diagrams for Zaiband?

Ok...here we go:

One-pillar cases:

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

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

In a plain rectangular room: identical to V, except you can target anything you can see that isn't in a wall. The projection path enabling visibility will automatically swerve as needed, thanks to Tyrecius' Permissive Field of View techniques.

T-intersections and entering rooms are a bit more dangerous in Zaiband:

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

has a reasonable ambush by D:

###
#D.
#..
#..
#..
@..
#..
#..
#..
#..

With all trick shots being handled automatically, all visible/targetable floor squares are fair game for ground zero of a ball spell; @ can be targeted by D but not conversely.

A symmetrized viewability/projection algorithm (directly violating Permissive Field of View) would end up with the following for @:

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

Note that Zaiband abolishes the hockey puck by allowing off-diagonal projections to start diagonally:

??o
?x#
#x#
@.#

In V, this fails because the first step is into the wall to the north.

[PowerDiver]

the whole notion of not being able to target every wall tile from inside a room as a complete deal breaker is about as naive as saying no expanding shadows on single pillars is a deal-breaker. They are two different interpretations of Angband's dungeon model, and they both give rise to acceptable (IMO) gameplay.

I hope I never described either as a deal-breaker. People were suggesting changes that they thought could address various problems. My point was that you cannot fix everything. I gave a list of properties that I claimed cannot all be true in any consistent model of the type under discussion. Well, I listed my preferred properties and said that another property could not be made consistent with them, which amounts to the same thing.

This should suggest to model designers that they choose which property to violate at the start of the process of designing a model. Or, if they don't believe my claim, they should first show that my argument fails to apply to the kind of model they are considering.

[Marble Dice]

"The four points of the obstructing diamond do not obstruct visibility unless that point is adjacent to another wall tile (this allows extra visibility around corners, but prevents sight through walls)."

Are you referring to tangent touches of the LOS with the extreme point of the diamonds there?

Right. Permitting tangential intersection allows "no blind corners" but if you don't patch it for adjacent walls, you'd get leaking lines of sight inside of corridors, and other situations:

#@#
#.#.
#.#  .
#.#    .

[PaulBlay]

As named on the wiki page, the properties PowerDiver is referring to are "No hidden ghosts" (all pass wall monsters in visible wall tiles are visible) and "No lost targeting" (casting stone-to-mud on a walled, targetable ghost does not cause an inability to target that tile).

Ah, thanks. I figured "No hidden ghosts" was probably one of them after I check the wiki.

While you're here

The four points of the obstructing diamond do not obstruct visibility unless that point is adjacent to another wall tile (this allows extra visibility around corners, but prevents sight through walls).

Are you referring to tangent touches of the LOS with the extreme point of the diamonds there?

[Marble Dice]

I agree that you can make visible walls in conjunction with expanding pillars consistent, if you are willing to violate one of the properties I suggested about passwall monsters.

Yeah, but what were those properties? That post must be over 10 replies ago as I can't see it from here.

As named on the wiki page, the properties PowerDiver is referring to are "No hidden ghosts" (all pass wall monsters in visible wall tiles are visible) and "No lost targeting" (casting stone-to-mud on a walled, targetable ghost does not cause an inability to target that tile).

Of course, as Paul points out, one or more of these properties are only broken if you actually want to make all those wall tiles visible/targetable. You can still just use the map memory to display the walls (in the darkened non-visible wall tile color) even though those tiles aren't visible (which really just means stuff inside those wall tiles isn't visible).

You can argue that would be more difficult to implement, which suggests such a system would be less than ideal. That's a valid argument, but the whole notion of not being able to target every wall tile from inside a room as a complete deal breaker is about as naive as saying no expanding shadows on single pillars is a deal-breaker. They are two different interpretations of Angband's dungeon model, and they both give rise to acceptable (IMO) gameplay.

[PaulBlay]

I guess I do not understand what point you are making. I agree that you can make visible walls in conjunction with expanding pillars consistent, if you are willing to violate one of the properties I suggested about passwall monsters.

Yeah, but what were those properties? That post must be over 10 replies ago as I can't see it from here.

[EDIT] OK, I think we're disagreeing on the definition of "visible wall". I am in favour of 'expansive walls' (as Marble Dice put it). Display on map of walls that "you'd think logically you'd be able to see" but where any (possible) content of those walls will not necessarily be known. This doesn't give the G in the wall any tactical advantage over just not being able to see the wall. It still can't see or target you, and you still can't see or target it (when it is in the theoretical shadow).

In other words I could say those 'additional' wall tiles are displayed but are not visible.

[EDITx2] Expansive walls are actually related to "wall memory".

Take this example:

#########%%%%%
  ....@....
#########%%%%%

Without expansive walls - walking down a dark corridor from the left. Walls are still displayed where he knows they were from earlier. He can't see monsters in the walls to the left any better than he can see them in the %'s to the right.

###########%%%
  ....@....
###########%%%

With expansive walls - walking down a dark corridor from the left. Same situation, only a couple more %'s are replaced by #'s.

########%%%%%%%%%%%%%
     .@..............
########%%%%%%%%%%%%%

Without expansive walls - our hero (with a torch) zaps a wand of light to the right.

#####################
     .@..............
#####################

Same situation with expansive walls.