Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[serio]

not sure if that was by design or i'm doing it wrong, but this command:

Code: [Select]

[Command]
name="up"
command=U
time=1
will also work if you're holding up and tap forward/back/down.

i need a tap up command to replace the built in double jump since it's too clunky to use (impossible to disallow in specific cases, like after a specific command's done) and problematic (sometimes it just doesn't want to come out for no reason).

add that to kfm's cmd and then this to his -1:

Code: [Select]

[State *]
type=ChangeState
triggerall=stateno!=45
triggerall=pos y<-const(movement.airjump.height)&&var(02)=0
triggerall=command="up"&&statetype=A
trigger1=ctrl
value=45

holding up and tapping fwd or back will make kfm doublejump over and over.

[Cyanide]

I had this issue too inside Kirby. I worked around it by altering the command order and adding some extra Up commands in, it works now, but the underlying problem is still there obviously.

[Seravy]

I have the exact same problem except not with the UP button but the DOWN one.

If I release back faster than down after crouch guarding (happens often when you play on a keyboard), it registers and extra "down" keypress, resulting in a DDx attack coming out when I want to do DFx.

Additional tests with a defined down command showed that it is indeed always registering a down keypress when the back, forward, or up button is released while down is held.

I think it is safe to assume that a held directional key is detected as a new keypress whenever other directional keys get released. The bug is exclusive to directional keys and isn't related to the diagonal directions as it even happens with the up+down button combination. It only happens if the held key is the last one still being held, if there are 3 buttons held and you release only one, it doesn't happen, but if you release the second, it does.

I think this is a major problem because it affects gameplay in a negative way, cannot be avoided by coding, and affects a large number of characters.

[Byakko]

command = "up" ("U") && command != "fwd2" ("$F") && command != "back2" ("$B") ? Yeah, the diagonals likely detect a new key press UF and the key press UF thinks it includes U and F and considers both as new key presses. So maybe you can try rejecting the diagonal inputs ? (dunno what to do about the D+U case, though) Hoping it doesn't consider that self-contradicting (like command = "U" && command != "U")...

If I release back faster than down after crouch guarding (happens often when you play on a keyboard), it registers and extra "down" keypress

Well that's funnier.

I think this is a major problem because it affects gameplay in a negative way, cannot be avoided by coding, and affects a large number of characters.

On the other hand I feel like it's an intrinsic reason keyboard inputs feel easier than a pad. And more importantly, I'm also under the impression it might be something in the keyboards themselves, like, it's just how they work, and Mugen isn't responsible. What happens if you try the same thing with a pad that does have diagonals ? (at least for the diagonals and forget about D+U of course) Maybe pads recognize UF as its own unique input different from a combination of U and F. The test might be interesting at least for the "press" part - hold up, then move to UF and see if U registers again. I imagine that for the "release" part, holding DB then moving to D (releasing B) will recognize a second D input.

(then again this isn't valid for situations outside Mugen, like, I hold the "a" key, then hold the "e" key, and release one, it doesn't consider I've pressed "a" again...)

[Seravy]

I'm also under the impression it might be something in the keyboards themselves, like, it's just how they work, and Mugen isn't responsible.

No, that's impossible. I don't see the cursor moving down when I release the back button while editing text for example. This is a Mugen only thing.

On the other hand I feel like it's an intrinsic reason keyboard inputs feel easier than a pad.

It definitely makes the command easier to come out, especially if you include ~ or $ in front to make it detect releases, but it also makes the command come out when it is not intended, which is serious problem to the extent that I removed every $ and ~ from the front of all my commands.
It's really unfun when you can't walk forward and punch after crouching because it makes ~D,F,a performed instead, and this bug is basically the same thing except that it happens less often (only after crouch guarding when there is at least 1 tick of timeframe between releasing the buttons) but cannot be avoided in ANY way in coding that I know of.

[Byakko]

[Command]
name = "down"
command = D
time = 1

[Command]
name = "bck"
command = $B
time = 1

[Command]
name = "rbck"
command = ~$B
time = 1




[state -1, poof]
type = explod
trigger1 = command = "down" && command != "bck" && command != "rbck"
anim = 0
pos = 50, 0


With trigger1 = command = "down" alone : I get an explod when I hit D, I get nothing when I hold B when still holding D, and then I get something when I release B but still holding D. So that's the situation you're describing. I also conclude that serio's problem doesn't occur when pressing F or B but only when releasing F or B.
With trigger1 = command = "down" && command != "bck" : same thing as above.
With that I conclude with proof that it's just the "release" part that causes problem.
With trigger1 = command = "down" && command != "bck" && command != "rbck", I get the explod when I hit and hold D, I don't get it when I hit B while still holding D, and I still don't get it when I release B and keep holding D.
With trigger1 = command = "down" && command != "rbck" : same as with all 3 commands listed.
My conclusion at this time : the release of the other direction is the cause of the problem, alone. Proved through test.
Suggested solution at this time : reject the triggering when releasing any other direction than the one you want to hold (you probably want to throw in also release forward and release up if you want to trigger only on hit D). Solution verified through test in a specific situation. Suggestion to extend to whatever other situation you guys have.
I reckon that would give the same result for serio's version with a double jump on "up" alone and not tapping F or B. Or D.
Well, that's still not solving the cause of the problem which is likely hard-coded, but that's a workaround.
I'd also still be interested in knowing if anyone can test that with a pad.

Comment ? Is it enough ? Did I miss something ?

[Seravy]

Suggested solution at this time : reject the triggering when releasing any other direction than the one you want to hold (you probably want to throw in also release forward and release up if you want to trigger only on hit D).

Although this is indeed the only solution, it is technically impossible to do this for every command a character uses. Why? Because the commands are not just a single directional key.
For example, if the command is D,F,x with time=15, then you'd have to reject releasing those keys at the time D was pressed, which happens earlier than when the entire DFx command triggers, so you'd need to buffer all key presses and releases for 15 ticks and mugen obviously doesn't have enough variables for that, especially if you consider that some commands will have time=30 or even more, besides it way too complicated for a workaround.
So this is only possible for single directional key commands.

[Cyanide]

Mine was more along the lines of command = "up" where Up was simply U, implying to me it was a press and would not register again till released. Annoyingly i could tap forwards or backwards and cause it to activate U while holding the key down the whole time. I wanted forwards and backwards to have a purpose, i just did not want their release to cause an Up command.

Holdfwd + tap up should cause Up, hold up and tap forward should not cause Up.

I realise that makes a certain amount of sense but i would hope the keypresses were a little smarter than that. Up is held therefore it has not been pressed and "holdup" should be active, not the press indicated.

In the end i had

[command]
name = "fly"
command = ~U
time = 1

[command]
name = "fly"
command = ~U+B
time = 1

[command]
name = "fly"
command = ~U+F
time = 1

in the .cmd, which worked. It's still a bit stupid though. Or at least prevented the whole release F to achieve U problem.

[Byakko]

So this is only possible for single directional key commands.

Uh... Yes because it's exactly what was being asked here ? Well, there's the case where holding F, then tapping D will basically register a qcf and a dp motion. Is that abnormal ?
Look at a pad or a stick : if you hold F, then move down-forward, then release D, you're essentially coming back to F, even though it was being held since the beginning, your finger is still doing a qcf, so I don't see how it's a problem that it detects a new F input. It looks to me like it's exactly what's supposed to happen.
You're seeing it as a mistake because on the keyboard, you look at your finger and your keys, and you see that you are holding the "U" key all the time and you don't see why it should register a new press. But on a pad or a stick, that looks exactly how it's supposed to be. The "single directional key commands" in cases like serio's is the exception, and you can circumvent that the way I described.
In your case, you want to use that method specifically for your Dx move to avoid having it detected as a DDx move, but you precisely don't want to do it for your qcf-like moves.

[Seravy]

Well, there's the case where holding F, then tapping D will basically register a qcf and a dp motion. Is that abnormal ?

Surprisingly, I tested this scenario and it doesn't happen.Tapping D while holding F doesn't register a qcf attack for me, neither a dp one. I don't really understand why, but I wasn't able to define any qcf or dp command that actually triggers on this. The additional keypress on release thing probably only applies to the first key of the command.

It looks to me like it's exactly what's supposed to happen.

Give me a dedicated Guard button and I can actually agree with what you are saying.
However, as long as I hold DB with the intention of crouch guarding, I don't want it to register additional B or D keypresses at random when I stop doing it. (No, it's not possible to always release the two buttons at the same time. Even if there is only a 0.0001ms timegap between the two, they can end up being registered in different ticks if the next tick happens to start processing during that 0.0001ms.)
Back being the guard button is bad design anyway. If the opponent moves quickly between your front and back side, you can't guard properly as the back button keeps switching around on the keyboard. Same applies if he is directly above you when attacking, back might switch around right when you need to guard, making you fail guarding.

[Byakko]

If the opponent moves quickly between your front and back side, you can't guard properly as the back button keeps switching around on the keyboard

Well, that's this thing called cross-up, it's a pretty important part of games that use that guard system. It's designed that way - well, maybe it wasn't the very first time it appeared, but now it's a very large part of gameplay and strategies.

However, as long as I hold DB with the intention of crouch guarding, I don't want it to register additional B or D keypresses at random when I stop doing it.

So you can circumvent that specific situation with the method I described ? And you don't want to do it for everything else. If there's something that triggers by a press of B or a press of D, these specific triggers must be changed to implement what I posted above, so that they won't trigger when you're guarding with DB and release either/both directions.
holding DB, then releasing D, if you have something triggering on command = "B", just add && command != "~$D"
holding DB, then releasing B, if you have something triggering on command = "D", just add && command != "~$B"
well, use names obviously.
Tested and proved. What am I not getting with this ?

[Frederika Bernkastel~]

if this is a bug that only happens on keyboards as they are not supossed to be the primary input method for fighting games (really, when have you seen a fightng game arcade that ahs a keyboard, much less a tournament palyer bringign his keyboard to an event) i think this bug should be disregarded as low priority-do not fix.

I will try to replicate it on a gamepad during the weekend.

[serio]

my case registers on a gamepad too.

[Seravy]

if this is a bug that only happens on keyboards as they are not supossed to be the primary input method for fighting games (really, when have you seen a fightng game arcade that ahs a keyboard, much less a tournament palyer bringign his keyboard to an event) i think this bug should be disregarded as low priority-do not fix.

Mugen is a PC game engine, and the primary input device of a PC is the keyboard (and mouse). Maybe the most hardcore players buy gamepads for it, but the majority of players use the keyboard because that's the only thing they have. Buying new hardware for a single game is not something you can expect from people.

[Off]
Regardless, I have been considering to get one, so maybe this is the time to actually do so. I don't know much about them, though. Is something like this compatible with mugen?
Are gamepads really worth it? Is it easier to control the game with one?
[/Off]

I will try to replicate it on a gamepad during the weekend.

On a gamepad, you can't release one of the two diagonal buttons earlier than the other, simply because you either return the joystick to the middle (releases both), or move it to a single direction (counts as a new keypress which in this case is intended). There is no "I released back a milisecond earlier than down so I got an extra down press" situation on a gamepad at all because diagonal direction doesn't consist of two non-diagonal ones.
The behavior is correct on a gamepad, but incorrect for a keyboard.
If we could have true diagonal buttons defined on our keyboards, the problem would cease to exist, or more like, this behavior would be the correct one on both. (as you'd need to press the 1 button for crouch guarding instead of the 2 and 4 together)

my case registers on a gamepad too.

Yes, it should be like that on a gamepad. You can't hold the stick up and press another direction because you'd need to move the stick for that, and you'd be no longer holding up (but diagonal upforward instead), so moving it back to up would register up again. Unless, you have directional buttons that do the same thing as the stick on your pad, but in that case, you are essentially using a keyboard (not the stick).

[Byakko]

or move it to a single direction (counts as a new keypress which in this case is intended).

That's exactly the thing.

The behavior is correct on a gamepad, but incorrect for a keyboard.

I.... Uh... Well... What then ? It's how it's supposed to be, what now ? And yes, I do understand you say it's normal for a pad but it's not normal for a keyboard, I see the reasoning. But I don't see how that works in reality.