YesNoOk
avatar

Reversed inputs upon landing (Read 5592 times)

Started by Mr. I, October 22, 2014, 11:52:44 am
Share this topic:
Reversed inputs upon landing
#1  October 22, 2014, 11:52:44 am
  • ***
    • Canada
I'm pretty sure this has been discussed somewhat before but I think it's best to start a new thread to try to keep discussion fresh.

Something that's been putting me off from using this engine is the way that MUGEN handles reversed inputs. Generally in almost all fighting games that I've played, when p1 jumps over a standing p2 and lands - commands should immediately be reversed once p1 touches the ground. MUGEN handles this differently as commands are reversed - only when p1 has been "turned" - either internally by MUGEN's autoturn, by facep2 = 1 or manually through a sctrl. This problem is present is ALL characters - take any Ryu, have p1 jump and cross over p2, as you are about to land input a hadouken - it SHOULD only come out on (numpad) 214 + P, but since you haven't been "turned" it will instead come out only on 236 + P.

Here are (failed) solutions I've explored:

1. Put facep2 = 1 in state 52
This was my original solution but it fails if a move is inputted and buffered before the player lands. This is because p1 is not "Turned" upon crossing over p2 and inputting 236 while airborne and pressing Punch immediately upon landing will trigger the wrong direction hadouken.

2. Reversed commands based on p2dist x

I think I first saw this one, or something similar to this, in Bluestreak by JEsuszilla.

Code:
[Command]
name = "QCF_p"
command = ~D, DF, F, x
...

[Command
name = "QCB_p"
command = ~D, DB, B, x
...

And in the -1, having:

Code:
[State -1, L Hadouken]
...
triggerall = ( command = "QCF_p" && p2dist x >= 0 ) || ( command = "QCB_p" && p2dist x < 0 )
...

This essentially creates the opposite problems as the previous solution. Reversed commands work perfectly when buffered upon landing, however once p1 lands, there is a time when p1 is being "turned" by MUGEN's autoturn. During that short period when p1 is turning, p2dist x is also being switched as well and it is during this time where p1 can input 236 + punch and result in a hadouken.

3. Custom variable based command buffer via helper

This solution is currently in Vans' characters ( Xiangfei_LB and Shingo_LB ). Looking at the buffering system, it is quite complex but simplified it basically has every button and motion mapped to different variables that are initialized to a number when performed and counts down acting as its own buffer system as well:

Code:
; This example code is out of order but arranged top to bottom to make it easier to read
[ Helper's Statedef ]

;initialize variable number
[State 10371, LP Init]
type = VarSet
trigger1 = command = "x"
var(0) = 3

[State 10371, QCF Init]
type = VarSet
triggerall = command != "holddown"
trigger1 = p2dist X >= 0 && command = "qcf" && command != "holdback"
trigger2 = p2dist X < 0 && command = "qcb" && command != "holdfwd"
var(21) = 13

; Counts down when initialized
[State 10371, LP Dec]
type = VarAdd
triggerall = root, HitPauseTime = 0 ;^^ root, HitPausetime = 1
trigger1 = var(0)
var(0) = -1

[State 10371, QCF Dec]
type = VarAdd
triggerall = root, HitPauseTime = 0 ;^^ root, HitPausetime = 1
trigger1 = var(21)
var(21) = -1

And in the -1

Code:
[State -1, L Hadouken]
...
triggerall = ( helper, var(0) ) && ( helper, var(40) ) ;basically both qcf and lp have to be performed
...

This helper is also bound to p1's head position, meaning that it will perfectly detect which side p1 is on and which direction must be performed to get the move.

Quite frankly, this code actually DOES solve both of the problems as being in a helper, it will bypass being buffered by pauses (hitpause, superpause, pause) and the reverse commands work perfectly. But it comes with one fatal flaw... There is a one frame delay that occurs when the motion is inputted. Theoretically, though I may be wrong, I believe this is because MUGEN processes states in the order -3, -2, -1 then other states. Since the helper is definitely not in state -1, it takes one extra frame for the QCF and LP variables to be initialized and therefore the changestate in -1 will occur 1 frame after the variables and the condition is met. In addition, helpers do NOT get access to -2 and -3.

4. Put Vans' buffering system in -2

This is where it gets funny. Basically copying and pasting Vans' buffering system (and sacrificing a TON of variables) it pretty much eliminates that one frame of input delay and we appear to be fine and dandy. Until you discover MUGEN's internal flaw which is that commands are automatically buffered during hitpause, pause, and superpause. This becomes apparent mainly when another character does a super and "pauses" or "superpauses" - your commands are literally eaten up and buffered by that pause. Basically during the time that p2 pauses, MUGEN will continue to read input and once the pause finishes, the move will automatically come out the very first frame that the game is unpaused. This may also be problematic if any character uses a move with a really large hitpause and if you attempt to apply negative edge, it basically means that the button release will be detected indefinitely.

So this is basically the problem that has pretty much discouraged me from MUGEN until Elecbyte releases a fix for all of this. There is one solution that I have not explored and that is eliminating autoturn via AssertSpecial and manually putting all of the turns in. Unfortunately this is something that I don't have the time for exploring so if someone does manage to do this and is successful, their code will be promptly stolen  ;)

Anyways, if you made it this far - thanks for reading.
The double-curse of Blue Beard Baboon lies in these words you see. Read them once, then read them twice and your island is history.
Re: Reversed inputs upon landing
#2  October 22, 2014, 12:04:03 pm
  • ****
  • play more SNK games
  • I FUCKING LOVE PLATINUM!
    • South Africa
    • www.trinitymugen.net/
Some fgs work like that, off the top of my head OMK does it.
Re: Reversed inputs upon landing
#3  October 22, 2014, 12:06:26 pm
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
My current CvS2 stuff does it without a buffering system.

Code:
triggerall = ifElse((Anim !=[5,6]), (command = "QCF_lp" || command = "QCF_mp" || command = "QCF_hp"), (command = "QCB_lp" || command = "QCB_mp" || command = "QCB_hp"))


... but I will be updating it with a buffering system soon anyway.
Last Edit: October 22, 2014, 11:38:54 pm by Jesuszilla
Re: Reversed inputs upon landing
#4  October 22, 2014, 11:38:49 pm
  • ****
    • Japan
Quite frankly, this code actually DOES solve both of the problems as being in a helper, it will bypass being buffered by pauses (hitpause, superpause, pause) and the reverse commands work perfectly. But it comes with one fatal flaw... There is a one frame delay that occurs when the motion is inputted. Theoretically, though I may be wrong, I believe this is because MUGEN processes states in the order -3, -2, -1 then other states. Since the helper is definitely not in state -1, it takes one extra frame for the QCF and LP variables to be initialized and therefore the changestate in -1 will occur 1 frame after the variables and the condition is met. In addition, helpers do NOT get access to -2 and -3.

Rather than a fatal flaw I think of it as a compromise.

Certain games already had some detection delays in their input systems or outright discard 1-frame button/direction detection. You could also technically argue that between ports, versions and hardware all versions of a game have different input delays, it's just something we have to deal with.

Following that thought, having every single command with a fixed delay of 1-frame is far from being the worst possible scenario. Input tricks and retained muscle memory still work, you just have to adjust your timing by 1-frame, which we already do all the time.
Re: Reversed inputs upon landing
#5  October 23, 2014, 12:54:34 am
  • *****
    • Peru
I understand the problem, but I want to ask why's that a problem. In some games thats a feature you use to get stuff you normally wouldn't, like pulling out charge moves after a crossup (SF4 engine comes to mind).
Re: Reversed inputs upon landing
#6  October 23, 2014, 01:01:09 am
  • ****
    • Japan
Because that's precisely what doesn't happen.

Upon landing MUGEN resets all command detection back, it's even worse for charge commands.

Suppose you're P1, jumping over P2 on the left side. If you attempt to do a landing sonic boom by holding right, landing and then pressing left and punch, it will not work. MUGEN reads that input as having buffered (charged) forward, back and then punch.

Actually the MUGEN charge bug would make this work. Let me mention a different scenario: P1 jumping over P2 on the left side, if you start buffering moves that end in a forward direction and finish with the forward direction (which would be left on your joystick) MUGEN will still detect it as a backwards motion.

MUGEN doesn't adjust its command detection in a turning transition.

Edit: Actually, let me rephrase that because I just had an epiphany.

MUGEN has a bug with charge commands, it doesn't matter which direction you're holding it will charge buffer your command anyways. It might have been a hotfix to prevent charged commands from failing during a crossup.
Last Edit: October 23, 2014, 01:10:48 am by Vans
Re: Reversed inputs upon landing
#7  October 23, 2014, 01:07:03 am
  • *****
    • Peru
I'm confused because op says the opposite. I haven't tested it, tho.
Re: Reversed inputs upon landing
#8  October 23, 2014, 01:09:50 am
  • ****
    • Japan
Upon landing commands work as if you had never turned around to face P2, ever.

This window is so big that it makes basic stuff like running/hopping work backwards.
Re: Reversed inputs upon landing
#9  October 23, 2014, 09:26:37 am
  • ***
    • Canada
I kind of have a bad habit of making things sound worse than they actually are. A 1-frame delay is a very fair compromise considering it pretty much solves the problem entirely. In fact I probably wouldn't even have noticed it if weren't for the first character that I was planning to convert to your system (Vans). Rufus' instant air dive kicks weren't as instant as I'd hoped.

I do have a few other ideas but for now it seems as this will stay unless Elecbyte does something about it.
The double-curse of Blue Beard Baboon lies in these words you see. Read them once, then read them twice and your island is history.