I was using the 'move at angle' action to make my sprite move in roguelike fashion (8-direction tile movement) when I ran into a very confusing issue. Logic didn't work.
I was using a 32x32 tile structure, so I used the Pythagorean theorem for the diagonals distance and half the angles for the direction, but for some reason it would not work right. Now...I am not the best at math so I figured it was my mistake and looped through it over and over trying to get it right, fiddling with the numbers in the slots, before noticing what it was doing. At some point I added background tiles to give me an idea of where it was going in respects to the tiles, along with discovering that for some reason far less than half the angle was closer to proper diagonal movement and 45.25 pixels was over shooting. So I went back to what should work with the tiles and I was surprised. Whoa. Instead of moving one up and one over for NE it was moving one up and two over! And nothing would fix it! Not without crude approximations that made no sense could I get the sprite anywhere near where it should be!
Until I discovered what was screwing it all up by accident.
I was also using WASD for a control scheme. People that have some familiarity with proper roguelikes might note that implies I was ignoring diagonals or had some usage of maybe QEZC or something to perform them, as I was not using the traditional numpad for it (or the vi keys). Nope. I was using shift as a modifier, so that while W, D, S, and A were North, East, South, and West respectively, holding left shift before pressing them made it North W, North E, South E, and South W instead. It was in a two condition event requiring that shift was down and one of the directional keys that I was using was pressed. For whatever reason that made all the difference and I realized using the same 90 degree increments and the same 32 pixels distance worked in these events. Even directly changing the position of the sprites coordinates (though I only got X+32, Y+0 to move NE) did so via diagonal. What the heck?
Why did including shift in my control scheme/event conditions make the 'move at angle' event work so oddly? Without it, the sprite moves as math dictates. If I had not gone into the project with WASD and the shift modifier in mind I would have never ran into such a problem and proceeded without confusion.
PS - I put this here because I figured shift did something I was unaware of and assuming a bug or something seemed precocious of a beginner