Pages: 1
I am using RPG Maker 2003 (with only David Patch) right now for my game Legend of Alkior. Basically, my current goal was to have an ability where you hold down a key (in this case the SHIFT key), for a specific amount of time and then you have to release it with proper timing. However, on occasions that almost seem random, the game will respond as if you had released the key when you definitely did not, thus resetting the amount of time you have to charge the ability.

For a visual of what my goal is, take a look at this demo I just released yesterday at about a minute in. It looks like I am missing the timings on purpose, but I am actually struggling with this bug of sorts. This "bug" will persist until something seemingly switches on/off. For example, I just found recently that minimizing the game while it's running will possibly change it from always resetting involuntarily to always resetting voluntarily and vice versa. If resetting voluntarily, the bar will increase until it hits the top and then decrease until it hits the bottom and then repeat until the player releases the key.

This is really strange. I have isolated just the one parallel process event that tracks how long you have been holding the button onto a separate map, and I also gave all parallel process common events that usually had no trigger switch a trigger switch that would never be turned on while testing this. This was to remedy what I *thought* was a problem of parallel processes interfering with each other while running in tandem.

The algorithm uses this basic structure. I am emulating a loop with labels to avoid extra lag:
<>Label 1
<>Key Input Processing (Shift key only; no Wait before proceeding; store in variable X)
<>If X is Shift key
<>Increment or decrement ChargeLevel variable
<>Update picture for Charge Bar
<>Wait 0.0 Sec (This is just enough lag that the bar will quickly move up/down at the right pace.)
<>Jump to Label 1

Any thoughts? Thanks in advance for the help!
Use a loop. Add wait 0.0 to eliminate lag. That tends to work best and it doesn't break on ya.
Best to add it before the end loop and after it - both sides of the loop command.

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.

Otherwise, I've no idea. Perhaps it's not reading the shift key press? Or maybe you need to make the initial wait command at least .1 so that it has time to process? Some times they take longer to process than the 0.0 gives.
Okay, I changed it to a loop with "Wait 0.0" before and after the "Break Loop" command plus an extra "Wait 0.0" after the loop itself...and it's still acting finicky.

This is unfortunate because I planned on each use of skills like this costing MP, but if the game lags or whatever, doesn't register the continued holding of the button, and resets on its own, then the player just loses MP upfront. I would have to make it so that you only lose MP if you release with a successfully high bar, and then it would be up to the player to aim properly at the target. (Gibmaker already suggested elsewhere that something like boulder pushing but with the power bar added is just a pointless barrier, but I also planned for other skills like it to be available that would put an enemy to sleep and then engage the targeted touch encounter for example.)

Even still, the game could act finicky and automatically release the power meter at its peak when you were not next to a touch encounter or other valid target, wasting precious MP in the process.
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.

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).
What I've done in the past to solve the problem myself is to have a kind of "buffered release".

Ooo, this really sounds like this would work, so I'll give it a go and report back later.

LATER: Well, it seems to be working as intended now! I haven't come across this same issue again (yet...). Thanks for the help! However, if any other action is going on (e.g. walking around) while charging then there is a little bit of lag, but I'm not sure if this can be helped.

Edit: Actually, I'm not sure about the walking lag even being there. If it is, it's probably more negligible than another source of lag that is coming from something regarding releasing the key. But I'm pretty sure it is separate from the issue mentioned in the OP.

Additional Question: Do you know if erasing a picture will create the same amount of lag as showing a picture?
As long as the event script with the charging is handled in a parallel process which is independent from other scripts, then it shouldn't cause lag.

Erase picture doesn't cost as much as show picture, since there is file loading involved in it.
I think it might have something to do with playing sounds or showing an animation right after, but I can't keep testing at the moment.

Edit: Huzzah! I located and managed to fix the source of this additional lag. I was calling a common event that contained a label loop that was missing the magic "Wait 0.0", which was needed because I was showing multiple pictures to update the mana bar for my ABS-type system. I also fixed the logic so that I would only ever have to show one picture one time rather than multiple, since before, I was tracking remaining mana from the minimum amount rather than the maximum amount, so I wouldn't have to keep updating the picture.

Anyways, thanks to both of you for your assistance! I can now proceed from here with smiles =)
Pages: 1