You win! PERFECT!

[ClubSyN-X-TReME]

This is something I added to my screenpack to make the game/announcer tell if you win with a perfect.
The code I will show will tell you how to do that and to avoid glitches I discovered when creating this.

For this method, you will need to place this in a helper thats active at all times, thats why in of my guides I use a Dummy/Fake helper.

Code: [Select]

[State -3, Dummy Helper]
type = Helper
triggerall = !numpartner
trigger1 = time = 1 && !numhelper(xxxxx)
helpertype = normal
name = "Dummy Helper"
ID = xxxxx
stateno = xxxxx
pos = 0,-99999999999999999
postype = left    ;p2,front,back,left,right
ownpal = 0
supermovetime = 999999999999
pausemovetime = 999999999999
ignorehitpause = 1
persistent = 0

And below are the Dummy Helper States....

Code: [Select]

;------------------------------------
;Dummy Helper States
;------------------------------------
[Statedef xxxxx]
type = S
physics = n
ignorehitpause = 1

[State 0, AssertSpecial]
type = AssertSpecial
trigger1 = 1
flag = noshadow
flag2 = invisible
ignorehitpause = 1

[State 0, NotHitBy]
type = NotHitBy
trigger1 = 1
value = SCA
ignorehitpause = 1
Now we have a Dummy helper that is active at all times when needed and it will kill that delay that having a helper alone in a negative state causes when needing something to happen at the correct moment as well as hitpause desyncs.

in the dummy states above, add another helper to it for the PERFECT win codes.

Code: [Select]

[State 0, Perfect Victory]
type = Helper
trigger1 = (roundstate > 3 && !drawgame)&& (root,WinKO || root,LoseKO) && !numhelper(yyyyy)
helpertype = normal ;player
name = "Perfect Victory"
ID = yyyyy
stateno = yyyyy
pos = 0,-99999999999999999
postype = left    ;p2,front,back,left,right
ownpal = 0
supermovetime = 999999999999
pausemovetime = 999999999999
ignorehitpause = 1
persistent = 0
See this trigger here:
trigger1 = (roundstate > 3 && !drawgame)&& (root,WinKO || root,LoseKO) && !numhelper(yyyyy)
This will prevent the helper from kicking in when there is a draw game and time over regardless if you have full health and the enemy doesn't.

IMO it's pointless for a perfect to be displayed if you won by a time over.

Now for the Perfect states.

Code: [Select]

;------------------------------------
;Perfect Victory
;------------------------------------
[Statedef yyyyy]
type = S
physics = n
ignorehitpause = 1
sprpriority = -4

[State 0, AssertSpecial]
type = AssertSpecial
trigger1 = 1
flag = noshadow
flag2 = invisible
flag3 = roundnotover
ignorehitpause = 1

[State 0, NotHitBy]
type = NotHitBy
trigger1 = 1
value = SCA
ignorehitpause = 1

;---------------<perfect!>-----------

use a perfect Explod code here

use a Playsnd to make the announcer or voice say perfect.

[State 0, DestroySelf]
type = DestroySelf
trigger1 = statetime = 200
Even though helpers destroy themselves when a round is over, you MUST destroy this one since we are using the roundnotover asserted trigger which means mugen will not end this round properly.

[Jelux Da Casual]

Legen, wait for it...

[MirageAtoli]

Why is there a second helper involved? Why not use changeanim on the first one?

[ClubSyN-X-TReME]

Why is there a second helper involved? Why not use changeanim on the first one?

Because

Now we have a Dummy helper that is active at all times when needed and it will kill that delay that having a helper alone in a negative state causes when needing something to happen at the correct moment as well as hitpause desyncs.

btw, I really hate explaining myself twice. no offense but it gets to me.

As far as changeanim, I dont know, if coded in a character maybe ( I seriously doubt that), but my version was not coded in a character, its for my screenpack with uses the fightfx.sff so it would be compatible with all chars, thats why I didnt use changeanim since the sprite is not the chars own sff and to be honest, changeanim is a very bad idea for this.

Oh yeah I forgot to mention for the perfect explod and playsnd, use this trigger to activate it.

trigger1 = (root,life = lifemax || enemy,life = lifemax)

[BEATMASTERMIKE]

this is pretty cool

[shinra358]

maybe you should have this done by hits instead of life cuz a person life can be taken and someone may have life regain(or just defense, etc). if does by hits then you can say if the person wasnt hit at all. just becuz being hit and gaining life back != to a perfect

[ClubSyN-X-TReME]

Then I would need a variable for the root character which was the reason Why I made this method. Avoid using root vars.

[shinra358]

what about helpervar instead?

[ClubSyN-X-TReME]

to detect, count hits, etc, a var would need to be assigned to that characters attack states, all of them. which im trying to avoid.

[shinra358]

k

[MirageAtoli]

Why is there a second helper involved? Why not use changeanim on the first one?

Because

Now we have a Dummy helper that is active at all times when needed and it will kill that delay that having a helper alone in a negative state causes when needing something to happen at the correct moment as well as hitpause desyncs.

btw, I really hate explaining myself twice. no offense but it gets to me.

trigger1 = (root,life = lifemax || enemy,life = lifemax)

You do realize that you run the risk of running out of the total amount of possible helpers each with 100 variables each.
To me it would make more sense to have the helper change to different state or anim while still asserting roundnotover, but that is also from the guy who can't stand for his code not to be optomized.

I also don't know enough about the latency problem that you are trying to avoid.

to detect, count hits, etc, a var would need to be assigned to that characters attack states, all of them. which im trying to avoid.

As for a perfect round compare the roots life to its maxlife and set one of the helpers values and use that to switch between an "untouchable" and "perfect" rounds. It is very doable, but may not be what you intended.

[ClubSyN-X-TReME]

You do realize that you run the risk of running out of the total amount of possible helpers each with 100 variables each.

, yeah im aware of that and I rarely use vars in the helpers anyway. I am not actually coding a character you know. I did say this was for my screenpack. also if I needed more helpers, I can always increase them in the mugen.cfg

To me it would make more sense to have the helper change to different state or anim while still asserting roundnotover.

I understand the changing to a different state but I cant use a sprite from the fightfx with a changeanim code and thats why I did it the way I did. If I use a changeanim code then I would have to insert that sprite and anim code into all mugen chars that exist. I swear I already said that and I also said,

I am not actually coding a character you know. I did say this was for my screenpack,

I also don't know enough about the latency problem that you are trying to avoid.

Of course you don't, thats why you always question my methods without having the full understanding.

This was something I have experienced when making interactive stages or using coding methods by having something activate from a negative state. A negative state has a 2 tick delay from anything happening in a positive state when tryong to sync events and effects. Rednavi and I discovered this while we were working on separate projects and he showed me how to properly fix that and thats when I figured I would make a helper thats active at all time, but dont do anything which I call a dummy helper and if I needed something to hapen when I want in the right time, I code it in that dummy helper states so it would execute at the exact moment when I needed it to. Even hitpauses, pause triggers, or super triggers wont throw it off sync like it would if I used whatever code I used in a negative state alone.

As for a perfect round compare the roots life to its maxlife and set one of the helpers values and use that to switch between an "untouchable" and "perfect" rounds. It is very doable, but may not be what you intended.

Sigh, just for you, I will repeate myself, again.

1.

to detect, count hits, etc, a var would need to be assigned to that characters attack states, all of them. which im trying to avoid.

2.

I am not actually coding a character you know. I did say this was for my screenpack,

[MirageAtoli]

Thanks for the precise answers and clarification; it really is quite useful.

Of course you don't, thats why you always question my methods without having the full understanding.

How else would I learn, if I don't have a complete understanding. It isn't like there are any other experts to ask with this expertise or a textbook I could check.

My psuedologic for the perfect and untouchable rounds still stand and are very doable. That wasn't a suggestion of what to do, but a statement that it is possible, mostly for the benefit of others. Sorry, I wasn't to clear to whom that was direct to, and am fault here.

, yeah im aware of that and I rarely use vars in the helpers anyway.

I'd be worried that the memory stack has a buffer overflow, especially in the case of DragonClaw. Do player objects have a fixed size in memory?

[ClubSyN-X-TReME]

as far as the fixed size memory, I doubt thatm but im sure when I do release my screenpack since it contains of custom features im trying to make compatible with all mugen chars I expect some possible bug reports and ppls thoughts on their experience with my works.

I will wait until then before going into that aspect. That will help me better everything in the future.