-Try going into the plugin manager and disabling Quasi Movement and then running your game. Does it still do this? If it does, the issue is elsewhere.
-If you find that it only happens when Quasi Movement is on, have you altered the plugin in any way?
-Even if you haven't altered it, try downloading it again and replacing the copy of the plugin with your freshly downloaded copy.
-If it still does it, try creating a new project, adding Quasi Movement to it and then seeing if it happens again. If it doesn't happen on your new project, it is likely that something was messed up with your old project.
-Lastly, have you tried anything more advanced with the plugin and are trying to use script calls, or is this just a barebones thing?(Barebones=vanilla map with vanilla everything, the only fancy thing you've got is Quasi Movement). If you are using script calls, it could be possible that you have entered something incorrectly and have messed something up that way. Try getting rid of your added script.
-If it still happens, than unicorns exist, and at that point you should send me(i don't mind checking it out) or Quasi(assuming he is willing) your project to look at. But honesty, if you follow what i wrote above, it should fix it.
@shaynec1981 I think what he is trying to say, if I am wrong, correct me, is that that game was built based on, and optimized for, grid movement & collision. Non-grid based movement is made available via plugins but isn't optimized for the game engine when published.
Think of it this way:
Grid and Pixel based movement are both technically based on a grid, one is just a lot simpler than the other. Lets compare it to the game battleship(hopefully you have played this game as a kid). When playing with a traditional board, finding ships is not all that difficult, you just say A-5, or C-8 and so on until you find the enemy battleship, this game is made playable(time wise) by the fact that it has a small grid and therefore only so many combinations. Now imagine playing battle ship and the grid is around 600x600 in size totaling up to 360,000 different squares, this is going to increase the game time significantly because the amount of combinations.
When pathfinding is active the computer is trying to find the best non obscured route to a determined point and when it is on a small grid(10x10 maybe), there are only so many possible paths, so it is easy for the computer and game engine to find the best path. But when the game is using pixel based movement and collision, the grid is significantly larger and there is a massive increase in the number of paths it could take, so finding the best path is much harder given that it is supposed to figure it out in milliseconds AND that the engine was not built or optimized for it.
Something that might work is if you were able to find a way to simplify the collision grid for pathfinding, but that might not even speed things up to the extent that it is playable. I have seen other game engines set auto pathfinding via nodes like so:
If you had something like this, it would perhaps solve the issue of pathfinding while retaining the awesome collision maps on Quasi Movement. I have no idea how you might do this except to make the nodes with events and then having a node be defined as your mouse. You could see if you could get to your mouse in a straight line and, if not check what node it could get to instead. But this might have performance issues too, @shaynec1981 this is just an idea you could try.