|
|
metadata
I’m working on a game in a small team and everyone who tests the game sometimes has their keys sticking and they have to fiddle around to fix it again. This isn’t occurring for me though, so it’s really difficult to debug since I can’t even recreate it. Is this kind of issue common within flash? I think I’ve heard about it, but I’m not exactly sure.
Thanks.
|
|
|
|
|
metadata
|
|
|
|
|
metadata
> *Originally posted by **[Feffers](/forums/4/topics/322190?page=1#posts-6781609):***
>
> I’m working on a game in a small team and everyone who tests the game sometimes has their keys sticking and they have to fiddle around to fix it again. This isn’t occurring for me though, so it’s really difficult to debug since I can’t even recreate it. Is this kind of issue common within flash? I think I’ve heard about it, but I’m not exactly sure.
> Thanks.
Show us your keypress code- it’s likely one of the if statements is butchered.
|
|
|
|
|
metadata
> *Originally posted by **[saybox](/forums/4/topics/322190?page=1#posts-6782046):***
>
> Are they using IE?
Tried both firefox and the standalone – same result.
> *Originally posted by **[RTL\_Shadow](/forums/4/topics/322190?page=1#posts-6782090):***
>
> Show us your keypress code- it’s likely one of the if statements is butchered.`
stage.addEventListener(KeyboardEvent.KEY_DOWN, keyDown);
private function keyDown(ev:KeyboardEvent):void {
if (ev.keyCode == asciinum) {
//move
}
}
`
Simple booleans when key down and key up to put on enterframe and move the character.
Not exactly sure what you mean by butchered.
|
|
|
|
|
metadata
That code doesn’t work smoothly for key presses. You should use a system of booleans and check what keys are down on `EVENT.ENTER_FRAME` if you plan on having a non-stuttering movement.
|
|
|
|
|
metadata
I agree with UG on this one… When I first started out, I did it the same way as you are doing it here… It caused problems when pressing more than one key at a time.
I usually make some event listeners for key up and key down, and then have a boolean for each relevant key that I set to true if down, false if up – then just check for those in the enter\_frame.
|
|
|
|
|
metadata
I think you guys misunderstood, that’s what I am doing.
|
|
|
|
|
metadata
Based on the code you posted, it is not what you are doing.
|
|
|
|
|
metadata
The code I posted was displaying how I captured the key inputs. Below it I said I was setting booleans to true/false depending on keyDown or keyUp as well as putting it on an enterFrame event to move the character.
|
|
|
|
|
metadata
Given the comment “// move” the more probable code there might be was exactly “move by function” and not “set a boolean”. You have not provided enough code for a qualified decision.
|
|
|
|
|
metadata
Alright, I’ll admit I made a typo. Pseudo on what I’m doing:
`
var rightKeyDown:Boolean <- false;
//keydown event listener
if ev.keyCode == right {
rightKeyDown <- true
}
//keyup event listener
if ev.keyCode == right {
rightKeyDown <- false
}
//enterframe event in character class
if rightKeyDown {
x += speed
}
`
That’s how it should be done, right? To elaborate with the _actual_ problem, I myself am not getting any sticky keys, it runs smooth and nicely. However, 2 other people who have tested it can recreate the issue where if they hold, for example, the right key down, then hold the up key down, quickly switching to go left will result in them going up/right only stopping when they have put the right and up key up again. It doesn’t happen all the time, but they are able to recreate it.
|
|
|
|
|
metadata
What kind of keyboard do they have? It could be a problem with the mechanics of their keyboard. Some (cheap) keyboards apparently are built so that they can’t respond properly to multiple keypresses/keyreleases (I forget the anachronym for the number of simultaneous keypresses a keyboard can handle).
If it is not that, there are two other possibilities (from what I’ve read): security settings (most notoriously IE’s protected mode) and key repeat settings. I hypothesize that they are both symptoms of the same cause, however (being the way Flash handles key input processing — see the post by chriskallen1 in [this thread](http://www.kongregate.com/forums/7/topics/32448?page=6). Unless you have a lot of listeners or something, I would’ve thought how you’re doing it would be fine — though I would put ev.keyCode into a dedicated var rather than access ev’s keyCode for each test. Also, I thought I read somewhere that assigning priorities to your listeners can be of some help (rather than using the default, give a higher priority to the keyup listener and the keydown listener)).
|
|
|
|
|
metadata
@Feffers: [Here.](https://github.com/skyboy/AS3-Utilities/blob/master/skyboy/ui/Key.as)
You’re already on the right track, so unless you want to make your own key listening class for practice, you might want to just use skyboy’s version instead.
|
|
|
|
|
metadata
Thanks a lot for the responses, I’ll look into it.
|
 "Feffers"){kind=small}
 "saybox"){kind=icon}
 "RTL_Shadow"){kind=avatar}
 "UnknownGuardian"){kind=small}
 "Danishdragon"){kind=small}
 "Drakim"){kind=avatar}
 "vesperbot"){kind=small}
 "dragon_of_celts"){kind=small}
 "Aesica"){kind=small}