Damage increase on counter move (FIXED)

Started by Momotaro, October 24, 2011, 11:07:55 PM

Previous topic - Next topic

Momotaro

I would like to implant a feature in my game.

Enemy start any of his attack move
P1 counter this move with any normal attack
The damage value of P1 move is at 125% (for the first hit only, if it hav more than one hit)

Is there an easy way to add this feature without re-coding all my hitdefs
I can remember trying to add this feature using state-3 and this kind of things, but never succeded. :-\
I'm using winmugen.

Thanks in advance

Bastard Mami

I use some st-2 code to detect counter hitting then a lifeadd in my states;you can put  the latest lifeadd in st-2 if you wish.


Cyanide

You have no way of knowing how much damage an attack does until it hits you. This can't be done.


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.

Bastard Mami


Cyanide

Oh, i was reading that as 125% of the opponents move.

Targetlifeadd is totally the way to go

value = -floor(enemy, gethitvar(damage)*0.25)

Should work.


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.

Seravy

If you don't want to add it to your hitdefs, then
[State -3]
Type=Attackmulset
Trigger1=1
value=(1+0.25*(P2movetype=A))


Momotaro

Thanks
Seems to be a good code.
Now how can I trigger it only when a move is countered?
I'm intersted in some effective "counter hitting detect"

Bastard Mami

do not use what seravy posted, pretty sure it won't work.

Seravy

Quote from: Feedback Police~ on October 25, 2011, 03:29:46 PM
do not use what seravy posted, pretty sure it won't work.
Explain why it isn't working. You can't just say it's not working without proving it.
It won't work on damage done by helpers or projectiles, but should work on every attack done by the player.
QuoteNow how can I trigger it only when a move is countered?
Already included.
You do 1x damage if P2movetype is not A (opponent is not attacking) and 1.25x if P2movetype is A (opponent is attacking).

Bastard Mami

well, it will only break on one tick per attack and considering how most mugen characters are coded they most likely have extra movetype=A time anyway. for a fast fix it might work provided you don't care about tick precision. i.e. if p2 changes movetype in the tik you hit him you will get a false positive on counter hit damage.

Seravy

Quotefor a fast fix it might work provided you don't care about tick precision.
Considering that P1 side sees P2 side a tick later than P2 sees P1, I think caring about tick precision is kinda unnecessary...as the same code does read different values form the enemy depending on the player side.

Example situation #1
a.,P1 starts an attack.
P1 switches movetype from I to A. P2 detects the A movetype, and will correctly activate the increased damage.
b.,P2 starts an attack.
P1 detects the current movetype of P2 (could be anything, but most likely it is I). P2 then sets movetype to A. The increased damage will activate 1 tick later than it should.

Example situation #2
a.,P1 stops attacking.
P1 switches movetype from A to I. P2 detects the I movetype and will correctly not do increased damage.
b.,P2 stops attacking
P1 detects P2's movetype=A. P1 does increased damage. P2 switches movetype from A to I. The increased damage will stop 1 tick later than it should.

Now, as you see, the code works correctly if you are P2, but not if you are P1.
To make it work correctly for P1, you'd need to know in advance what the movetype of P2 will be after his current tick is evaluated (as it hasn't happened yet when P1's tick is processed), which would require reading into the future. If you can make a code in Mugen that does that, I'd request next week's winning lottery numbers, please.

Conclusion : Coding with tick precision is impossible if it needs to read something related to the opponent or any other object which is processed after P1 is.

As for the extra Movetype=A, I'm actually letting that be there intentionally, for exactly the thing described above. Stuff that needs to trigger when taking a hit from an attack of the attacking enemy simply doesn't trigger on P2 side if the attacker (P1) immediately switches movetype to I after the hit is done. When I added the movetype change, it broke that code that was triggering on taken attacks.

Momotaro

Thanks for the explanations.
I'll tray to use it ASAIC. :)

Bastard Mami

exactly, you are the one who is reading to the future, it can be done differently without doing that.

Seravy

Quoteexactly, you are the one who is reading to the future, it can be done differently without doing that.
How? You need to detect P2's movetype and it's not been set yet when P1 is processed. Doing the additional damage later through a targetlifeadd or similar allows you to avoid this problem in theory, but I'm not sure about it in reality. Depends on when movetype=H is set when taking a hit.
It also rises a few other problems :
-The additional damage will not be dealt if the target got dropped (any reason).
-The additional damage will not be dealt if the opponent had an active hitoverride (superarmor)
-The additional damage will not be dealt if the opponent is taking damage through a helper overlay (helper type superarmor)
-The additional damage will not be dealt if you hit each other at the same time.
-The additional damage will be dealt to every target, including ones that got hit by earlier attacks in the combo and weren't dropped yet.

Momotaro

Quote from: Seravy on October 25, 2011, 11:35:08 AM
If you don't want to add it to your hitdefs, then
[State -3]
Type=Attackmulset
Trigger1=1
value=(1+0.25*(P2movetype=A))


Thanks it works perfectly! (I can't see any problem on it...)
I increased the damage value to more only for the debug works
Do you think it will work on 2 vs 2?

Now I would like to add another features:

to have it working only with normal moves by P1
is this code OK?
trigger1 = StateNo = [200,299]

A blink screen effect
Initially, I was using a var value for the counter system, but it was really buggy.
So how can I trigger it? (without using a var??)

[State -2, 5] ;Blink white
type = BgPalFX
trigger1 = ??????????????????
time = 2;4;3
add = 128,128,128 ;256,256,256
ignorehitpause=1


Thanks again

Seravy

QuoteDo you think it will work on 2 vs 2?
No it won't. There is no way to make an attack do different amounts of damage to two different players simultaneously. It's just not possible in the current Mugen. Maybe in a future version.
At best you can decide on either P2's or P4's movetype depending on some sort of a condition, for example, using whichever is standing closer to you.
If you use the targetlifeadd method (see above for disadvantages of that), you can even check which player you were hitting, but it will still do the same thing to both players if more than one was hit.

Oh yeah and targetlifeadd method has another flaw, too. If P2 is hit but P4 is guarding the move, it'll still do the 25% damage to P4. (because guarding players are also targets, and you can't drop just the player who is guarding from your targets.)

Quoteto have it working only with normal moves by P1
No, that code is not ok. You have to use enemy,hitdefattr for it.
Like this
Type=Attackmulset
Trigger1=1
value=1+0.25*(enemy,movetype=A)*(enemy,hitdefattr=SAC,NA,NT,NP)

also, you want the trigger1=1 unchanged, because it needs to set the attack multiplier back to 1 when the conditions are not true.

QuoteA blink screen effect
Initially, I was using a var value for the counter system, but it was really buggy.
So how can I trigger it? (without using a var??)
Well, that one is a bit harder.
Basically, you need to trigger it when attackmulset was on 1.25 the previous tick AND you just did a hit.

for that, you need to use a variable, to store the attackmulset value.

[State -3]
Type=BgPalFX
Trigger1=var(11)=1.25
Trigger1=Movehit=1
...
ignorehitpause=1

[State -3]
Type=Varset
Trigger1=1
var(11)=1+0.25*(enemy,movetype=A)*(enemy,hitdefattr=SAC,NA,NT,NP)
ignorehitpause=1

[State -3]
Type=Attackmulset
Trigger1=1
value=var(11)
ignorehitpause=1

The order of the three controllers is important.

Momotaro

In this code seems to cancel enemy's normal only:

Type=Attackmulset
Trigger1=1
value=1+0.25*(enemy,movetype=A)*(enemy,hitdefattr=SAC,NA,NT,NP)


But I want not that. P1 can cancel every of P2 move, but only by using a normal move (by P1)
Is this code below good? (only deleting "enemy")

value=1+0.25*(enemy,movetype=A)*(hitdefattr=SAC,NA,NT,NP)

Quotealso, you want the trigger1=1 unchanged, because it needs to set the attack multiplier back to 1 when the conditions are not true.

Sorry, I'm not sure to understand. I have to delete the trigger=1 to have it return to basic value when conditions are not true, right?
So what kind of trigger can I use instead? Or the inverse, I have to use it to make sure the counter move is always detected every tick?

This is a try of implanting blink effect too
(The damage is harder, so I can see visually the damage changing on the lifebar, this is only for debug)

[State -3,1]
Type=BgPalFX
Trigger1=var(13)=3.25
Trigger1=Movehit=1
time = 2;4;3
add = 128,128,128 ;256,256,256
ignorehitpause=1

[State -3,2]
Type=Varset
Trigger1=1
var(13)=1+2.25*(enemy,movetype=A)*(enemy,hitdefattr=SAC,NA,NT,NP)
ignorehitpause=1

[State -3,3]
Type=Attackmulset
Trigger1=1
value=var(13)
ignorehitpause=1

Seravy

QuoteBut I want not that. P1 can cancel every of P2 move, but only by using a normal move (by P1)
Is this code below good? (only deleting "enemy")
Oh. No, it's not good. Minus states are executed before your current state, meaning that this code checks your hitdef before the Hitdef controller is executed and sets the attack. So this way, it will not be active on the first tick of the hitdef activation.
If you want to make this work, you have to activate your hitdefs earlier than where the clsn1 is on the animation, that way the first time when the hitdefattr is not detected yet will happen when the attack is not able to hit yet.
The other solution is to put the multiplier into all your normal attack states directly.

QuoteSorry, I'm not sure to understand.
1 is a condition that is always true. So trigger1=1 makes sure an Attackmulset is always activated for either the value 1 or 1.25 depending on that formula in value=. It isn't mentioned in the documentation how long is attackmulset effective, and this makes sure the value is always set back to 1 when it needs to.
Basically, the value=part tells the counter to be active or not, but to do so, the code must always work.
Your blink effect code looks good (except that you don't need the enemynear,hitdefattr part because that's not what you wanted.)

Momotaro

QuoteIf you want to make this work, you have to activate your hitdefs earlier than where the clsn1 is on the animation, that way the first time when the hitdefattr is not detected yet will happen when the attack is not able to hit yet.

Is this code OK to activate it at the start of every normal move without editing every state?

trigger1 = StateNo = [200,299]

Quote
1 is a condition that is always true. So trigger1=1 makes sure an Attackmulset is always activated for either the value 1 or 1.25 depending on that formula in value=. It isn't mentioned in the documentation how long is attackmulset effective, and this makes sure the value is always set back to 1 when it needs to.
Basically, the value=part tells the counter to be active or not, but to do so, the code must always work.
Your blink effect code looks good (except that you don't need the enemynear,hitdefattr part because that's not what you wanted.)

OK, I understand, so it have to be always detected to make sure it works everytime.

With this changes it should work, right?

[State -3,2]
Type=Varset
Trigger1=1
var(13)=1+2.25*(enemy,movetype=A)
ignorehitpause=1

Cyanide

QuoteIf P2 is hit but P4 is guarding the move, it'll still do the 25% damage to P4. (because guarding players are also targets, and you can't drop just the player who is guarding from your targets.)

Ugh, i always forget about that. Such a shitty feature. The sooner we can alter how guard states work (i want movetype = G) the better.


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.