YesNoOk
avatar

rather interesting problem regarding super armor-concurrent code. (Read 1223 times)

Started by Bastard Mami, July 02, 2008, 09:03:12 pm
Email this topic
View printable version
Share this topic:
« previous next »
Page 1 of 11   Go Down

Bastard Mami

rather interesting problem regarding super armor-concurrent code.
#1  July 02, 2008, 09:03:12 pm
  • ******
  • [E]
    • Mexico
Ok, first I will post a small snippet of code

[Statedef 210]
Type          = S
MoveType      = A
Physics       = S
Ctrl          = 0
PowerAdd       = 0
Juggle        = 10
FaceP2          = 1
HitDefPersist       = 0
MoveHitPersist       = 0
HitCountPersist    = 0
SprPriority       = 2

[State Return]
Type       = ChangeState
Trigger1    = AnimTime = 0
Value          = 0
Ctrl          = 1
[State Vel ]
Type       = VelSet
Trigger1    = !Time && Anim= StateNo
X          = 0
Y          = 0
[State Anim ]
Type       = ChangeAnim
Trigger1    = !Time && Anim= StateNo
Value          = StateNo


That one is a regular statedef. to allow the state to be re-entrable by the super armor whitout restarting everything, I check if the current anim is the one that corresponds to the state, which means I was there before, if I come from another state-animation pair I just restart my animation, which in turn restarts all the sctrls as all the triggers depend on animation times.

This was working perfectly and dandy until I needed a state to restart it's own animation, by calling it form the cmd.

what I did to fix it is this:

[Statedef 210]
Type          = S
MoveType      = A
Physics       = S
Ctrl          = 0
PowerAdd       = 0
Juggle        = 10
FaceP2          = 1
HitDefPersist       = 0
MoveHitPersist       = 0
HitCountPersist    = 0
SprPriority       = 2

[State Return]
Type       = ChangeState
Trigger1    = AnimTime = 0
Value          = 0
Ctrl          = 1
[State Vel ]
Type       = VelSet
Trigger1    = !Time && 1370!= StateNo
X          = 0
Y          = 0
[State Anim ]
Type       = ChangeAnim
Trigger1    = !Time && 1370!= StateNo
Value          = StateNo


1370 is the super armor state, so now I can cancel a weak punch to another weak punch and the animation will restart properly. But I am pretty sure I broke re-entry that does not come from super armor and that should not restart the anim-state. an example is going to a state 5 times in a single tick to call 5 different projectiles.

I have a few ideas currently for this; one is making a statelist for allowing  reentry and the other is to quit changestates and use change anims instead, which would require a big change in most states, especially the common ones. Both meaning that I can solve/have solved the problem already but I still want to see how others would fix this differently, as I might be overlooking something.

Cyanide

Re: rather interesting problem regarding super armor-concurrent code.
#2  July 02, 2008, 10:49:38 pm
  • ******
  • Legendary XIII
  • I am the eye of the storm to come!
    • New Zealand
    • network.mugenguild.com/cyanide/
I went with time = 0 && anim != stateno more or less. The freeze is in the super armour state.

Rereading, coming from the .cmd means chaining of hits.

Add another trigger. Prevstateno != stateno. Bugger making it compact, code that works is much better than code that's iffy.


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

Re: rather interesting problem regarding super armor-concurrent code.
#3  July 02, 2008, 11:40:51 pm
  • ******
  • [E]
    • Mexico
unrelated: I think the !Time trigger is copletely useless.

Related: Yeah, it would work, it fits in the criteria of amking a state list, but is my fault for not explaining my concept of it.

Cyanide

Re: rather interesting problem regarding super armor-concurrent code.
#4  July 02, 2008, 11:49:28 pm
  • ******
  • Legendary XIII
  • I am the eye of the storm to come!
    • New Zealand
    • network.mugenguild.com/cyanide/
In that situation, persistent = 0 would work just as well as time.

I wonder, in the interests of everything. persistent normally defaults to 1. Does this mean that even though the trigger is something like time = 0 mugen will reread it every tick? If you set persistent = 0 then mugen will bypass that controller after the first read?

I don't know that much about mugens state reading stuff.

This is mostly so you don't have to keep writing in animation/statenumbers right? What happens if you need a duplicate animation that doesn't match the state? Or do you copy paste the anim with the required number?


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

Re: rather interesting problem regarding super armor-concurrent code.
#5  July 03, 2008, 05:36:28 am
  • ******
  • [E]
    • Mexico
Copy paste is right, I use a slightly different set of required anims, so I copy paste my set to use mugen's default set to provide mugen compatibility.
Page 1 of 11   Go Up
« previous next »