Run Attack

[AkatsukiDude15]

Can someone make or find me vid on how to make a run attack for a char. PLZZZZ!!!!!
(btw can a mod close my other Run Attack thread in request)

[Elix]

What do you mean by run attack? Just normal punch while running? In that case all you need to edit is .CMD. Check ChangeState controller for the attack you need. See if there's Ctrl = 1 trigger. You see, when you're running normally your Ctrl = 0. So all you need to do is to add another condition: triggerall = Ctrl || StateNo = 100 || StateNo = 101; 100 is a Run state, 101 is a stop running state

[PotS]

For a running attack it'd actually be better to use just "StateNo = 100 || StateNo = 101" as condition and leave out ctrl, so that the char can't do it when not running. Either that or:

triggerall = Ctrl && (StateNo = 100 || StateNo = 101)

[Bea]

You see, it's far more effective in mugen standards to code it like this:

triggerall = ctrl
triggerall = stateno = [100,101]

Mugen expressions aren't short circuited.
That means that the above trigger set will not test the second condition if the first trigger is false, but the ones you two posted will test the whole condition, wasting CPU cycles.

And here I thought it was common knowledge already...

[Elix]

Thank you for remembering that, but I think in this case the result will be FALSE. Statedef 100 has ctrl = 0. So the first trigger checked will turn false, turning off the controller. Isn't it obvious?

And I though it's only natural for mugen to behave like this, in the case oftriggerall = Ctrl || StateNo = 100 || StateNo = 101
1) Check Ctrl, if true, proceed with the next trigger, if false,
2) Check StateNo = 100, if true, proceed with the next trigger, if false,
3) Check StateNo = 101, if true, proceed with the next trigger, if false, render the whole controller false.
It's only natural, I wonder if MUGEN engine does it differently.

[Bastard Mami]

elix: you expression and vbia's are different anyway so there is no point to comparing.

[Bea]

Thank you for remembering that, but I think in this case the result will be FALSE. Statedef 100 has ctrl = 0. So the first trigger checked will turn false, turning off the controller. Isn't it obvious?

And I though it's only natural for mugen to behave like this, in the case oftriggerall = Ctrl || StateNo = 100 || StateNo = 101
1) Check Ctrl, if true, proceed with the next trigger, if false,
2) Check StateNo = 100, if true, proceed with the next trigger, if false,
3) Check StateNo = 101, if true, proceed with the next trigger, if false, render the whole controller false.
It's only natural, I wonder if MUGEN engine does it differently.

Fact is, mugen expressions aren't short cirtuited.
It will always process a whole expression, no matter what.

You can prove it by adding a sctrl like this to your -2 states:

[State -2, Debug Flood]
Type = Null
trigger1 = 0 && Target, Pos y = 0

The above expression will flood your debug screen whenever you don't have a target. Note that 0 makes a trigger return sFalse.

[State -2, Without Debug Flood]
Type = Null
trigger1 = 0
trigger1 = Target, Pos y = 0

The above trigger set won't cause debug flood as the first trigger in the set always return sfalse, preventing the triggers of the same id below it to be processed.

Such information can be found at exp.html under mugen doc folders.

[Elix]

Thank a lot, Bia. Such examples really prove that you were right.
Still our triggerall examples are different, as R[E]ika said.

[AkatsukiDude15]

ok thanks but i meant a tutorial