About keyboard libraries

ID:1249568
 
Apr 28 2013, 10:10 am
(See the best response by Albro1.)
Problem description:
I was using kaiochao's keyboard library but I decide not to because the library had this "thing" that if I press and hold the button it makes the function(move, attack, etc) once, it stops for a whole second and then it start to repeat. I changed the library for the F_A's library, which does the same thing but worse.
It's something natural of BYOND or I'm really unlucky?

Oh...Kaiochao apparently doesn't have a page for his library(maybe he deleted?) and F_A's MIA as far as I know so I'm posting this here

Maybe I should say more of what I'm triyng to make...

I want to my game to be very "free" regarding movement and I want to have an easy way to create your own macros, and kaiochao's keyboard library was perfect when I saw it.
So if you guys could help me with this problem so I can continue using this library.
Or maybe I could switch to F_A's and search for a library just for the macros.
Apr 28 2013, 10:24 am
Best response
Make sure you aren't using any macro files of your own. You also may need to do some overriding. Look at forum_account's "movement-demo". I've used that concept and it's pretty smooth.
Apr 28 2013, 10:33 am
I just wanted to say that before blindly following an instruction to forgo libraries, read this.

Maybe you should forgo these libraries if you can't get them to work (So long as you put effort forth in following the way the library works), but don't get the idea that all libraries should be avoided.
Apr 28 2013, 10:50 am
It's pretty clear that what you're experiencing is BYOND's default key-repeat behavior. It goes by your keyboard. If you hold down a key, it appears, pauses for a short time, and then repeats. This is not specific to BYOND, as far as I know.

What you really should be doing to get smooth key actions is making a loop that checks what keys are down. A good keyboard handling library will have a list of keys ("keys" in F_A's lib and this post of mine), with each key associated to a Boolean value telling if the key is down.

@GS: Come on, now, that's unnecessary library hate. F_A's library (and my own snippet) has what you say he should have. He's just not using it properly.
Apr 28 2013, 11:07 am
I decide to use the movement-demo's way of handling keys.

Thanks to everyone!
Apr 29 2013, 1:21 am
Somehow I think I could point to a number of programmer failings that kill projects more frequently, well before I'd manage to point to poor or inappropriate library use. If you'd like a debate on this, I'd take it over to design philosophy (or as it should be called, given how frequently this comes up, design dogma).
Apr 29 2013, 2:45 am (Edited on Apr 29 2013, 4:27 am)
I currently use FA's library and know exactly what you mean and this pause is necessary in mimicking the delay while typing into inputs.

I actually even contacted Kaio about it and tried his loop approach but ultimately didn't like it (probably because my phobia of loops).

My solution is modifying the key down verb in FA's lib to include the repeat procedure and a if() to see if the user is chatting, and if so it applies a delay if not lets it run smooth.

This was a while ago but I think by doing this you need to disable the repeat function in the library, the one it comes with anyway. Not sure.

    // These verbs are called for all key press, release, and repeat events.
    verb
        KeyDown(k as text)
            set hidden = 1
            set instant = 1

            // if input is locked, we do nothing.
            if(input_lock) return

            if(!use_numpad)
                if(k == "northeast")
                    k = "page up"
                else if(k == "southeast")
                    k = "page down"
                else if(k == "northwest")
                    k = "home"
                else if(k == "southwest")
                    k = "end"

            // convert numpad keys to their actual symbols
            if(translate_numpad_to_numbers)
                if(k in __numpad_mappings)
                    k = __numpad_mappings[k]

            keys[k] = 1

            var/chatting_delay = 0
            while(src && focus && keys[k]==1)
            
                if(hascall(focus, "key_down")) focus.key_down(k, src)
                else CRASH("'[focus]' does not have a key_down proc.")  
                            
                if(chatting_delay==0&&mob.Chatting)
                    chatting_delay = 1
                    sleep(world.tick_lag*10)
                sleep(world.tick_lag)
Apr 29 2013, 3:39 am
In response to Jittai
I'm afraid something's wrong with your logic if you have a loop phobia and use goto. The system I wrote in the post I previously referred to is fine. There's only one infinite loop and it loops over everyone every tick. Optimizations could be made (like, skip mobs that don't have a certain key down) but it's pretty efficient already and it can't really get out of control.
Apr 29 2013, 3:51 am (Edited on Apr 29 2013, 3:57 am)
A phobia is a phobia for a reason, and that was mostly a joke. I don't really remember but there was an issue using the key-down-loop you suggested, not with the system itself but with what I was doing with it.
Apr 29 2013, 3:56 am
In response to Jittai
Still, keep your phobias to yourself. Don't need new programmers using goto around here, no sir.
Apr 29 2013, 4:17 am
Could be a while() I guess. Actually, since the repeat check only needs to be ran once it SHOULD be a while()... thankslol.

This is what happens when you code something and shove it away for half a year.
Apr 29 2013, 4:20 am
Apologies, I trimmed the post because I realised it wasn't 100% functionally the same. What I had was:

if (mob.Chatting)
    sleep(world.tick_lag*10)
while (focus && keys[k]==1 && src)
    sleep(world.tick_lag)


The case where it wasn't 100% functionally the same would be one where the mob was not chatting when you entered the loop, but then started chatting while you were inside the loop, causing it to sleep for longer. In my example, it doesn't do that.

By the sounds of it though, you wanted my behaviour?
Apr 29 2013, 4:24 am
Edited earlier post to use while() instead.

The delay only has to be applied once after the initial key press as with any chat-inputs. Which is why the "chatting_delay" is used.

You can even try it on these forums by holding down a key- FA's lib does this by default (perhaps unintentionally) when he has key_down transition into key_repeat.

This bugged the OP and me as when you're out of chat-mode or what ever your project has to communicate because when moving around or using other macros that delay could be annoying.
Apr 29 2013, 4:28 am
I find running a loop to check what keys you have down and executing actions based on the results doesn't give a delay.
Apr 29 2013, 4:42 am
If you're referring to Kaio's method I didn't say it did- FA's lib alone had a delay issue; Kaio's provision does not but it had other issues with the chat system I was using.
Apr 29 2013, 4:43 am
In response to Albro1
It shouldn't. A key is either up or down, and the flag is set on keydown and keyup; nothing happens with the default keyrepeat as it's the culprit here.
Apr 29 2013, 4:45 am
In response to Jittai
Keep in mind that it's the loop that does the work. FA's library can use the same exact code, as it also has the same functioning keys list (that's all it takes).
Apr 29 2013, 4:47 am
I just remembered the issue I ran into using Kaio's method. When chatting I needed the delay on input and it seemed simpler to just edit the key down. My chat system is all contained via on-screen images and objects so it doesn't use the interface's input.

Long story short- both methods work; for general use I would recommend Kaio's.