KAZESUI'S PROFILE

You can do these by the help of using pointers.
Make a set of consecutive variables for the enemies (for example variable 51 to 55).
Make an event for each enemy, and at the start of a battle, store the event ID values in the variables from 51 to 55.

Now, use a variable which starts at say value 51. This value should go to 52 if you press the down button. let's say that in variable 52, there's the number 13 which is the ID of one of the enemies. You can make use of this to call an event page from that very enemy by getting that value and then have another variable with the correct page number as a value.
The page could just be like:
variable enemy screen x = this screen relative coordinate x
variable enemy screen y = this screen relative coordinate y
variable enemy screen x = + 16
show picture cursor at enemy screen x, enemey screen y

Now you can easily show which enemy you're targetting. Once an enemy is killed, say enemy with ID 13. you check if variable 51 has the value 13. if not, then you check variable 52 and so on. if you find it at variable 52, you take the value of variable 53 and store it in 52, and the one in variable 54 and store it in 53 and so on. This effectively removes the enemy out of the possible list of targets, so that you can only target living enemies.

If you're unfamiliar with pointers, then I strongly suggest you get familiar with them (tutorial link)
This all probably makes a bit more sense if you understand the use of them.

If or once you have a fair grasp of pointers, I could let you take a look at a CBS I have lying around with the intention of writing a tutorial on it at some point. It's rather WIP, but enemy targetting is fully functional.

Dijkstra's algorithm isn't and shouldn't be used for moving the player/actor if this one has already generated a move field, since the neccessary information for quick path finding should already be contained within this field.

The only actual need for the Dijkstra's algorithm is for the AI, which can't determine as easily where it should go, especially if the player units are far away. The AI would have to be able to think some moves ahead, meaning a normal move field wouldn't work for the AI.

If the AI being fairly stupid isn't a problem, you could do something fairly simple as just making the event move in the direction of the closest player unit. This will cause the enemies to seem retarded and get stuck every now and then, but it will be quick, and interesting games can still be made, with this being an example: link (it's even in german).
The AI in that game is rather stupid, but the game is still somewhat fun to play.

What you generally do for "charging" attacks, i.e. ones where you hold down a button for an amount of time is that you make use of key inputting without "wait until pressed" checked running in a loop until the key you're checking isn't held down any more.

Assuming rm2k3, it's also important to do multiple checks before accepting that the key has been released, since it will occasionally claim to have been released on lot of keyboards without it being the case.

Here's a sample project which should fit your description somewhat: Sample (assuming rm2k3).

The top left event handles everything of interest. It first runs on parallel process waiting for confirm key to be pressed, and activates a switch as soon as it does.
This switch triggers the next page which is an auto-start event, and thus stops the enemies from moving. This page sets a "Charge Counter to 0" and then starts iterating through a loop. The charge counter is there for the sake of differentiating between just hitting the confirm key, and holding it down for a longer time.
For each iteration, you increase the charge counter by 1 and do two key input processes. One only checks for the confirm button, while the other only looks for direction buttons. Both have "wait" unchecked.

You then use change the facing according to the variable used for key input of the directions, and you then check if the confirm button is still pressed with the other.
if it isn't, then you do the check a few more times with a 0.0 wait inbetween. If any of the branches say that the key is still pressed, you jump to the top of the event again, if not you check if the button was held down long enough, and execute whatever code you want to happen if yes. Then you turn the switch off and the event will return to page one and wait for key input.

Yes it does, doesn't it? And apparently this (less original) concept proved efficient. Which reminds me that I should mention the inspiration in the profile as well, thanks.

If you'd pay attention, you'd notice that the second video, i.e. the one with the 3D, is done in rm2k3, so the only thing you'd find would be event code pendling through tons of pre-rendered panorama/pictures.
Not a very good way to make 3D features in a game I might add.