KAZESUI'S PROFILE

When you say you try that exact same event, do you refer to the one here or by GRS?
The one here lacks one tiny yet important detail. The code has to be put in a loop (label or regular). If you put the code here in a parallel process with no loop, you will find that at the end of the event, the code will wait for a frame ( 0.0 wait ) before it returns to executing the code from the start.
What this in effect means, is that you're not guaranteed that PlayerXY will take the same value as NewPlayerXY before it, which can lead to occasional step skips.

This should be fixed if you put the whole thing inside a loop, or if you instead of taking the coordinates of the hero, just let PlayerXY take the value directly from NewPlayerXY, given that you initiaize these four variables before running the step counter event.
If for some reason this didn't fix it, try reducing the 0.1 wait to a 0.0 wait.

author=Jparker1984
I was simply wondering how humans survived and dinosaurs didn't. I personaly feel that they were better suited for long term survival then us.

Dinosaurs lived for millions of years before going down. Humans haven't even done one million yet, and there are lot of reasons to believe we won't even make it to the first million.

So... where do you have proof that we're better suited for long term survival?

You're problem comes from a defect in how rm2k3 handles input from certain keyboards, not from the label looping (or the other looping for that matter). For some (not all) keyboards, it will not register you holding down the button, despite it being down, and thus cause a premature release.

What I've done in the past to solve the problem myself is to have a kind of "buffered release". Basically, check for key input multiple times with a 0.0 wait in between if the key has actually been released. If key is held down, you go straight to your usual code, if key is not held down you do another check and do the same thing. I would personally recommend having 6 checks with 0.0 waits in between, since that's about as fast as a player can react anyway ( 0.1 seconds ), and it makes a premature release very unlikely.
This of course means, that you should go back to using labels for your loop, since it just more reasonable than copy pasting the same code many many times.

author=Liberty
But yeah, with 2k/3 the Wait 0.0 is great for eliminating lag. I have no idea why it works because, frankly, it shouldn't - but it does.

The reason a 0.0 wait works, is that internally it will stop reading the event script for that frame as soon as it encounters a wait of any kind. In the next frame it will then check if the event has waited long enough. In the case of a 0.0 wait, this will be exactly 1 frame, i.e. 1/60th a second (assuming no lag is preventing the fps from staying at 60).

Indeed, fixed graphics and fixed direction does not work. The SDK does not give access to these event properties, so I'm unable to handle them accordingly (outside of adding more comment commands).

Transparency might not work at the moment, true. If you just want to use a picture as a custom background, you can do that by disabling the background however.

Adding more control over sprite offsets, so that the developer can manually control it is on my todo list for when I get time.

You will need to make your own custom background for that, using pictures and disabling the background.

As for rotation and direction, yeah it's a bit wonky at the moment. You can still fix this to a certain degree, by just eventing in your own movement scheme, which adjust in accordance to the rotation (with key inputs and move commands). I'm pretty sure that's what pepsiOtaku did for his airship.
Eventually, I would like to add a more free movement scheme, where up is forward, and the sides are simply rotate, more similar to how it actually worked in several snes games. But again, there's the issue of getting time to implement that, so don't expect it too soon.

Personally, I'm not sure I would say coding a custom battle system from scratch would be much easier Ruby than it would be to just event it. Of course, this is if you'd actually need something new, where you cannot just modify the old to accustom whatever system the person has in mind. Coding it in ruby would probably be a bit less tedious though.

I do wonder if you really are up for the task though, especially given the "not good with pictures" statement of yours. It's almost certain that you will want to use pictures for your system, a lot even.
Either way, assuming you're going for a menu driven system still, you could start by looking up tutorials on doing custom menus first, as they're going to be an important part of your battle system
here's one on a general menu:
CMS tutorial
and here's one on an item sub menu
Item menu tutorial

For the latter, and many many other aspects of a battle system, you will probably want to know a lot about pointers, so if you don't already know too much about them, you should look them up as well.
Pointer Tutorial

Since you've already aquired DynRPG, the DynText Plugin is probably going to do you a lot of good for a battle system, as it will allow you to show text for your menus, as well as numbers for damage and whatnot.

Something worth considering as well would be DynPEC, as it allows you to turn pictures into spritesheets, which you can then along with comment commands use for conveninet animation of the sprites. Will be in particular good for bigger enemies, as it would be easier to work with pictures than event graphics to deal with those.

If you can handle all of the tutorials above, I also have a project you might want to have a look at. It's a project containing a pretty old wip ffx-esque cbs intended for a tutorial. Only thing is that it was never finished, and as such, there's not a lot of description going on.
It is somewhat simple (for a cbs anyway), so it could be worth something in terms of reverse engineering. Only if you're interested of course.
I suppose that would also give a slight idea of what kind of work would go into a cbs.