YesNoOk
avatar

Refining a Guard Crush System Code (Read 1647 times)

Started by Nep Heart, November 18, 2018, 09:51:11 am
Email this topic
View printable version
Share this topic:
« previous next »
Page 1 of 11   Go Down

Nep Heart

Refining a Guard Crush System Code
#1  November 18, 2018, 09:51:11 am
  • ****
  • CPU Purple Heart
    • USA
    • https://www.pixiv.net/en/users/8108265
 For the most part it is complete and has been complete for some time, it even works as intended... most of the time. I chose to ignore it since I didn't think it would be too recurring, but it's been getting on my nerves recently and I wanted to finally get it resolve. The main issue I've been having is while it does indeed put the opponent in guard crush state, it doesn't do it consistently. Sometimes, it'll just fail to put the opponent in the guard crush custom state altogether at random.

 It doesn't happen often, but still annoying and getting it fixed would be ideal.

 I'll provide the coding below so any of you can point out the flaw causing this problem.

Spoiler, click to toggle visibilty

 The system being monitored in -3.

Spoiler, click to toggle visibilty

 This is so that helper attacks can properly guard crush the opponent.

Spoiler, click to toggle visibilty

 The guard crush custom states.
Last Edit: December 04, 2018, 09:49:45 pm by Nep Heart

Odb718

Re: Refining a Guard Crush System Code
#2  November 22, 2018, 09:14:37 am
  • *****
  • Shame on you!
    • USA
one thing you'll want to do is add triggerall = to make sure the var you're setting doesn't actually already = the value you're setting it to. It just wastes mugen's time kinda. Could resolve some hiccups. Stuff like
Spoiler, click to toggle visibilty

My main suggestion, is your
trigger1 = (GameTime % 30)
fvar(3) = 3
is kinda slow. Use gametime%10 and fvar(3) = 1 so it happens 3x as often, but at exactly the same rate. ignorehitpuase is needed for sure, but mugen can skip over some stuff randomly.


When the guard crush doesn't fire off, what's the value of the fvar(3) and var(11)?
Honestly, reading the code and getting down to the end, I thought you'd be monitoring fvar(3).
The fact that you're using whole numbers and fvar may be messing things up slightly.

BUT
out of all of that, I think it comes down to an ordering problem.
Spoiler: Your reset code should go last (click to see content)
If all the values are firing off with the current attack, you might have the attack set the values to reset everything in the first tic. Your targetstate may never get the tic to fire. I'm not 100% certain of any of this. It's 3:10am and I just worked a double. But that's a few things I'd check.

I'd rerun exactly what you have now, and watch those variables closely. Try to record the values on a couple fails to see if there's some consistency in the mess-ups.
After that, I'd drop the reset to be last. If the mess-ups happen more or less, see if the two vars have different values and see if you can think of some reason why.
vVv Ryuko718 Updated 10/31/22 vVv

Nep Heart

Re: Refining a Guard Crush System Code
#3  November 24, 2018, 12:33:56 am
  • ****
  • CPU Purple Heart
    • USA
    • https://www.pixiv.net/en/users/8108265
 Sorry about the late reply, got sidetracked with some offline tasks, but anyway...

 fvar(3) is being used for the modifyexplod for the guard crush meter while var(11) is what the actual guard crush system use to keep track of the entire system. I just have fvar(3) there to be read by var(11) so that the meter on-screen drains/restores smoothly.

 var(11) initiates the guard crush states whenever it reaches 1000 or above, but always starts out at zero.

 I'll give these suggestions a test nonetheless and report what changed.

Nep Heart

Re: Refining a Guard Crush System Code
#4  November 26, 2018, 12:59:32 am
  • ****
  • CPU Purple Heart
    • USA
    • https://www.pixiv.net/en/users/8108265
 Alright, I'm getting somewhere with this as far as those suggestions go. Couldn't really put the variable reset last, however, since that caused an infinite custom state loop, but changing trigger lines to delay the reset worked. So, now, at least non-helpers make the custom state activate more consistently now.

 ... Only issue is that helper attacks still don't guard crush consistently, but I've narrowed down the issue pretty quick. The helper that induces the guard crush gets destroyed too soon (they're set to destroy themselves the moment the opponent is no longer in any kind of hitstun or guardstun to allow the combo meter to read the hits properly). So, I need a solution to substitute root,var detection in helpers. Also, the "1 frame behind" thing with helpers could also be the issue on top of that?

Odb718

Re: Refining a Guard Crush System Code
#5  November 26, 2018, 02:04:50 am
  • *****
  • Shame on you!
    • USA
If you need an additional few tics, my cheat is to create a blank animation and use that.
So all the destroyself get changed to changeanim.
Then a new destroyself is made to check the animtime of the blank animation.
May be your simplest way to fix this. Might not be the best way, but I know I do this little cheat pretty often so my "fireballs" "combo". Having helpers die too quickly can mess up a bunch of things.

There's the method of creating an explod so grandchildren can get past the 1tic lag. You might want to look into that method.

(they're set to destroy themselves the moment the opponent is no longer in any kind of hitstun or guardstun to allow the combo meter to read the hits properly).
Does the combo meter affect the guard crush at all? I'm not exactly sure how/why you're doing this comparison so my little fixes may mess something else up. Not 100% sure.
vVv Ryuko718 Updated 10/31/22 vVv

Nep Heart

Re: Refining a Guard Crush System Code
#6  December 04, 2018, 09:49:20 pm
  • ****
  • CPU Purple Heart
    • USA
    • https://www.pixiv.net/en/users/8108265
 Late reply again, but for good reason. Spent the entire week finding ways to apply your additional advice, but I've finally found the solution to make this all work seamlessly. I basically made it so that the targetstate activates early enough by making it so that the custom state triggers the reset later into the sequence. It seems to now make all attacks whether conventional, helper or projectile based. Should be bug free and now I can finally release my current character while updating my previous releases to work with this fix.

 Thanks very much!
Page 1 of 11   Go Up
« previous next »