Allow targeting towards unseen squares

[dd]

This might be just me, but I've often times been annoyed that I can't target unseen squares when I'm firing a weapon or a wand.

For example, I want to hit several enemies with lightning bolt, and the only way I can get the beam to hit them all would be to target a specific square that's behind all the enemies, to get the right angle for the beam - but if that square happens to be unseen, I can't shoot at that angle, and if it's seen, I can. This seems counter-intuitive and inconsistent to me.

This also affects wands, for example wands of digging, if I want to make a path towards a certain place I often have to fire it while standing next to a wall. If I'm in a place where I can only see adjacent squares, I can only fire in 8 directions, but in a more open area I can fire in whatever angle I choose.

I think you should have the same options to target whatever angle, no matter where you stand.

[danr]

Weird, I was just noticing the same thing myself today, I was trying to get a mephitic cloud on something and couldn't - there was an angle which would allow it, but the end square that I had to target for that was out of range for the spell.

That was actually for a seen square though, it was just out of range.

I'm not sure if there's a rationale for the current behaviour, but it seems to me it would be an easy and significant interface improvement to just allow any square to be targeted and let the spell go as far as it can.

[crate]

You are allowed to fire at seen but out-of-range spaces (up to LOS range), try using !

[TGW]

Extremely niche consideration: hugeterm players would get to target at pretty much any angle, while normalterm players would be limited to fewer firing directions.

You're 99% right though, it shouldn't stop you from firing toward squares just because they're behind fog or walls. In particular, this would make digging in the correct direction much simpler.

[dd]

Extremely niche consideration: hugeterm players would get to target at pretty much any angle, while normalterm players would be limited to fewer firing directions.

How so?

[Galefury]

Because they have fewer places they can target. At the minimum terminal size you only get to see a square that includes LOS + 1. If the target you need to get exactly the angle you want is not inside that square, you cant shoot at that angle. I don't think this matters at all, though. Targeting could also be limited to LOS radius to avoid the problem.

[dd]

Because they have fewer places they can target. At the minimum terminal size you only get to see a square that includes LOS + 1. If the target you need to get exactly the angle you want is not inside that square, you cant shoot at that angle. I don't think this matters at all, though. Targeting could also be limited to LOS radius to avoid the problem.

But that only solves the problem partially - when the targeting is limited to an area it will still limit the angles you can shoot at.

Much better would be to allow targeting to scroll the screen, similarly to the (x) command.

[galehar]

No, we don't want to have to toggle map mode and aim at the other end of the level for the perfect angle. That's terrible.
Having LOS range instead of LOS sounds reasonable though.

[TGW]

Much better would be to allow targeting to scroll the screen, similarly to the (x) command.

You can't see the beam path if you're scrolled all the way across the level, though.

[XuaXua]

I do not like that beam path is inconsistent and malleable.

Take the example Player (X) of standing next to a wall with an opening in the wall at a distance and an open area to the side:

  Code:

.#####
.....X
......


SITUATION 1) If I want to hit a target (A), the beam (o) looks like this :

  Code:

A#####
.ooooX
......


SITUATION 2) If I want to a similar target (B) on the opposite side of me, the beam (o) looks like this:

  Code:

.#####
...ooP
Boo...


Due to pathing and situations, items can be in the path or not, but I don't get to choose the path.

Since SITUATION 1 obviously involves some sort of hook-shot, is it penalized? Probably not. Should it be? Not my call.

[njvack]

SITUATION 1) If I want to hit a target (A), the beam (o) looks like this :

  Code:

A#####
.ooooX
......


Since SITUATION 1 obviously involves some sort of hook-shot

It doesn't. The dungeon grid is just too low-res to show all the places stuff can be; they're big squares with a lot of room in them.

In your example, you have a direct shot on target A. No hook needed.

[The Mantis]

Can't you do this with Z . anyway...

[Galefury]

XuaXua: In wizmode you can cycle through the possible beam paths, but not in normal play.

[dd]

SITUATION 1) If I want to hit a target (A), the beam (o) looks like this :

  Code:

A#####
.ooooX
......


Since SITUATION 1 obviously involves some sort of hook-shot

It doesn't. The dungeon grid is just too low-res to show all the places stuff can be; they're big squares with a lot of room in them.

In your example, you have a direct shot on target A. No hook needed.

it'd go something like this

[XuaXua]

XuaXua: In wizmode you can cycle through the possible beam paths, but not in normal play.

I don't quite see why that has to be relegated to wizmode, other than some sort of programmatic concern.

[bobross419]

SITUATION 1) If I want to hit a target (A), the beam (o) looks like this :

  Code:

A#####
.ooooX
......


Since SITUATION 1 obviously involves some sort of hook-shot

It doesn't. The dungeon grid is just too low-res to show all the places stuff can be; they're big squares with a lot of room in them.

In your example, you have a direct shot on target A. No hook needed.

it'd go something like this

Ummm... couldn't the same exact argument be made for target B?

[galehar]

XuaXua: In wizmode you can cycle through the possible beam paths, but not in normal play.

I don't quite see why that has to be relegated to wizmode, other than some sort of programmatic concern.

You have to test several squares if you want to optimize your beam path, and people are already asking for more. Now, you want to be able to choose which path to take for each square? Do you really want to spend 10 minutes finding the perfect angle and path each time you cast bolt of fire?
Keep it simple. That kind of interface improvement just add tedium, not interesting decisions.

[bobross419]

XuaXua: In wizmode you can cycle through the possible beam paths, but not in normal play.

I don't quite see why that has to be relegated to wizmode, other than some sort of programmatic concern.

You have to test several squares if you want to optimize your beam path, and people are already asking for more. Now, you want to be able to choose which path to take for each square? Do you really want to spend 10 minutes finding the perfect angle and path each time you cast bolt of fire?
Keep it simple. That kind of interface improvement just add tedium, not interesting decisions.

I'd like this as well. By default spell path could just be like it is now, but for certain angles you could use an option key to switch to fine tune mode:

z{tab}f
vs.
zTjjjnf

Most of the time regular pathing is fine, but sometimes it just doesn't make any sense at all.