stop Angband from stacking commands

[Sky]

ok, i got to post this knowing what world of hurt will come out of it.

we need to stop the game from stacking / queuing commands; or in other words, when i take the finger off a button, it can not perform any other commands.

let's say i'm a Mage cleaning up a room of hounds - nothing even worth mentioning, just waltz in and hold whatever button is your Acid Bolt spell.

i kill the last hound, stop casting, and there's another dozen or so spells queued up that are cast to nothing.

(i was just doing a bit of flair there, it's not targeted spells that do this, only directional spells)

However, this applies to just about anything else, i really want only one command to be stored at any time.

double taps / holding a button for too long can too many times result in unjustified deaths. I don't think the UI should punish the player for the ergonomics he uses in game, but rather for his ingame decisions. If anything, the UI should help the player play the game, not set traps for him.

[Derakon]

Holding buttons down is going to get you killed, even if the game doesn't queue up commands, simply because something is going to come storming in while you're holding that button down, and kill you before you release it.

So basically, from my perspective what you're saying is equivalent to "I use a blender with the lid off to make my smoothies, but it makes an awful mess. It shouldn't make that mess." The solution is to put the lid on the blender, not to make a smarter blender.

[Sky]

but i am specifically speaking about commands that happen AFTER you have released a button. i have a setting for delay, i can tweak that. no need to patronize me when there is an aspect of the game that should clearly not be happening.

also, i'm kind of tired of hearing "holding buttons down" when the game is built in a way where it's begging you to hold buttons down.

[AnonymousHero]

but i am specifically speaking about commands that happen AFTER you have released a button. i have a setting for delay, i can tweak that. no need to patronize me when there is an aspect of the game that should clearly not be happening.

FWIW, I didn't see anything patronizing in Derakon's comment. I think you may be taking thinks a little too personally.

also, i'm kind of tired of hearing "holding buttons down" when the game is built in a way where it's begging you to hold buttons down.

You can use Shift+Arrow (aka "running") to avoid a lot of that. If you're already using running, then I may not be understanding what you want -- the later levels will kill you if you hold buttons down -- even if you configure a 5 second delay between 'actions'.

[Huqhox]

I think there are two issues here.

Firstly holding down a button being a good way to get killed. I don't think anyone is disputing that (although I learnt it the hard way). I use run to avoid the problem on movement and make attacks discrete button presses, which is just how I have always done it.

The second issue is that holding down a command key in Angband puts multiple commands into the input buffer; this is really a side effect of the way the input handling has been written and is a legacy of C input handling. Angband isn't the only game that suffers from this. I think what Sky is trying to say is that maybe when a key is reased the input buffer should be purged. Obviously this might have a bearing on how macros are handled and might not be easy to do. But I think there is a valid point that the game shouldn't continue to process actions if the key is not currently being pressed.

[PowerWyrm]

If you macro your Acid Bolt spell with [Escape]m3h', you can interrupt the extra castings with any key.

[Sky]

i have my keyboard set up with fast repeats; i need this otherwise in work and other games (Quake, mostly) so i'm not going to build a .bat to change it every time. other people who type a lot would probably have the same, i'm not talking about some ridiculous regedit with millisecond repeats, just set on Fast rather than Medium. keeping a key down has a very broad definition, and while in some cases i might do that (clearing a slime pit with MM) in other instances it's simply being too slow on releasing a key.

there is no good reason why the game needs to queue commands - it would work identically without it. it's just old coding from the 80s that could easily* go away.

[kandrc]

there is no good reason why the game needs to queue commands - it would work identically without it. it's just old coding from the 80s that could easily* go away.

The game does not queue commands. The keyboard driver queues keys so that the input is not lost if the system can't process the interrupts quickly enough. What you call "old coding from the 80s" is actually a very complicated problem. You can build a keyboard driver with unbuffered input, but then, when a cron job kicks off (or whatever the hell equivalent things happens in Windows land), you lose keys that you actually wanted buffered because you hit them correctly! Or you can configure your I/O library to discard buffered input when it pulls a single key code; this, in fact, leads to exactly the same problem. This type of "solution" can easily kill characters when the player literally did nothing wrong. And here you are, spouting nonsense about things you clearly don't understand, and claiming that fixing them is "easy", so that you can live through undisciplined fuck-ups of your own making.

Don't mash buttons. It's that easy.

[Sky]

you are telling me that

10 execute command
20 purge commands
30 goto 10

is too hard ?

[Pondlife]

Could you flush the keyboard buffer before accepting command input with:

fseek(stdin,0,SEEK_END)

[Derakon]

you are telling me that

10 execute command
20 purge commands
30 goto 10

is too hard ?

You would be amazed at how often something that is really easy to describe is really hard to implement. I don't actually know how hard purging pending actions is in Angband or in any program, but I could easily believe it to require super-low-level access to the operating system and a lot of clever logic around dealing with input.

Feel free to take a stab at doing it yourself and proving me wrong. I don't have a problem with making the game easier to use, just with your reason for wanting the change. But you're making the assertion that the thing you want is easy, without any evidence that it actually is.

[takkaria]

There is a difference between realtime games, where you expect a key to do something for exactly as long as it is pressed, and turn-based games, where individual keypresses represent discrete commands.

In realtime games, you can just scan the keyboard to see what keys are pressed many times a second and act accordingly.

Angband accepts discrete keypresses, whatever the OS passes it, so if the OS passes it 15 [f1] presses and [f1] is acid bolt, Angband is going to cast acid bolt 15 times. Angband doesn't know whether the key is being held down at the moment the command is processed.

It could find out, but in the case of a single keypress you don't want to do this check, because it might be by the time the game has processed the command the key isn't down anymore, which would lead to the game ignoring commands – unless the player holds down each command key for the precisely the right amount of time.

This 'is-the-key-down-right-now' check also wouldn't be helpful if you pressed [f1] three times in a row manually, but still faster than the game was processing those keypresses - for example because it's animating the previous acid bolt. In that case you'd lose keypresses you made intentionally.

You could imagine a check where if the current command is the same as the previous one, then you check if the key is held down. But then if you pressed [f1] two times in a row manually (as opposed to with auto-repeat), this wouldn't be the desired behaviour either. You could, I guess, take a note of the time when each keypress comes through and compare it to the time of the previous command, and if they're really close together turn on scanning behaviour. But I imagine that will be pretty error-prone too, and would feel pretty non-deterministic to the player.

The problem really with your request is that are two very different models of input processing here. Angband works on discrete keypresses; its whole gameplay revolves around this. You want it to be some kind of hybrid system where you can hold down keys and not worry about it, but honestly I don't see how it can work. It's not as simple as you seem to think it is.

[kandrc]

you are telling me that

10 execute command
20 purge commands
30 goto 10

is too hard ?

Spectacular! Code it up!

[Sky]

you are saying that the keyboard sends a bundle of messages, and that angband cannot tell if these messages happened before, or after it has completed a single operation.
i have to assume that in angband you have multiple actions, not a single action with various types attached to it (cast, move, quaff, etc). in that case, the purge would have to be added to each action.

derakon, the OS has nothing to do with it. it's the game that chooses not to ignore commands. if the game receives more-than-one command, let it receive them all and ignore all after the first. the OS only thinks the app is taking time to go through the queued commands if the app send interrupt requests.

if adding purge on each command is too much, you can maybe build a command buffer that ignores the stacked commands. i honestly haven't seen a game stack commands like angband since the 90s.

[Sky]

ok, let's be constructive. solutions, not problems.

you need have a list of commands, right?? e.g. press 8 -> move up.
what language is angband built in? C+ ? how does it stack commands? does it tell the OS "i have not finished with this command yet" , or does it actually buffer internally the commands? let's assume the former, your basic commands should look something like press 8 -> move up, getchar();
or char buffer[1].