If you leave the first argument of the ATTR parameter blank, the hitdef will not be affected by reversaldefs, but the hitdef will work as normal. Useful if you don't want moves to be countered or projectiles to be reflected.

Hitdef
attr = , SA

thank you, really cherish of what u say,and then how about this 1, it seem like such character have the really accurate number in the enemy position determination. is that necessary need to calculate such figure with the word like "Floor" i understand the word "enemynear(fvar(36))" but is that necessary?

Code:

P2BodyDist Y = [-70-floor(6*(EnemyNear(floor(fvar(37))),vel Y)+(6*(6+1)/2)*fvar(30)),0-floor(6*(EnemyNear(floor(fvar(37))),vel Y)+(6*(6+1)/2)*fvar(30))]

While I was coding my last char, I've found a weird bug:

Chars which are on a NotHitBy state STILL can be hit by ReversalDef, something just absurd (Come on, Elecbyte...).
A NotHitBy should mean, you know, NOT HIT BY, instead of ALMOST NOT HIT BY

This render some bugs, like Super Armor chars (using or not an helper for the armor) will be on p2 states besides their own states.

I've tried to make this:

Quote

[State 0, SelfState]
type = SelfState
triggerAll = RoundState =2
trigger1 = MoveType = H
value =0
ctrl = 1
ignorehitpause=1
persistent=1

[State -2, ChangeState]
type = ChangeState
triggerAll = RoundState =2
trigger1 = MoveType = H
value =0
ctrl = 1
ignorehitpause=1
persistent=1

But, no good.

There is any other solution?

for the record regarding the glitch that disallows targetdropping; you don't actually need to reverse anything. reversaldef simply needs to exist (even in the most undefined way possible). if you have a hitdef in the same state and it hits your target will still remain indefinitely.

Code:

[State ]
type=reversaldef
trigger1=1
reversal.attr=acs,aa,ap,at
ignorehitpause=1
persistent=1

[State ]
type=hitdef
trigger1=
attr=
ignorehitpause=1
persistent=1

Ricepigeon said, September 18, 2015, 09:09:39 pm

Additionally, there is a glitch in the Reversaldef controller which causes Player1 to retain Player2's target information even after Player2 returns to an Idle state. This allows Player1 to use target-based state controllers such as TargetState and TargetLifeAdd, as well as the Target redirection trigger, when they would normally not be allowed to. Through specific coding, it is possible to utilize this glitch to replicate a "damage-over-time" effect such as Poison. Please see these threads for more info.

there is another glitch where if this is done with helpers and the helpers destroyself, any helper that spawns from that point onwards is automatically a target. this plus ""rootchangestate"" through projectile is how the character F1 is killed.

Hi guys, I have tried the code in different ways but it never returns the helper's iD, why would it be?

In Mugen 1.0, setting the character's internal name (not the displayname parameter) past a certain character limit will cause the character to be automatically KOed at the beginning of a match, among other issues.

Typo example: forgetting to close parenthesis in triggers:

Code:

[State 200, CS]
type = changestate
trigger1 = (var(20)=1 ;note that the first set of parenthesis is left often
value = 0

Late reply, but adding more to it:

Explaining a bit on how it actually works, without any of the examples Ink posted.

Cond was made with the intention to get information out of the source, check if its true/false and return a or b

Code:

Cond( Condition, a, b)
Cond( Condition = true, return a, b)
Cond( Condition = false, a, return b)

(IfElse works similarly but won't work for this kind of application).


with that in mind you can almost see how it works

If I Write

Code:

Cond(1, ID, 0)

100% of the time, that code will get me the ID value, since the info that cond is checking is ‘1’, which means ‘true’, it will return the id. if 1 would be considered ‘false’ then it would return 0 (but that won’t happen. (Unless you’re from a parallel universe lol).

But, why would you use cond that way? because all we care about its the “return a - b” scenario.

The other way around to do that would be by writing:

Code:

Cond(0, 0, ID)

this will prefetch the b-data.

and using that with other instances inside mugen, give you the same. Catch my thought yet?

What if we could get the id of a helper that’s attacking the player in just 1 line?
We need to do as it follows:
-Check if there’s a player nearby
-Check if that same player, has an active helper with attacking properties
-If everything above is true - return it’s ID.

 Coding that in game:

Cond(NumEnemy,
Cond(Enemy, NumHelper,
Cond(Helper, MoveType = A
Return ID.

I’ve separated just so you get the jist of it.

Lost?

All we are doing is redirecting data inside other objects(players/helpers) until it gets to the object you need. Its like a chain of redirects that go 1 by 1, until it reaches it's destination. That's why there's cond on top of conds.


The var setting using the := operator also works using this method:

Code:

Helper(200), Cond(1, Var(10) := 1, 0)

This will set the var 10 of that Helper(200) to 1. Remember that, mugen works like this:

Check condition > if true, apply whatever effect from whatever sctrl; While true, do not check for any more objects that this is not true.

What does that mean in practice? That’s gonna check for the first spawned helper(200), and set its var while the helper is ingame. if by any chance another helper 200 is summoned. it won’t get the same effect as long as the first helper is still there. To overcome this problem, there’s a lot of different solutions. I’ll leave that as an open topic.



This exploit was found in mid-ish 2018. Me and a couple of friends have stress tested this and we can say it's totally reliable. (As long as you know how to use it, and you're fully aware of how mugen checks conditions).

Funny enough, Electbyte coded Cond, because IfElse had problems with how it had try to check the conditions, and to fix that they created Cond, which makes it possible to cross-redirect any type of data in between all available ids. Helper from your team or not, it can be accessed and their info can be checked directly from any id without any kind of hacking code that would only work on full games. IfElse on the other hand, can't be used to do that. It wont work.

Also it’s kinda weird that i've just came across this exploit 10 years later since the first time Cond was actually introduced but oh well.

@Archimonde

I can only have a max of 512 controllers though...

Anyway, I don't wanna be told off for derailing the thread, so is it okay if you make a different thread about this null stuff and elaborate a bit?

@Archimonde

A little unrelated, but do you know if any of these nulls are avaliable to download? I want to have a look at how the null exploit works in 1.0/1.1...

I know, but for some reason, having those there does seem to help it work better... for some reason... I don't know why but it just does, at least for me.