Mike Mugen :: Voir le sujet

Inscrit le: 11 Oct 2006

Objectif du test : utiliser l'AssertSpecial "RoundNotOver" pour outre-passer le fonctionnement normal qui fait qu'appuyer sur un bouton a pour effet de zapper la WinPose.

Mon test en détails :
1. Je crée un helper pendant la WinPose
2. J'active un flag RoundNotOver actif tant que le helper existe
3. Appuyer sur "A" ne détruit pas le helper

Code:

; Win state decider
[Statedef 180]
type = S

[State 180, 1]
type = ChangeState
trigger1 = Time = 0
value = 181
;---------------------------------------------------------------------------
; Win pose 1
[Statedef 181]
type = S
ctrl = 0
anim = 0

[State 181, 1]
trigger1= time = 1
type=Helper
id=1
stateno=182
keyctrl=1

[State 181, 2]
type=assertspecial
trigger1=time > 1 && numhelper(1)>0
flag=roundnotover
;---------------------------------------------------------------------------
[Statedef 182]
type=S
ctrl=0
anim=6525

[State 182, 3]
type=destroyself
trigger1=animelemno(0)=16 && command="a"

Résultat attendu :
Si j'appuie sur A pendant tout autre élément que le n°16, mon helper n'est pas détruit donc mon AssertSpecial est toujours actif, donc ma winpose n'est pas zappée.

Résultat obtenu :
La WinPose est zappée même si j'appuie pendant tout autre élément que le n°16...

Le flag "RoundNotOver" n'est pas pris en compte si on appuie sur un bouton pendant la winpose.

La pertinence de cette information peut échapper à nombre d'entre vous, cependant c'est important quand on essaie de faire des trucs originaux !!!

Inscrit le: 07 Oct 2004

Perso, je trouve le comportement de Mugen assez normal, sur ce coup-là.

En effet, même si le nom "RoundNotOver" (RoundPasTerminé, en traduction littérale) n'est pas forcément bien choisi, son "effet" est assez clair dans la doc d'Elecbyte :

traduction de sctrls.txt a écrit:

- roundnotover : Dit à MUGEN que le personnage fait actuellement sa winpose. Doit être contrôlé sur tous les ticks que dure la winpose.

A mon avis, ce flag informe juste Mugen que le personnage est en WinPose, et qu'il doit donc attendre avant de faire le fondu en noir et passer au round suivant. Pour moi, il sert juste à éviter que l'anim de winpose ne soit coupée en plein milieu si le joueur ne touche pas aux boutons. Wink

Mais ça n'empêche pas de zapper la winpose en appuyant sur un bouton...

Techniquement, empêcher de zapper la winpose serait très difficile. Il faudrait forcer Mugen à ne pas passer en RoundState = 4, et le seul moyen que je vois, ce serait de maintenir l'adversaire en vie. Ca voudrait dire placer l'adversaire dans un custom state, qui ne le "tuerait" vraiment qu'une fois la winpose achevée.

Le moyen le plus simple serait peut-être de placer un helper sur P2, qui activerait un hitdef avec un p2stateno si les dommages du hitdef sont supérieurs à la vie de P2. Dans ce cas, le hitdef enlèverait la vie de P2 - 1 point, et le placerait au sol. Faudrait aussi recréer un effet de ralenti (avec un Pause déclenché 1 tick sur 2, c'est peut-être jouable). Là, P1 fait sa winpose, et lorsqu'elle est finie, l'helper achève P2.

Mais ça me semble quand même compliqué à mettre en place. Ca reprend un peu le principe de fée pour Link, qui l'empêche de mourir en le maintenant à 1 point de vie, puis le "ranime" en lui redonnant de la vie, mais c'est plus simple car appliqué à P1 (avec un HitOverride). Ici, il faudrait appliquer le HitOverride sur P2, pour que l'helper annule le coup de P1 censé tuer P2...

Mike Werewolf.

Inscrit le: 11 Oct 2006

Il me semble pourtant que dans beaucoup de jeux, appuyer sur un bouton ne fait qu'accélérer l'affiche des statistiques de fin de match. Enfin bref.

Effectivement, le contournement qui consiste à ne pas changer de RoundState est vraiment trop compliqué pour ce que je veux faire...
La bonne nouvelle, c'est que les directions, elles, ne zappent pas la WinPose donc je suis sauvé !

Mon WIP avance !!! Mr. Green

Inscrit le: 07 Oct 2004

Citation:

Il me semble pourtant que dans beaucoup de jeux, appuyer sur un bouton ne fait qu'accélérer l'affiche des statistiques de fin de match. Enfin bref.

Yep, c'est le cas dans SFII et consors. Mais dans Mugen, au lieu d'accélérer la scène, ça saute purement et simplement la fin du round.

Je suppose que dans des jeux "finis" tels que SF2, le timing des anims est connu, tout peut-être prévu à l'avance, et donc on peut imposer qu'il se passe telle et telle chose entre le moment où un des persos est KO et le moment où on change de round, et que cet intermède dure tant de temps. Dans Mugen, pas possible, vu que chacun crée ses stages, screenpacks, persos de son côté et que les utilisateurs assemblent le tout. Ici, on ne peut pas harmoniser les fins de rounds (ou les intros), sauf à faire un jeu complet ; je suppose que c'est la raison qui a poussé Elecbyte à faire ce choix.

Wink

Mike Werewolf.