Aiuto
Salve a tutti, avrei bisogno di creare un Helper ke faccia una mossa incrociata con il giocatore principale.
L'idea è questa: Arriva l'helper prende l'avversario e lo lancia in aria, poi il giocatore prende la mira con un arma e lo fredda in aria. Naturalmente è una Hyper, ke toglie quasi tutta l'energia
Pagina 1 di 1
Mosse incrociate con Helper
#2
- Art is deader than dead
-
- Gruppo: Membro
- Messaggi: 749
- Iscritto: 16-February 08
Inviato 24 November 2008 - 19:26
In sostanza direi che per fare una cosa del genere crei uno statedef all'interno metti uno state che sarà quello che porta all'helper e poi programmi l'azione del p1 cioè lui che fredda l'avversario in aria, poi crei uno statedef apposito per l'helper e ci metti l'animazione e l'hitdef poi per far si che lanci l'avversario in aria programmerei nell'air la presa... scusami se non sono stato molto esauriente però tra poco devo andare via...
#3
- Horse Rider Skull Phantom. Rarely Here.
-
- Gruppo: SuperModeratore
- Messaggi: 4898
- Iscritto: 11-July 04
Inviato 24 November 2008 - 20:35
E' una cosa complessa. Ti devi fare uno schema preciso, secondo me. Una cosa del genere
-----------
Azioni del Giocatore
-------------
State 3000: Giocatore fa apparire Helper (Helper stateno = 3010) e sta in attesa. Se Helper fallisce, vai a state 3001, se Helper riesce a fare la presa, vai a 3002
State 3001: Caso 1) l'Helper fallisce la presa. Il Giocatore torna quindi allo state 0.
State 3002: Caso 2 - Parte I) L'Helper riesce ad eseguire la presa. Giocatore rimane in attesa aspettando la sincronia della presa dell'Helper. Quando è il momento di colpire, vai a state 3003
State 3003: Caso 2 - Parte II) Continua da precedente. Giocatore prende la mira e lo fredda in aria. Al termine dell'animazione torna allo state 0.
-------------
Azioni dell' Helper
-------------
State 3010: Helper appare e cerca di raggiungere l'avversario
State 3011: Helper avvia la presa. State del tentativo di presa. Se presa riesce vai a 3020 (+ custom state 3028 per l'avversario che subisce la presa). Se presa fallisce vai a 3012
State 3012: Helper fallisce la presa. Scompare e si distrugge.
State 3020: Helper esegue la presa sul giocatore. Al termine va a state 3025
State 3025: Helper scompare dopo la presa e si distrugge
State 3028: Avversario subisce la presa dell'Helper. Qui programmati i comportamenti base dell'avversario (es. il richiamo all'animazione personalizzata da eseguire).
##################
I numeri di state che ti ho fatto vedere, sono indicativi. E' ovvio che questo è uno schema di massima, che va rifinito a seconda delle tue esigenze specifiche. Come vedi è molto complesso (molti state) perché personalmente preferisco dedicare ad ogni azione specifica un singolo state, così da controllare al meglio ogni singolo aspetto di una mossa. Nulla ti vieta di organizzarti diversamente.
Ti dò solo una indicazione: visto che tu devi coordinare i movimenti dell'helper e del personaggio principale ti dò un accenno di un argomento di programmazione avanzata, che ti è INDISPENSABILE per programmare bene un effetto del genere: la trigger re-direction.
Ogni trigger (che normalmente fa riferimento all'oggetto di riferimento - se programmato nell'Helper si riferisce all'Helper, se programmato nel personaggio principale si riferisce al personaggio principale) può essere indirizzato (rediretto) a valutare la condizione su un altro oggetto.
In poche parole è possibile, ad esempio, per il personaggio principale verificare qualcosa inerente all'Helper, ed è possibile per l'Helper verificare qualcosa inerente al personaggio principale. Come fare? con una istruzione come questa
trigger1 = helper(10), trigger
in questo caso il trigger "trigger", contenuto all'interno di una istruzione del personaggio principale, valuterà la variabile desiderata all'interno dell'Helper 10.
trigger1 = helper(10), stateno = 3025
persistent = 0
con queste due istruzioni si fa in modo che, ad esempio, il giocatore esegua il comando quando l'Helper entra nello state 3025. Il parametro persistent=0 fa in modo che l'istruzione venga eseguita una sola volta.
Eccoti le redirezioni che ti possono interessare
helper (ID),
parent,
root,
Il primo rediriziona sull'helper desiderato (identificato con un ID numerico)
"parent" è valido solo all'interno di un helper. Redireziona il trigger rispetto a colui che ha creato l'helper (solitamente il giocatore)
"root" è valido solo su un helper. Rediriziona sempre al giocatore. Utile solo in caso di Helpers creati da altri Helper. Altrimenti è meglio usare "parent".
------
Spero di essermi spiegato decentemente :unsure:
-----------
Azioni del Giocatore
-------------
State 3000: Giocatore fa apparire Helper (Helper stateno = 3010) e sta in attesa. Se Helper fallisce, vai a state 3001, se Helper riesce a fare la presa, vai a 3002
State 3001: Caso 1) l'Helper fallisce la presa. Il Giocatore torna quindi allo state 0.
State 3002: Caso 2 - Parte I) L'Helper riesce ad eseguire la presa. Giocatore rimane in attesa aspettando la sincronia della presa dell'Helper. Quando è il momento di colpire, vai a state 3003
State 3003: Caso 2 - Parte II) Continua da precedente. Giocatore prende la mira e lo fredda in aria. Al termine dell'animazione torna allo state 0.
-------------
Azioni dell' Helper
-------------
State 3010: Helper appare e cerca di raggiungere l'avversario
State 3011: Helper avvia la presa. State del tentativo di presa. Se presa riesce vai a 3020 (+ custom state 3028 per l'avversario che subisce la presa). Se presa fallisce vai a 3012
State 3012: Helper fallisce la presa. Scompare e si distrugge.
State 3020: Helper esegue la presa sul giocatore. Al termine va a state 3025
State 3025: Helper scompare dopo la presa e si distrugge
State 3028: Avversario subisce la presa dell'Helper. Qui programmati i comportamenti base dell'avversario (es. il richiamo all'animazione personalizzata da eseguire).
##################
I numeri di state che ti ho fatto vedere, sono indicativi. E' ovvio che questo è uno schema di massima, che va rifinito a seconda delle tue esigenze specifiche. Come vedi è molto complesso (molti state) perché personalmente preferisco dedicare ad ogni azione specifica un singolo state, così da controllare al meglio ogni singolo aspetto di una mossa. Nulla ti vieta di organizzarti diversamente.
Ti dò solo una indicazione: visto che tu devi coordinare i movimenti dell'helper e del personaggio principale ti dò un accenno di un argomento di programmazione avanzata, che ti è INDISPENSABILE per programmare bene un effetto del genere: la trigger re-direction.
Ogni trigger (che normalmente fa riferimento all'oggetto di riferimento - se programmato nell'Helper si riferisce all'Helper, se programmato nel personaggio principale si riferisce al personaggio principale) può essere indirizzato (rediretto) a valutare la condizione su un altro oggetto.
In poche parole è possibile, ad esempio, per il personaggio principale verificare qualcosa inerente all'Helper, ed è possibile per l'Helper verificare qualcosa inerente al personaggio principale. Come fare? con una istruzione come questa
trigger1 = helper(10), trigger
in questo caso il trigger "trigger", contenuto all'interno di una istruzione del personaggio principale, valuterà la variabile desiderata all'interno dell'Helper 10.
trigger1 = helper(10), stateno = 3025
persistent = 0
con queste due istruzioni si fa in modo che, ad esempio, il giocatore esegua il comando quando l'Helper entra nello state 3025. Il parametro persistent=0 fa in modo che l'istruzione venga eseguita una sola volta.
Eccoti le redirezioni che ti possono interessare
helper (ID),
parent,
root,
Il primo rediriziona sull'helper desiderato (identificato con un ID numerico)
"parent" è valido solo all'interno di un helper. Redireziona il trigger rispetto a colui che ha creato l'helper (solitamente il giocatore)
"root" è valido solo su un helper. Rediriziona sempre al giocatore. Utile solo in caso di Helpers creati da altri Helper. Altrimenti è meglio usare "parent".
------
Spero di essermi spiegato decentemente :unsure:
#4
- Senpai
-
- Gruppo: Membro
- Messaggi: 941
- Iscritto: 14-September 05
Inviato 24 November 2008 - 20:59
Mi hai chiarito le idee..... Grazie mille Nobun e ben tornato
Cmq poi ti mando un pm con un codice mio di un Helper già creato, perkè credo di averlo programmato male. Infatti il mio Helper quando colpise l'avversario va tutto bene, ma se viene colpito, ho difficoltà a far cambiare state al mio giocatore.
Lo sapevo ke era complesso, ma fattibile. Vorrei fare una cosa alla Rival Schools tanto per intenderci.
PS: a seconda della posizione in cui si troverà l'avversario lanciato in aria dall'helper poi il giocatore dovrà cambiare animazione ed usare armi differenti. Spero si possa fare
Cmq poi ti mando un pm con un codice mio di un Helper già creato, perkè credo di averlo programmato male. Infatti il mio Helper quando colpise l'avversario va tutto bene, ma se viene colpito, ho difficoltà a far cambiare state al mio giocatore.
Lo sapevo ke era complesso, ma fattibile. Vorrei fare una cosa alla Rival Schools tanto per intenderci.
PS: a seconda della posizione in cui si troverà l'avversario lanciato in aria dall'helper poi il giocatore dovrà cambiare animazione ed usare armi differenti. Spero si possa fare
#5
- Horse Rider Skull Phantom. Rarely Here.
-
- Gruppo: SuperModeratore
- Messaggi: 4898
- Iscritto: 11-July 04
Inviato 24 November 2008 - 21:12
Se vuoi rendere il tuo Helper colpibile, devi complicare ulteriormente il codice.
In ogni fase dell'Helper (dove ci sono clsn2 attivi) devi attivare un HitOverride in modo tale che, nel caso venga colpito, l'Helper vada ad un altro state (ancora diverso) che gestisce in maniera personalizzata la caduta dell'helper dopo aver subito il colpo e la scomparsa.
Fondamentale: Durante l'esecuzione della presa l'Helper deve essere assolutamente incolpibile. Quindi:
1) O NON deve avere clsn2 attivi (in fase di esecuzione di presa, scelta preferibile)
2) O deve aver programmato un NotHitBy (value = SCA)
Fondamentale: Durante l'esecuzione della caduta personalizzata (rimandata dall'HitOverride), compresa la scomparsa, l'Helper deve essere essere assolutamente incolpibile. In questo secondo caso è preferibile l'opzione 2)
Fondamentale: Durante la scomparsa finale dell'Helper, l'Helper deve essere incolpibile. Come sopra.
In ogni fase dell'Helper (dove ci sono clsn2 attivi) devi attivare un HitOverride in modo tale che, nel caso venga colpito, l'Helper vada ad un altro state (ancora diverso) che gestisce in maniera personalizzata la caduta dell'helper dopo aver subito il colpo e la scomparsa.
Fondamentale: Durante l'esecuzione della presa l'Helper deve essere assolutamente incolpibile. Quindi:
1) O NON deve avere clsn2 attivi (in fase di esecuzione di presa, scelta preferibile)
2) O deve aver programmato un NotHitBy (value = SCA)
Fondamentale: Durante l'esecuzione della caduta personalizzata (rimandata dall'HitOverride), compresa la scomparsa, l'Helper deve essere essere assolutamente incolpibile. In questo secondo caso è preferibile l'opzione 2)
Fondamentale: Durante la scomparsa finale dell'Helper, l'Helper deve essere incolpibile. Come sopra.
#6
- Senpai
-
- Gruppo: Membro
- Messaggi: 941
- Iscritto: 14-September 05
Inviato 24 November 2008 - 21:15
Ascolta x non complicarmi la vita quando il mio Helper fa la classica combo non ha i box di collisione blu. Questo comporterebbe qualke problema?
#7
- Horse Rider Skull Phantom. Rarely Here.
-
- Gruppo: SuperModeratore
- Messaggi: 4898
- Iscritto: 11-July 04
Inviato 25 November 2008 - 22:51
Se togli la collisione blu, l'Helper non ha corpo, quindi può essere letteralmente "attraversato" da un altro giocatore (player o avversario che sia).
Se vuoi evitare questo, ma vuoi renderlo incolpibile, basta inserire, in ognuno degli state dell'Helper, questo comando all'inizio dello state in questione.
[State x, NotHitBy]
type = NotHitBy
value = SCA
trigger1 = 1
Se vuoi evitare questo, ma vuoi renderlo incolpibile, basta inserire, in ognuno degli state dell'Helper, questo comando all'inizio dello state in questione.
[State x, NotHitBy]
type = NotHitBy
value = SCA
trigger1 = 1
#8
- Chan
-
- Gruppo: Membro
- Messaggi: 12
- Iscritto: 14-December 07
Inviato 01 December 2008 - 00:06
Nobun, su Nov 24 2008, 20:35, detto:
E' una cosa complessa. Ti devi fare uno schema preciso, secondo me. Una cosa del genere
-----------
Azioni del Giocatore
-------------
State 3000: Giocatore fa apparire Helper (Helper stateno = 3010) e sta in attesa. Se Helper fallisce, vai a state 3001, se Helper riesce a fare la presa, vai a 3002
State 3001: Caso 1) l'Helper fallisce la presa. Il Giocatore torna quindi allo state 0.
State 3002: Caso 2 - Parte I) L'Helper riesce ad eseguire la presa. Giocatore rimane in attesa aspettando la sincronia della presa dell'Helper. Quando è il momento di colpire, vai a state 3003
State 3003: Caso 2 - Parte II) Continua da precedente. Giocatore prende la mira e lo fredda in aria. Al termine dell'animazione torna allo state 0.
-------------
Azioni dell' Helper
-------------
State 3010: Helper appare e cerca di raggiungere l'avversario
State 3011: Helper avvia la presa. State del tentativo di presa. Se presa riesce vai a 3020 (+ custom state 3028 per l'avversario che subisce la presa). Se presa fallisce vai a 3012
State 3012: Helper fallisce la presa. Scompare e si distrugge.
State 3020: Helper esegue la presa sul giocatore. Al termine va a state 3025
State 3025: Helper scompare dopo la presa e si distrugge
State 3028: Avversario subisce la presa dell'Helper. Qui programmati i comportamenti base dell'avversario (es. il richiamo all'animazione personalizzata da eseguire).
##################
I numeri di state che ti ho fatto vedere, sono indicativi. E' ovvio che questo è uno schema di massima, che va rifinito a seconda delle tue esigenze specifiche. Come vedi è molto complesso (molti state) perché personalmente preferisco dedicare ad ogni azione specifica un singolo state, così da controllare al meglio ogni singolo aspetto di una mossa. Nulla ti vieta di organizzarti diversamente.
Ti dò solo una indicazione: visto che tu devi coordinare i movimenti dell'helper e del personaggio principale ti dò un accenno di un argomento di programmazione avanzata, che ti è INDISPENSABILE per programmare bene un effetto del genere: la trigger re-direction.
Ogni trigger (che normalmente fa riferimento all'oggetto di riferimento - se programmato nell'Helper si riferisce all'Helper, se programmato nel personaggio principale si riferisce al personaggio principale) può essere indirizzato (rediretto) a valutare la condizione su un altro oggetto.
In poche parole è possibile, ad esempio, per il personaggio principale verificare qualcosa inerente all'Helper, ed è possibile per l'Helper verificare qualcosa inerente al personaggio principale. Come fare? con una istruzione come questa
trigger1 = helper(10), trigger
in questo caso il trigger "trigger", contenuto all'interno di una istruzione del personaggio principale, valuterà la variabile desiderata all'interno dell'Helper 10.
trigger1 = helper(10), stateno = 3025
persistent = 0
con queste due istruzioni si fa in modo che, ad esempio, il giocatore esegua il comando quando l'Helper entra nello state 3025. Il parametro persistent=0 fa in modo che l'istruzione venga eseguita una sola volta.
Eccoti le redirezioni che ti possono interessare
helper (ID),
parent,
root,
Il primo rediriziona sull'helper desiderato (identificato con un ID numerico)
"parent" è valido solo all'interno di un helper. Redireziona il trigger rispetto a colui che ha creato l'helper (solitamente il giocatore)
"root" è valido solo su un helper. Rediriziona sempre al giocatore. Utile solo in caso di Helpers creati da altri Helper. Altrimenti è meglio usare "parent".
------
Spero di essermi spiegato decentemente :unsure:
-----------
Azioni del Giocatore
-------------
State 3000: Giocatore fa apparire Helper (Helper stateno = 3010) e sta in attesa. Se Helper fallisce, vai a state 3001, se Helper riesce a fare la presa, vai a 3002
State 3001: Caso 1) l'Helper fallisce la presa. Il Giocatore torna quindi allo state 0.
State 3002: Caso 2 - Parte I) L'Helper riesce ad eseguire la presa. Giocatore rimane in attesa aspettando la sincronia della presa dell'Helper. Quando è il momento di colpire, vai a state 3003
State 3003: Caso 2 - Parte II) Continua da precedente. Giocatore prende la mira e lo fredda in aria. Al termine dell'animazione torna allo state 0.
-------------
Azioni dell' Helper
-------------
State 3010: Helper appare e cerca di raggiungere l'avversario
State 3011: Helper avvia la presa. State del tentativo di presa. Se presa riesce vai a 3020 (+ custom state 3028 per l'avversario che subisce la presa). Se presa fallisce vai a 3012
State 3012: Helper fallisce la presa. Scompare e si distrugge.
State 3020: Helper esegue la presa sul giocatore. Al termine va a state 3025
State 3025: Helper scompare dopo la presa e si distrugge
State 3028: Avversario subisce la presa dell'Helper. Qui programmati i comportamenti base dell'avversario (es. il richiamo all'animazione personalizzata da eseguire).
##################
I numeri di state che ti ho fatto vedere, sono indicativi. E' ovvio che questo è uno schema di massima, che va rifinito a seconda delle tue esigenze specifiche. Come vedi è molto complesso (molti state) perché personalmente preferisco dedicare ad ogni azione specifica un singolo state, così da controllare al meglio ogni singolo aspetto di una mossa. Nulla ti vieta di organizzarti diversamente.
Ti dò solo una indicazione: visto che tu devi coordinare i movimenti dell'helper e del personaggio principale ti dò un accenno di un argomento di programmazione avanzata, che ti è INDISPENSABILE per programmare bene un effetto del genere: la trigger re-direction.
Ogni trigger (che normalmente fa riferimento all'oggetto di riferimento - se programmato nell'Helper si riferisce all'Helper, se programmato nel personaggio principale si riferisce al personaggio principale) può essere indirizzato (rediretto) a valutare la condizione su un altro oggetto.
In poche parole è possibile, ad esempio, per il personaggio principale verificare qualcosa inerente all'Helper, ed è possibile per l'Helper verificare qualcosa inerente al personaggio principale. Come fare? con una istruzione come questa
trigger1 = helper(10), trigger
in questo caso il trigger "trigger", contenuto all'interno di una istruzione del personaggio principale, valuterà la variabile desiderata all'interno dell'Helper 10.
trigger1 = helper(10), stateno = 3025
persistent = 0
con queste due istruzioni si fa in modo che, ad esempio, il giocatore esegua il comando quando l'Helper entra nello state 3025. Il parametro persistent=0 fa in modo che l'istruzione venga eseguita una sola volta.
Eccoti le redirezioni che ti possono interessare
helper (ID),
parent,
root,
Il primo rediriziona sull'helper desiderato (identificato con un ID numerico)
"parent" è valido solo all'interno di un helper. Redireziona il trigger rispetto a colui che ha creato l'helper (solitamente il giocatore)
"root" è valido solo su un helper. Rediriziona sempre al giocatore. Utile solo in caso di Helpers creati da altri Helper. Altrimenti è meglio usare "parent".
------
Spero di essermi spiegato decentemente :unsure:
Direi proprio di si.....:D
Nula di troppo complicato, si tratta di chiamare un helper che tenta la mossa, se la manca dice al parent "stai fermo", se la esegue invia il comando "finiscilo"....piuttosto semplice....:D
Pensandoci, si potrebbe fare anche così:
Si crea un statedef per il p2, che può subire solo da suddetto helper.....(per ipotesi statedef 12345)
poi in una porzione del codice del chars si inserisce una stringa del tipo (nella porzione relativa a statedef -2)
[State -2, l'Helper và a segno e il mio chars "Lo fredda in aria"]
type = ChangeState
trigger1 = P2StateNo = 12345 (il state in cui p2 entra quando l'helper lo fà schizzare in aria)
value = 3003 (lo state di esempio di Nobun)
ctrl = 0 (per evitare di poter prendere il possesso del nostro chars, magari "negandogli" di conseguenza la super. il ctrl settalo a 1 nell'effetivo state della super 3003)
Questa è una maniera alternativa....in mugen gli stessi risultati si posson ottenere in più modi....;)
Condividi questa discussione:
Pagina 1 di 1