So, you're trying to make the character move with both keyboard and mouse?
I don't see the point of having two control systems, players tend to use only one. For an action RPG i would go with keyboard, you can still use clicks for attacks and actions.

I think sometimes you want both because you don't know whether the player is playing the game using a gamepad or the mouse.

In starcraft, the smallest unit is always centered onto an isometric tile. In fact, the units are always centered on some tile unless they are in the middle of the moving animation. The animation are smooth using an algorithm. Units are in a determine tile at any moment in time. In fact, this is the basis of all Real-Time Strategy games. The step size in any RTS that I know of is an integer multiple of the smallest tile size of the board. Thus, the smallest tile size is a factor to the largest common factor of the step sizes. This setup allows the collision to be located on the map.

Units in every RTS games never go to where I click because they are always lock to grid. If you want the unit to go where you click, then there should not even be a determined step size because you cannot take half a step. Determined Step Size is the dimension of a tile. In other words, you're making multiple unsynchronized tile system. All RTS in history has chosen to implement only one tile system (of up to three layers hierarchy) to simplify the problem.

A fascinating read that might give you some ideas. I stumbled across it while searching for tiling in RTS games.

The Pac-Man Dossier: What Tile Am I In?

@loom_weaver: RTS does not have the CPU capacity to do it that way because there are a minority group of players (whom make up a significant amount of voters) that demand to have the latest graphics. However, the method used in Pac-man can be modify a little bit to check for position swapping to take away this effect that occur 1/60 chance. Since you're making RPG, the game will have more capacity to brute force information.

@arthurviolence: The method that loom_weaver has linked to is similar to the one you are trying to create. However, there is one difference, and that is the collision method.

In Pac-Man, each unit has to have one pixel as a reference point, and when this pixel is in a tile, the unit is consider in that tile.

In your case, you want to have the boundary of the image to detect collision. In other words, you're not making a tile based game. The tiles are only for easier map graphics and for fixed collision obstacles. Most game developers will create a rectangle for 2d or cube for 3d around their unit, and use those collision boxes.

However, it can also be brute forced by creating an algorithm that can outline the perimeter [2d] or surface area [3d] of the unit. Using the perimeter / surface area to detect collision is rather CPU intensive. However, sometimes you might need a "concentric" perimeter or surface area in case small objects moving too fast for the first layer to measure the collision. Having multiple concentric perimeters on the unit with each distanced away from the previous layer by less than the shortest length of the smallest object in the game will allow total collision detection, and it will also sense penetration of small objects, such as ammunition like an arrow or stone thrown by some monster or player.

Say the smallest object is a stone that's about 5x5 pixels with the corners cut off (to make it more round). Thus, we need to have one perimeter around the character at the boundary of the character. Next, we create a perimeter that's 4 pixels into the character. Then a third layer 8 pixels into the player. As many layers until we reach the center of the character.

Another way to detect collision is ray casting from 3d. With ray casting, if the object reaches a point where graphic overlap occurs, then there is collision; else, there is no collision.

Techniques to use in game programming:
Use 3d for 2d games
Use 4d for 3d games
Using an extra dimension to your game has some advantages.

The proper way is that all objects have to detect collisions at every moment in time, so the algorithm has to brute force at all times unless it can be optimized.

For path-finding, just use the step size to be the tiling grid that moves with you. In other words, just use the step size to path find using breadth first search with the search weighting forward movement more than turns, and turns more that backwards movement. Make the algorithm stop when you are a fraction of a step size to the destination since you cannot step smaller than one step size.