New command: (h) fires default ammo at nearest target

[d_m]

I added this command while testing the quiver and found it really nice. If people think there is too much "feature creep" I can take this command out, but I do think it does what one wants "most of the time." It's available in r1805.

The "default ammo" is the ammo in the lowest numbered slot of the quiver. This command won't fire ammo out of the inventory; if there is no acceptable ammo in the quiver, you'll get a message like "You have no ammunition in the quiver to fire." If there is no closest enemy, you'll be asked if you want to fire anyway (like if you use f on an out-of-range target).

Once one gets used to this feature, the next thing one tends to want is a way to distinguish the "in range" squares from the "out of range" squares visually.

Thoughts?

EDIT: I should say that I plan to update the documentation to include this command if the community ends up liking it. Otherwise I will just remove it again.

[Atarlost]

Why not add this as a default keymap instead of a C level command?

[d_m]

Why not add this as a default keymap instead of a C level command?

The big advantage is that it prints many fewer messages. But it's a fair point.

[SaThaRiel]

Sounds good - but i fear that i will end up in front of a wall running towards west

[Magnate]

Once one gets used to this feature, the next thing one tends to want is a way to distinguish the "in range" squares from the "out of range" squares visually.

Someone else suggested this in another recent thread. Personally I think it's high time all the view_wibble_lite options were rationalised, and if there's enough interest I think a slightly different colour for in-range lit squares (and unlit, maybe?) would be good. I guess it's going to depend on the long-awaited 256-colour feature as well, as I don't think we have enough colours for all the lights otherwise:

never seen
remembered as dark
remembered as lit
in-LOS lit
in-LOS dark (not sure if these two are distinct depending on current options)
in-light-radius
in-range lit
in-range dark

... that's starting to encroach on monster colour territory.

[RogerN]

What if rogue-like commands are enabled? (h) was already in use in that case (move left).

[d_m]

What if rogue-like commands are enabled? (h) was already in use in that case (move left).

That's a good point. Maybe I should use "x" instead? There aren't a ton of keys that aren't already taken!

I had forgotten that I needed to protect the rogue keyset.

[SaThaRiel]

What if rogue-like commands are enabled? (h) was already in use in that case (move left).

Actually thats what i was trying to say

[RogerN]

That's a good point. Maybe I should use "x" instead? There aren't a ton of keys that aren't already taken!

Heh, strike two... (x) is the look command in the rogue-like keyset. You may need to use different keys depending in the keyset.

[d_m]

Heh, strike two... (x) is the look command in the rogue-like keyset. You may need to use different keys depending in the keyset.

Clearly I need to read up in the code on how the keysets work. You're right that the roguelike set might need to use a different key. What key(s) would you recommend for this?

[Marble Dice]

Someone else suggested this in another recent thread. Personally I think it's high time all the view_wibble_lite options were rationalised, and if there's enough interest I think a slightly different colour for in-range lit squares (and unlit, maybe?) would be good. I guess it's going to depend on the long-awaited 256-colour feature as well, as I don't think we have enough colours for all the lights otherwise:

never seen
remembered as dark
remembered as lit
in-LOS lit
in-LOS dark (not sure if these two are distinct depending on current options)
in-light-radius
in-range lit
in-range dark

... that's starting to encroach on monster colour territory.

Do you really need a constant visual indication of range? Seems like a green or orange line or field when you enter into get direction or targeting mode would be enough. If you want to see the range on your bow, hit fire and see what gets highlighted. Something like this would be handy to have for any ranged attack - be it weapon, spell, or wand.

Not to say that you can't rationalize the view_lite options - I always turn them all on, but IMO the important ones are remembered lit/dark, in-LOS lit, and to a lesser degree torchlight. I don't think you can tell what's in-LOS remembered dark, but I might like it if I tried it.

[Magnate]

Do you really need a constant visual indication of range? Seems like a green or orange line or field when you enter into get direction or targeting mode would be enough. If you want to see the range on your bow, hit fire and see what gets highlighted. Something like this would be handy to have for any ranged attack - be it weapon, spell, or wand.

But ... the whole reason this has come up is because we now have a single keystroke fire command, so you need to know what's in range before that single keystroke!

[Marble Dice]

But ... the whole reason this has come up is because we now have a single keystroke fire command, so you need to know what's in range before that single keystroke!

I think I'd rather get a "There are no targets in range." message than constantly see a visual indication. Maybe it wouldn't look too bad if it were like the detection radius - a slightly discolored line of tiles at the threshold. I've had a single keystroke fire macro for years, and if I could just see the range by going into the fire prompt, that would be perfect for me.

[PowerDiver]

Is there really a need for another command? Most of the letters are taken, and there may be future demand.

Why not have a set of default macros tied to the F* keys?

[andrewdoull]

Someone else suggested this in another recent thread. Personally I think it's high time all the view_wibble_lite options were rationalised, and if there's enough interest I think a slightly different colour for in-range lit squares (and unlit, maybe?) would be good. I guess it's going to depend on the long-awaited 256-colour feature as well, as I don't think we have enough colours for all the lights otherwise

Based on the lack of free time I have at the moment, I'm in no danger of getting to this soon. It shouldn't be too hard to reintegrate the patch I wrote... I believe there was one clash between the colour table variable name I used and a couple of *Nix platform specific tables.

UnAndrew