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.

The infamous null exploit can actually negate all kinds of KO protections including the NoKO assertspecial flag. Contrary to popular belief, it still works in MUGEN 1.0, but the method to achieve that bug is done a little differently than it would be in WinMUGEN. I can confirm this because I have three characters in my roster who can OHKO Training even though it uses NoKO.

 However, I am not sure if the null exploit works in 1.1, still need to test it to confirm.

@2OS Speaking of helpers, I decided to relook at this thread and tried using them this time. I have the initial SuperPause thing which worked in -2 in a helper this time, and it looks like this:

-- Actual Helper

Code:

[Statedef 15150]
Type = U
MoveType = U
Physics = N
hitdefpersist = 1
hitcountpersist = 1
movehitpersist = 1

[State -2]
type = AssertSpecial
trigger1 = 1
flag = invisible
flag2 = noshadow
ignorehitpause = 1

[State -2]
type = BindToRoot
trigger1 = 1
pos = 0, 0
ignorehitpause = 1

[State ]
type = NotHitBy
trigger1 = ishelper
value2 = SCA
ignorehitpause = 1

[State ]
type = HitOverride
trigger1 = ishelper
attr = SCA,AA,NA,SA,HA,AP,NP,SP,HP,AT,NT,ST,HT,S,C,A,H,N,T,P
time=-1
ignorehitpause = 1

[State , SuperPause]
type = SuperPause
trigger1 = !ishelper
time = 11111111111
sound = -1
movetime = -1
darken = 0
anim= -1
p2defmul = 1
poweradd = 0
unhittable = 0
ignorehitpause = 1

[State , Pause]
type = Pause
trigger1 = !ishelper
time = 11111111111
sound = -1
movetime = -1
anim = -1
p2defmul = 1
poweradd = 0
unhittable = 0
ignorehitpause = 1

[State , SuperPause]
type = SuperPause
trigger1 = ishelper(15150)
time = 0
sound = -1
movetime = -1
darken = 0
anim= -1
p2defmul = 1
poweradd = 0
unhittable = 0
ignorehitpause = 1

[State , Pause]
type = Pause
trigger1 = ishelper(15150)
time = 0
sound = -1
movetime = -1
anim = -1
p2defmul = 1
poweradd = 0
unhittable = 0
ignorehitpause = 1

[State ]
type = Null
trigger1 = 1
ignorehitpause = 1

[State ]
type = DestroySelf
trigger1 = !root,alive
ignorehitpause = 1

In -2:

Code:

[State , Helper]
type = helper
trigger1 = (stateno = 5051 || stateno = 14000 || stateno = 14005) && !numhelper(15150)
id = 15150
stateno = 15150
name = "SaveH"
keyctrl = 0
ignorehitpause = 1
supermovetime = 11111111111
pausemovetime = 11111111111

Would this work? And as for armour, well, Super/Hyper Armour helpers are incompatible with the character I'm trying to add this to. Also, the States I'm trying to have this immunity active on all have NotHitBy's activated anyway, so there shouldn't be a need for Armour anyway whilst in those states.

The only issue I have with nep's version of it is that I can only have it in State -2, and I can only have trigger1 = 1. It won't work otherwise, which is a problem because I only need it to be active for those 3 states.


EDIT: This works.

Winposes (Roundstate 4)

Match Ending: The match will not end until one player is in State 5150 (the loser), and one is in State 0 WITH ctrl = 1 (the winner).
The enemy can be controlled via custom states during winposes, but there are very specific criteria to make it work seamlessly (see my guide here)
For the winning player, it is possible to continue a special "finisher-type" animation into the win pose phase (without changing to Stand anim), but the player must be in State 0 (add triggers preventing change to stand anim), and with ctrl (add triggers in .cmd to prevent input in this scenario).  A workaround for the latter is to just set ctrl=0, then toggle it to ctrl=1 intermittently for 1 tick (to trigger winpose phase).

---

State 5150 (lying down defeated)
When the defeated opponent is in State 5150, MUGEN does not recognize a "Player 2" / "Player 3" / "Player 4".  Meaning, triggers such as "P2Dist", "P4Life", etc will fail and result in a debug error "Nonexistent player".
However, trigger redirections such as "enemy," "enemynear," "PlayerID," - and even "target," still function correctly in this state.
Thanks @2OS for correcting my initial flawed description

---

Custom States
In a custom state, Explods do not scale to the active coordinate space.  A low res character in a high res environment will be drawn tiny / a high res character in a low res environment will be drawn enormous. There are no triggers that can be used to detect the scale factor, because all relevant values returned by these triggers are already scaled, regardless of being used by Player 1 or from a custom state.  Therefore, do not use Explods to draw the enemy - only use Changeanim / Changeanim 2 (unless in a fullgame environment where coordinate space is always uniform).

---

Stages that move up and down
On stages that have vertical movement (which bob up and down), all players (including helpers) are constantly affected by the movement, regardless of state type, if they are in the air, etc.  Explods, however, are NOT affected by this type of stage movement - therefore it is recommended to always bind Explods to the player when they are intended to be positioned relative to the player, because otherwise they may look ridiculous when used on such levels.

Okay, so I fixed the problem. I forgot that sometimes people change var values by using "v = " instead of "var() = " because of that, I thought var(21) wasn't being used, when, it infact was. So I used var(43) instead and then found a new issue.

Code:

[State -2, ResistState]
type = SelfState
trigger1 = var(43) = 2
value = ifelse(random < 333, 6500, ifelse(random < 500, 12012, 5210))
ignorehitpause = 1

This selfstate was being triggered when the var changed to 2, but it was in State -2 so it spam triggered when the var finally changed.

When I realized this I fixed it, and so this is what I ended up with, just so that anyone in future who may need this can copy:


In State -2:

Code:

[State -2, VarSet]
type = VarSet
trigger1 = life = 0 && var(43) = 0
var(43) = 1
ignorehitpause = 1

[State -2, Resist]
type = AssertSpecial
trigger1 = stateno = 14000 && var(43) < 2
flag = noko
flag2 = nobardisplay
ignorehitpause = 1

[State -2, SecondChance]
type = SelfState
trigger1 = life = 0 && var(43) < 2
value = 14000
ignorehitpause = 1

In State of your choice (I chose 14000):

Code:

[Statedef 14000]
sprpriority = -1

[State 14000, ResistBy]
type = NotHitBy
trigger1 = life = 0 && var(43) = 1
value = SCA,AA,NA,SA,HA,AP,NP,SP,HP,AT,NT,ST,HT
ignorehitpause = 1

[State 14000, ResistPause]
type = SuperPause
trigger1 = life = 0 && var(43) = 1
time = 5
movetime = 5
supermovetime = 5
darken = 0
unhittable = 1
ignorehitpause = 1

[State 14000, ResistSet]
type = LifeSet
trigger1 = life = 0 && var(43) = 1
value = lifemax / 4.66
ignorehitpause = 1

[State 14000, VarSet]
type = VarSet
trigger1 = var(43) = 1
var(43) = 2
ignorehitpause = 1

[State 14000, ResistState]
type = SelfState
trigger1 = var(43) = 2
value = ifelse(random < 333, 6500, ifelse(random < 500, 12012, 5210))
ignorehitpause = 1

And there you have it. This code should partially restore your chars HP when it reaches 0, giving it a second chance for battle. You can use it for resurrection like effects.

EDIT: Since I don't have any vfx in mind for the char, I decided to make it look like a counter attack by putting "ResistState" at the end. You don't have to do this, you could have it simply changestate to 0 or add some vfx or whatever you want!