How?(i have pondered thhis for a while and decided that key pressed<unicode of(numbers from 0 to 128)> was not good enough as in it can only detect alphanumeric keys
(ima go to sleep dont expect immmediate response)
If you want to detect every key:
It takes forever if no keys are pressed, though.
You can shorten this time by decreasing the number of Unicode generated.
You can save even more time by generating the list only once and keeping it in a global variable. Manifest constants, such as pi or this, are the main good excuse for using globals.
... except that FIND FIRST ITEM is what is taking up time
Generating a new list with numbers from (0) to (1114111) every time also takes up time, and converting each number as unicode to letter also takes up time. It's the same list item-wise every time, so it makes sense to generate the list once, and then find first item will be the only thing taking up time whenever the block is run.
Generating this list on a not-so-fast Windows laptop happens very quickly.
Oh. Right. This is a standard CS 2 data structures problem. Possible solutions, starting with the most complicated but fastest and ending with the least complicated but slowest:
-
Use a hash table. Several people have posted hash table projects. Possible pitfall: You have to be really careful that a-z don't all hash into the same slot. Time θ(1).
-
Use a balanced binary tree. Since you will generate the entire tree at once, you can make it perfectly balanced without need for any of the more complex algorithms to keep it balanced dynamically. Time θ(lg n).
-
Use a plain list, but when you find an entry, move it to the front of the list. Then the first few lookups will be slow, but after a while you'll find the common ones. You could prime the pump by putting the expected ones in front to begin with. Time θ(k) where k is the number of commonly used values.
It only takes a long time when no keys are pressed because it iterates through the whole list looking for a key pressed but doesn't find one. When a key is pressed, English ASCII characters are toward the beginning of the list, so it reports faster. Other characters might take longer based on their language and where they're located in the ASCII table.
if you can, it would be best to use the key pressed hat block, which can report what key is pressed if you set it to any key. you can keep track of the held keys by inserting the keys into a list.
Right, but even in the no-key-pressed case, you'll find out that no key is pressed in θ(1) or θ(lg n) time instead of linear time.
I said,use a custom block,not a hat
Or I would already use your plan because you alreadsy said this in another post
i don't think there's any fast way to get what key is pressed with pure reporters, there's just a lot of keys. what exactly is the situation? there might be something you can do to make your specific situation faster.
nvm,hats are ok
This way is kind of fast. It does take a little longer when no key is pressed, but it is still faster than @joecooldoo's solution, although it is slower for detecting regular keys.
Now, there is still a downside, when it detects no key, it outputs the unicode character for 0.
There is another issue for doing it this way, you can't detect keys like space, enter control, and keys that are more than just one character (and no, detecting the space character doesn't work). Not to mention, hundreds, if not thousands, of the characters that this script is detecting, don't even have a key on almost any keyboard. The best solution would actually to be to map out all the keys you need like this.
(place any modifier keys at the end)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.