So, I've been working nonstop on a game i made where I'm trying to incorporate omni-directional movement, diagonal costumes and all, and i just can't get it to be smooth.

the character started out as 4 different sprites that followed a hitbox sprite that moved around the stage.
i designed the sprites to disappear (ghost effect 100) when an opposing arrow key was pressed. it was alright at first until i pressed two keys at once and
it all disappeared for a bit.

i fiddled around with it and then i decided to compile everything into one sprite. that seemed to work in regards to the sprite not vanishing, but i coded it to switch to an idle costume and the repeat the number of costumes there are in the animation, but if not pressing that key anymore during the animation loop, it switches back to the idle costume in the direction it was facing.

the problem with this if i press another arrow key with the same coding as the others it scrambles the animation loop and starts two loops at the same time, making a complete jumble until the loops stop. I have no clue what to do.

I hope i made this easy to read and comprehend.

here's the project if that's allowed: https://scratch.mit.edu/projects/1146351229/

My preference for something like this is to have a single script that changes costume. It then does so using a range of costumes according to the current state. So as a simple example if you had a sprite that had running costumes 1 to 5, walking costumes 6 to 8 and idle costume 9 you would set the min and max for the range of costumes according to what the sprite is doing. That way there can be no conflict since there is only one script managing costumes.

deck26 wrote:

My preference for something like this is to have a single script that changes costume. It then does so using a range of costumes according to the current state. So as a simple example if you had a sprite that had running costumes 1 to 5, walking costumes 6 to 8 and idle costume 9 you would set the min and max for the range of costumes according to what the sprite is doing. That way there can be no conflict since there is only one script managing costumes.

well, i just tried that and it seems to be slightly better, the biggest issue is diagonal movement. its a whole new problem when i have to use two arrow keys at once,

i have a script that activates the animation when pressing left. now i code the function left and up. now when i press up and left at the same time it processes that i pressed the button for left cycle.

i've tried the And block and Not block

<<> and <>>

<not <>>

but that doesnt work either

All depends how you handle the key input (assuming no hardware conflicts). For example you could use 10 for right arrow and 20 for left arrow and 1 for up and 2 for down. Add the codes and you only have a limited number of valid codes of the form XY.

If either X or Y is 3 you can ignore that part of the code since the keys cancel each other out. Just subtract 30 or 3 if that is the case. You then have one of 8 codes

1 / 2 - up or down
10 / 20 - right or left
11 / 12 - right and up/down
21 / 22 - left and up/down

So you check all the keys, produce the code and then set the mode accordingly. If the mode hasn't changed from the previous value leave the costume loop to do its work. If the mode has changed set the min and max and the costume script will do the rest (it should set the costume to the min of the range if adding 1 to the costume takes it outside the range which neatly handles the loop restart as well).

deck26 wrote:

All depends how you handle the key input (assuming no hardware conflicts). For example you could use 10 for right arrow and 20 for left arrow and 1 for up and 2 for down. Add the codes and you only have a limited number of valid codes of the form XY.

If either X or Y is 3 you can ignore that part of the code since the keys cancel each other out. Just subtract 30 or 3 if that is the case. You then have one of 8 codes

1 / 2 - up or down
10 / 20 - right or left
11 / 12 - right and up/down
21 / 22 - left and up/down

So you check all the keys, produce the code and then set the mode accordingly. If the mode hasn't changed from the previous value leave the costume loop to do its work. If the mode has changed set the min and max and the costume script will do the rest (it should set the costume to the min of the range if adding 1 to the costume takes it outside the range which neatly handles the loop restart as well).

I think i figured it out. instead of figuring out how to make one sprite sense key movement to appear, i've made it be determined by costume name on either sprites, so they know when to disappear and reappear.

It would probably be better to change costumes based on the direction of the sprite/hitbox and not the key presses. Just make sure the hitbox/sprite is set to not rotate (as in, not rotate visually).