stop Angband from stacking commands

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • takkaria
    replied
    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.

    Leave a comment:


  • Derakon
    replied
    Originally posted by Sky
    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.

    Leave a comment:


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

    fseek(stdin,0,SEEK_END)

    Leave a comment:


  • Sky
    replied
    you are telling me that

    10 execute command
    20 purge commands
    30 goto 10

    is too hard ?

    Leave a comment:


  • kandrc
    replied
    Originally posted by Sky
    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.

    Leave a comment:


  • Sky
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • Huqhox
    replied
    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.

    Leave a comment:


  • AnonymousHero
    replied
    Originally posted by 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.
    FWIW, I didn't see anything patronizing in Derakon's comment. I think you may be taking thinks a little too personally.

    Originally posted by Sky
    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'.

    Leave a comment:


  • Sky
    replied
    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.

    Leave a comment:


  • Derakon
    replied
    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.

    Leave a comment:


  • Sky
    started a topic stop Angband from stacking commands

    stop Angband from stacking commands

    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.
Working...
😀
😂
🥰
😘
🤢
😎
😞
😡
👍
👎
☕