YesNoOk
avatar

Blocking behaviour (Read 5474 times)

Started by O Ilusionista, January 07, 2018, 07:17:04 pm
Share this topic:
Blocking behaviour
#1  January 07, 2018, 07:17:04 pm
  • ******
  • A living Mugen dinossaur :)
  • 23 years of Mugen O_o
    • Brazil
    • www.brazilmugenteam.com
Guys, I need some help here.
I have a character which has two hittable areas. The common hittable area (where it receives damage) is covered with a helper. The are where he should not receive damage (but must count the hit) is covered by another helper.

As far as I know, Mugen has an internal routine for triggering block routine (guardspark, guardsound) and, unless I am mistaken, the character (or helper) should be in one of the guard states (120-155)  - there is no way to say "this is a block state".

The code works fine, since I made the helper using the state 120 (guard start) but the problem is: If it's hit by a move where it's hitdef has "hitflag = MAFD" it never blocks, going to state 5000.

I tried to use  GetHitVar to get the attack but it fails. Am I missing something?

For sure, there is an option to simple using HitOverride, but using this, the hitspark and the hitsound from the attacker are still in action.

Any help, is appreciated.
Last Edit: January 08, 2018, 11:10:11 am by O Ilusionista
Re: Blocking behaviour
#2  January 07, 2018, 09:59:21 pm
  • **
    • France
Very confusing stuff ...
I don't know much how helper's guard behaves, but I'm very curious about your issue.

Are you saying that the "Downed" parameter in the hitdef flag triggers immediately state 5000 ?
Have you tried with an attack with hitflag = MD ?  (or AD, or FD)
Is your helper considered to by "Layed" (in statedef TYPE) or something ? I mean, if the D hitflag triggers something, I'd lean towards something in the way of TYPE=L  ...
- samurais, swords & stuff ? → Another Blade
Re: Blocking behaviour
#3  January 07, 2018, 10:05:05 pm
  • ******
  • A living Mugen dinossaur :)
  • 23 years of Mugen O_o
    • Brazil
    • www.brazilmugenteam.com
See the picture below:


The green area is the helper which is hitable (once it get hit, it substracts the life of the root).
The blue area is the blocking helper. It's also hitable, but since it is on state 120, the engine will treat it like a block (what I want to do).

Quote
Are you saying that the "Downed" parameter in the hitdef flag triggers immediately state 5000 ?
Yes. Even in state 120, once it get hit, it goes to state 5000 (which triggers the hit routine).

I am using a hitoverride to bypass this. but its not exactly what I wanted to.
Re: Blocking behaviour
#4  January 07, 2018, 10:55:37 pm
  • *****
  • Shame on you!
    • USA
Have you set up debug to make sure your char isn't considered downed?

Is there a reason for the two helpers? I mean, if one can block, why not use it AS the character?

And if the character is in statedef 120, couldn't it be a sysvar value problem?
"A Sysvar(2) is used in Statedef 5080 to store the next animation to change to. It isn't documented like sysvar(0-1) are." Set up your debug and see if changing Sysvar(2) around can change things.
vVv Ryuko718 Updated 10/31/22 vVv
Re: Blocking behaviour
#5  January 07, 2018, 11:00:22 pm
  • ******
  • A living Mugen dinossaur :)
  • 23 years of Mugen O_o
    • Brazil
    • www.brazilmugenteam.com
Quote
Have you set up debug to make sure your char isn't considered downed?
Is there a reason for the two helpers? I mean, if one can block, why not use it AS the character?
Its a easy way to make a super armor. The character, per se, is invincible to any attack and won't react to any attack.
All the damage is recorded by the helper.

Quote
And if the character is in statedef 120, couldn't it be a sysvar value problem?
"A Sysvar(2) is used in Statedef 5080 to store the next animation to change to. It isn't documented like sysvar(0-1) are." Set up your debug and see if changing Sysvar(2) around can change things.

I doubt it, since my state 5080 (basicaly all get hit states) is nullified

Code:
[Statedef 5080]
movetype=H
[State 5080, override]
type=changestate
trigger1=1
value=ifelse(alive,5000,5150)
Re: Blocking behaviour
#6  January 08, 2018, 01:02:15 am
  • ******
  • Hedgehog Whisperer
  • Red Bull addict
    • Spain
    • xgargoyle.mgbr.net
Check my superbuu character. His superarmor is coded via helper that absorbs the damage like yours, yet the main character is not interrupted during play.
With my superarmor code, I've never had the issues you are having
XGargoyle: Battle posing since 1979
http://xgargoyle.mgbr.net
http://www.pandorabots.com/pandora/talk?botid=e71c0d43fe35093a  <-- Please click that link
http://paypal.me/XGargoyle  <-- Donations welcome!
Re: Blocking behaviour
#7  January 08, 2018, 01:08:53 am
  • ******
  • A living Mugen dinossaur :)
  • 23 years of Mugen O_o
    • Brazil
    • www.brazilmugenteam.com
For sure I will, thanks.
I never had any issue - I use this method for years.
The problem started when I used the second helper as block.

In OpenBor, we can use any animation as block of we want to. We just to set a flag and its done.
Re: Blocking behaviour
#8  January 08, 2018, 03:43:53 am
  • ******
  • Legendary XIII
  • I am the eye of the storm to come!
    • New Zealand
    • network.mugenguild.com/cyanide/
D means block low. 120 isn't block low so you're getting hit by trips and the like. Fixing this is rather hard as you can't really do both high and low blocking at once.


In M.U.G.E.N there is no magic button

They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.
Re: Blocking behaviour
#9  January 08, 2018, 11:09:17 am
  • ******
  • A living Mugen dinossaur :)
  • 23 years of Mugen O_o
    • Brazil
    • www.brazilmugenteam.com
Yeah, I realize this won't be possible to do the way I want thanks to Mugen limitations. Even if I use crouched block states, he still trigger the hit, not the block.

The solution was using a hitoverride to simulate the block.
Thanks everyone.
Re: Blocking behaviour
#10  January 08, 2018, 07:57:32 pm
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
To get the desired results, the best way IMO would be to reverse the role of the helper and character: make the blocking part the character, and use a helper for regular hits, like a JOJO Stand. You can achieve greater control this way as you can read gethitvar and change to the necessary state. For the simplest possible Stand gethit implementation, refer to Bluestreak’s Shadow Kick code with the Gargoyle helper and cvsbluestreak_damage.cns (at least I believe that was the name). It’s very barebones so it should be documented well enough to see what needs to be done at a minimum. You can look at Warusaki’s DIO for the more complex stuff if needed, but what I have should be enough to set up gethit states.

It’s a bit more of a pain, but at least guard sparks will show correctly, as HitOverride still treats it as if a hit occurred.