I'm using a standard method to move a sprite up and down with the arrow keys:
when green flag clicked go to x: -220 y: 0 set "speed" to "10" forever if (key "up arrow" pressed?) point in direction 0 move (speed) steps if (key "down arrow" pressed?) point in direction 180 move (speed) steps endMy problem is that if I'm holding down either the up or the down arrow to keep my sprite moving, and if I press any other key while doing so (for example, the spacebar to fire a laser or something) what happens is that the sprite will continue to move in the direction it was going, even if I stop pressing the arrow.
Offline
Add a "Until <NOT (up arrow pressed)>"
Right now, you are telling it that if the up or down arrows are ever pressed, to FOREVER keep moving up/down.
Offline
A good idea, but it doesn't change the behavior. If I'm moving up (or down) and press the space bar, the sprite continues moving in whichever direction, even if I stop pressing anything. If it is stuck moving up, and I press down, it will pause, and then resume its upward motion when I release down. The only way I can find to stop the upward motion is to press up again.
Offline
This sounds more like a problem with your keyboard than the scripting. Some keyboards stick when three or more buttons are pressed at the same time, unfortunately. However, if you include the scripting for the actions that happen when you press the spacebar, maybe we can find another problem and fix it.
Maybe you could post the full script here?
Last edited by Kileymeister_test (2013-01-04 17:09:43)
Offline
My keyboard is brand new (as is the laptop it is attached to), so I hope it's not sticking.
Here is the firing script, attached to a bullet sprite:
when [space] key pressed if ((this) = (bullet)) set "ghost" effect to 0 go to s[ ] repeat until (touching s[ ]?) move 10 steps set "ghost" effect to 100 go to s[ ] end"this" is a variable private to the bullet sprite; part of an implementation of a primitive queue (so that I can fire multiple bullets. All of that is working correctly.
Offline
Sorry, this is the correct script, not the previous one:
when [space] key pressed if ((this) = (bullet)) set "ghost" effect to 0 go to s[Sprite1] repeat until (touching s[edge]?) move 10 steps end set "ghost" effect to 100 go to s[Sprite1] end
Offline
mythbusteranimator wrote:
Add a "Until <NOT (up arrow pressed)>"
Right now, you are telling it that if the up or down arrows are ever pressed, to FOREVER keep moving up/down.
No - what he's doing right now is checking, every frame, whether the arrow keys are pressed, and if so, move a bit in the corresponding direction, giving the illusion of constant movement.
...And that is correct, so I don't know what the problem here might be.
Offline
@mythbusteranimator, love you signature (C)
Offline
First of all, why is the second if inside the first one? Did you mean to do that, or did you just transcribe it wrong?
Try this (if it isn't what you're using already). It works for me.
when green flag clicked go to x: (-220) y: (0) set [speed v] to (10) forever if <key [up arrow v] pressed?> point in direction (0 v) move (speed) steps end if <key [down arrow v] pressed?> point in direction (180 v) move (speed) steps end end
Last edited by -Stendika- (2013-01-04 20:24:56)
Offline
Oh, yes. This problem again. @OP: Do you happen to be on a Ubuntu computer? Because I have this glitch too. Don't worry, you can still post the game and the glitch will stop happening on the web. It's not a scripting problem, but a problem with Scratch itself. Now to mention it, I hope Scratch will fix this bug.
Offline
I am indeed running Ubuntu 12.04, and I had pretty much decided to chalk this up as a glitch beyond my control (I've tried a few other methods of managing the events in question, all with the same results). It's good to have confirmation of my suspicion.
And @Stendika, yes, my transcription was a typo. I just pasted the relevant portion of the project summary without too much fiddling around.
Thanks, everyone, for your input.
Offline