[Menjoso]

Nobun, su Feb 24 2008, 12:47, detto:

Non si teletrasporta... si gira dall'altra parte :P

Sì, se sei abbastanza vicino all'avversario ma non troppo da eseguire la presa è possibile riuscire ad eseguire la hyper senza il primo colpo (anche nel char originale era possibile tale scorciatoia).

Ah beh.. gira, teletrasporta.. :P

Ah, gia che ci sono.. come si faceva la hyper di Nobunaga? :rotfl: :rotfl:

[Stickman]

Io lo stavo scaricando per provarla :P
Cmq l'ho provata subito dopo aver risolto il problema :D
PS: Maledetto winzip...
Stickman :rulez:

[Nobun]

Quale delle tante?

Comunque anche Nobunaga ha una movelist completa :P
(è in formato TXT ma si legge) :P

---------------------------
Hyper da 1 Power
---------------------------

Sword Launch (Lancio della spada) -> indietro, mezzo cerchio indietro, pugno
* se hai meno di 1/4 di energia non consuma power

Circle Flames (hyper) -> quarto di cerchio indietro, mezzo cerchio avanti, X+Y
(se premi solo uno dei due pugni esegue la versione special che è uguale ma è meno forte)

Gray Tornado -> mezzo cerchio avanti, mezzo cerchio avanti, pugno


---------------------------
Hyper da 2 Power
---------------------------

Hell's Flame -> quarto di cerchio indietro, quarto di cerchio indietro, A+B

----------------------------
Hyper da 3 Power
----------------------------

Thunder Extreme -> basso, basso, indietro, avanti, indietro, avanti, A+B
(quella che finisce l'avversario se va a segno)

----------------------------
Hyper del mantello
----------------------------

Questa hyper si esegue a prescindere da quanta power hai (quindi puoi averne anche 0) ma devono verificarsi le seguenti condizioni:

1) Avversario con meno di 200 punti vita
2) devi essere vicino all'avversario

Cloak Destroyer -> quarto di luna indietro, mezzo cerchio avanti, pugno
* se va a segno l'avversario muore.

-----

totale: 6 hyper

[Menjoso]

Azz, perchè avevo sentito parlare dell'hyper con la spada, dove hai usato tipo 10 statedefs! Pensa che io ne sto facendo una paurosa di hyper, dove uso 2 helper che attaccano in contemporanea (ho gia usato 6 statedefs e non è ancora finita!).

Poi magari provo le hyper di Nobunaga :P

I tuoi char li ho gia da un bel po, però non li ho mai esaminati a fondo. Sto scoprendo molte cose :P

Nobun :rulez:

Stickman :rulez:

[Nobun]

Nobunaga, tra tutti, è il char con programmazione più complessa anche se è il primo (perché alcune cose richiedevano maggiore complessità).

Comunque ricordi bene... gli state necessari per il lancio della spada sono molti (una decina circa)

Se guardi il file "hypers.cns" gli state impiegati per quella hyper sono tutte le righe che vedi a partire dallo [StateDef 3700] fino alla fine del file "hypers.cns"

Per semplificarti l'analisi gli states sono così suddivisi

COMPORTAMENTI DI NOBUNAGA
(states 3700+)

COMPORTAMENTI DELA SPADA
(states 3800+)

-------------------

3700-3701 lo state in cui nobunaga lancia la spada e rimane col braccio teso per sapere se va a segno o meno (non ricordo più a cosa servisse esattamente il 3701 però era un fix per alcuni casi in cui la spada non colpiva anche se andava a segno).

3710 nel caso in cui la spada va a segno e comincia a tagliuzzare l'avversario Nobunaga si muove alzando il braccio e controllando la spada

3720 nobunaga, una volta che la spada ha finito di tagliuzzare l'avversario e quando comincia a cadere a terra, egli va ad indicare il suolo dove cadrà la spada

3740 stessa animazione nel caso in cui però la spada sta cadendo, ma ha mancato il bersaglio. Qui l'animazione ha durata più breve perché in caso di errore Nobunaga può riprendere il controllo prima

--------------

3800 la spada è in volo orizzontalmente (in lancio)

3810 la spada tagliuzza l'avversario (la serie di 87 colpi)

3820 la spada vola a terra (sia dopo colpo riuscito che dopo colpo fallito viene eseguito questo state)

3840 la spada è a terra pietrificata (se aveva mancato il bersaglio la spada, dopo la caduta di cui allo state 3820 passa a questo state. La spada rimane pietrificata ed inattiva per 10 secondi. In questo lasso di tempo non può essere raccolta)

3850 animazione di transizione della spada da pietrificata ad attiva (ancora non può essere presa). Ora sono passati i 10 secondi dello state precedente e la spada sta tornando attiva

3870 spada a terra ed attiva (perché caduta dopo colpo andato a segno o perché la spada, dopo il colpo fallito, non è più pietrificata)

---------------

A tutto questo si aggiunge un altro state separato che è lo state

814 -> Nobunaga raccoglie la spada che si trova a terra. Nello state 814 ci si limita ad una animazione che comprende tutto. Infatti, appena Nobunaga entra in questo state la spada - intesa come elemento Helper autonomo - si distrugge immediatamente

Questo in virtù dell'ultima riga dello state 3870

[State 3870, 2]
type = DestroySelf
trigger1 = parent, stateno = 814

per l'appunto la spada si distrugge quando Nobunaga passa allo state 814

-----

Sono stato esauriente? :P

PS occhio che Nobunaga, essendo il mio primo char, contiene qualche errore di concetto e di metodologia di programmazione.

PS2 lo state 814 si trova nel file "spada.cns"

[Menjoso]

Nobun, su Feb 24 2008, 18:08, detto:

Nobunaga, tra tutti, è il char con programmazione più complessa anche se è il primo (perché alcune cose richiedevano maggiore complessità).

Comunque ricordi bene... gli state necessari per il lancio della spada sono molti (una decina circa)

Se guardi il file "hypers.cns" gli state impiegati per quella hyper sono tutte le righe che vedi a partire dallo [StateDef 3700] fino alla fine del file "hypers.cns"

Per semplificarti l'analisi gli states sono così suddivisi

COMPORTAMENTI DI NOBUNAGA
(states 3700+)

COMPORTAMENTI DELA SPADA
(states 3800+)

-------------------

3700-3701 lo state in cui nobunaga lancia la spada e rimane col braccio teso per sapere se va a segno o meno (non ricordo più a cosa servisse esattamente il 3701 però era un fix per alcuni casi in cui la spada non colpiva anche se andava a segno).

3710 nel caso in cui la spada va a segno e comincia a tagliuzzare l'avversario Nobunaga si muove alzando il braccio e controllando la spada

3720 nobunaga, una volta che la spada ha finito di tagliuzzare l'avversario e quando comincia a cadere a terra, egli va ad indicare il suolo dove cadrà la spada

3740 stessa animazione nel caso in cui però la spada sta cadendo, ma ha mancato il bersaglio. Qui l'animazione ha durata più breve perché in caso di errore Nobunaga può riprendere il controllo prima

--------------

3800 la spada è in volo orizzontalmente (in lancio)

3810 la spada tagliuzza l'avversario (la serie di 87 colpi)

3820 la spada vola a terra (sia dopo colpo riuscito che dopo colpo fallito viene eseguito questo state)

3840 la spada è a terra pietrificata (se aveva mancato il bersaglio la spada, dopo la caduta di cui allo state 3820 passa a questo state. La spada rimane pietrificata ed inattiva per 10 secondi. In questo lasso di tempo non può essere raccolta)

3850 animazione di transizione della spada da pietrificata ad attiva (ancora non può essere presa). Ora sono passati i 10 secondi dello state precedente e la spada sta tornando attiva

3870 spada a terra ed attiva (perché caduta dopo colpo andato a segno o perché la spada, dopo il colpo fallito, non è più pietrificata)

---------------

A tutto questo si aggiunge un altro state separato che è lo state

814 -> Nobunaga raccoglie la spada che si trova a terra. Nello state 814 ci si limita ad una animazione che comprende tutto. Infatti, appena Nobunaga entra in questo state la spada - intesa come elemento Helper autonomo - si distrugge immediatamente

Questo in virtù dell'ultima riga dello state 3870

[State 3870, 2]
type = DestroySelf
trigger1 = parent, stateno = 814

per l'appunto la spada si distrugge quando Nobunaga passa allo state 814

-----

Sono stato esauriente? :P

PS occhio che Nobunaga, essendo il mio primo char, contiene qualche errore di concetto e di metodologia di programmazione.

PS2 lo state 814 si trova nel file "spada.cns"

Ahia, ora capisco come mai usava così tanti states. Perchè oltre all'helper hai anche delle variabili (colpisce o non colpisce). Eh, la mia è di gran lunga piu semplice quindi, anche se uso 1 helper :P

Mi chiedo come poteva essere il primo char con una roba così, se anche io ce la farò, bene, se no ti ho scoperto, sei Dio :rotfl:

Una cosa non mi è chiara, è la prima volta che lo leggo:

[State 3870, 2]
type = DestroySelf
trigger1 = parent, stateno = 814

Per cosa sta Parent qui? Non bastava Stateno = 814?

Comunque quando mi metto a provare la hyper vedo anche il codice, che non si sa mai :P

[Nobun]

Assolutamente no.

La spada in questo momento è un Helper ciò significa che è un oggetto che si differenzia rispetto al char.

In questa istruzione io voglio che la spada si distrugga quando NOBUNAGA (e non la spada) si trova allo state 814.

se avessi messo solo

trigger1 = stateno = 814

non avrebbe funzionato (perché lo state DELLA SPADA è il 3870).

Invece per far valutare alla spada lo state di NOBUNAGA devo fare una trigger-redirection.

con l'espressione

parent,

io reindirizzo il trigger valutando l'espressione su "parent" ovvero colui che ha creato l'helper (e quindi dirigo la valutazione su Nobunaga perché l'helper è nato direttamente nel char e non da altro helper).

la trigger re-direction e le possibili espressioni sono spiegate nel tutorial "exp" (il più complesso di tutta la documentazione Mugen).

Un altro esempio lo vedi nello state 3700

[State 3700, 4]
type = ChangeState
trigger1 = helper(10), stateno = 3810
value = 3710

Questo comando fa sì che Nobunaga passi allo state 3710 se la spada (ovvero l'Helper con indice 10) si trova allo state 3810 (state della spada in cui la stessa si mette a sminuzzare l'avversario perché è andata a segno).

Se tu noti spesso la spada e Nobunaga si scambiano le informazioni tra di loro.

----

Le var(10) sono gli stati possibili della spada e può assumere i seguenti valori

0 -> nel fodero
1 -> in mano
2 -> in lancio
3 -> recupero fallito
4 -> spada a terra pietrificata
5 -> spada a terra attiva e recuperabile

----------------

Edit aggiunta.

Guarda ad esempio questa perla in Nobunaga

[State -1, Riprendo Spada da terra]
type = ChangeState
value = 814
triggerall = var(30) = 0
triggerall = ctrl && var(10) = 5
triggerall = command = "b+x" && statetype = C
trigger1 = (helper(10), parentDist X >= -15) && (helper(10), parentDist X <= 15)

sempre sulla gestione della spada qui è la gestione del recupero della spada (quando è possibile quindi passare allo state 814 di recupero della spada).

Non occorre che dica che questo codice è nel CMD.

il primo triggerall valuta che la AI sia disattiva ( var(30) )
il secondo trigger verifica che hai il controllo (ctrl) e che la spada sia a terra ed attiva e quindi raccoglibile ( var(10) = 5 )

il terzo trigger verifica che si prema "b+x" e che tu sia in uno statetype da accovacciato.

L'ultimo trigger è la perla. Esso verifica che la posizione di Nobunaga non sia più distante di 15 pixel rispetto alla posizione della spada (sia in avanti che in indietro).

Per farlo l'unico modo è usare il trigger ParentDist che però valuta la distanza tra un Helper e chi lo ha creato (e non invece tra il char ed un Helper). Quindi è necessario reindirizzarlo all'Helper(10).

Quindi Helper(10), ParentDist X

valuta, rispetto all'helper(10) (la spada), la distanza tra lui (la spada) e il suo genitore (Nobunaga).

[Menjoso]

Ah ora ho capito il parent, avevo fatto un semplice errore sbadato, non considerando che quel codice destroyself era nello state della spada, e quindi avrebbe fatto riferimento ad essa e non al char :P

Grazie delle spiegazioni e i chiarimenti, sempre esauriente :D

[Nobun]

Figurati.

Ti preciso che, stante alla mia inesperienza dell'epoca, quel tratto di codice contiene un piccolo errore.

Negli HitDef dello state 3810 vedrai espressioni come

triggerX = animelem >= X

Ebbene questo è un errore perché il trigger animelem non supporta le espressioni (le uniche espressioni consentite con animelem sono = e != (uguale e diverso) e quindi non valgono i segni di disuguaglianza né le espressioni di contenimento di valore). Questa è una cosa molto fine che si nota solo dopo qualche anno da smanettoni, quindi posso essere perdonato :rotfl:

Ovviamente l'errore non l'ho mai corretto perché comunque, nonostante tale imperfezione, la mossa funzionava lo stesso come volevo (onde rischiare di peggiorare la situazione :P)

-----

PS L'espressione DestroySelf è sempre contenuta in un Helper :rolleyes:

[Stickman]

Uhm... la programmazione dei chars mi sembra abbastanza intuitiva...
Chissa se ank'io un giorno comincerò a programmare come il menjo :rolleyes:

[Menjoso]

Mah, una volta che hai capito il sistema e ti abitui a ragionare un po penso che non sia nulla di speciale infondo :P

Poi se vuoi fare roba come quella della Spada di Nobunaga credo di non essere ancora in grado.

[Nobun]

E' molto più semplice di quello che pensi (ed io non sono affatto un genio).
La suddivisione in states l'ho dovuta un po' ragionare per razionalizzare al massimo il codice.

il file "spada.cns" è stato costruito a forza di esperimenti, problemi, risoluzioni varie a tutte le complicazioni che via via si presentavano (a volte soluzioni abbastanza "arrangiate")...

Più che bravura è stata opera di ESTREMA pazienza... è stato terribilmente distruttivo farlo (quando avevo finito non ne potevo più... na noia che non ti dico)

Il codice è così lungo perché dovevo controllare frame x frame il posizionamento ed il comportamento della spada, nonché l'inclinazione... tutte le volte modificandolo e riadattandolo...

Se vuoi che ti faccia vedere una espressione VERAMENTE complessa (quasi cervellotica) che ho creato dovresti vedere cosa ho combinato nel char di "cerbero" del pizzaiolo per la gestione della lifebar dell'helper :P

[Stickman]

Nobun, su Feb 26 2008, 20:39, detto:

...nel char di "cerbero"...

Di che char parli? :huh:

[Nobun]

Cerbero di Resident Evil.

Il char è stato fatto dal Pizzaiolo, ma un piccolissimo pezzo (la gestione della vita dell'helper) l'ho fatto io. Ed è lì che si può trovare tale espressione folle :P

[Stickman]

Oddio già immagino :ph34r:

[Nobun]

Sei sicuro? :P

Quote

[State 2500, 7]
type = Explod
anim = F1000 + 10*((parent, var(0)) /100)
pos = -50,0
bindtime = -1
removetime = -1
ownpal = 1
sprpriority = 4
id = 2001
trigger1 = time = 0


[State 2500, 8]
type = Explod
anim = F1000 + (((parent, var(0))-(((parent, var(0))/100)*100))/10) + ifelse(((parent, var(0))-(((parent, var(0))/10)*10))>0, 1,0)

pos = (-50 + 10*((parent, var(0)) /100)) ,0
bindtime = -1
removetime = -1
ownpal = 1
sprpriority = 4
id = 2002
trigger1 = time = 0

Questo è il codice per riprodurre la lifebar. Le espressioni sono così complesse per tre ordini di motivi:

1) La lifebar dell'helper è composta da due Explod (per un totale di 100 pixel di disegno). Una per le decine (10, 20, 30, ...., 90, 100) e una per le unità (0,1,2,3,...,8,9). Se rappresento quindi un valore life pari a 35 punti metto l'explod per 30 unità piene più un secondo explod attaccato al primo per 5 unità piene.

2) Il valore che rappresenta è un 1/10 del reale (l'helper ha vita pari a 1000 e visualizza 100 pixel di lifebar).

3) volevo evitare di mettere 200 comandi Explod (uno per ogni situazione possibile) ma riassumere tutto in una unica istruzione che fosse adattabile a tutte le casistiche (per un totale di due espressioni visto che la life è composta da due explod di lunghezza variabile).

PS: espressioni come (x / 100) * 100 non sono un errore. Sfruttano il fatto che, quando si dividono numeri di tipo intero, il risultato è sempre approssimato per difetto (i valori interi non sono in grado di accettare le cifre dopo la virgola).

Ad esempio una espressione come (582/100) * 100 arriva ad avere un valore pari a 500.

Infatti 582/100 farebbe 5,82. Ma abbiamo detto che le variabili intere perdono i valori dopo la virgola.
Quindi il risultato valutato dal computer non sarà 5,82 ma solo 5. (ovviamente 5 * 100 = 500)

-----

PS2: la seconda parte della espressione più complessa (secondo explod)

Quote

(...) + ifelse(((parent, var(0))-(((parent, var(0))/10)*10))>0, 1,0)

In realtà è frutto di pignoleria... serve ad essere sicuro che il risultato della lifebar sia approssimato per eccesso anziché per difetto.

Così che, anche se un char gli è rimasto solo un 1 punto vita (meno quindi di 10... abbiamo detto che la lifebar è lunga 1/10 del valore reale di vita dell'helper) la barra anziché essere vuota (perché ((1/10) * 10)) darebbe 0 per i motivi spiegati sopra) mostra sempre un pixel di energia (perché l'espressione aggiunta cambia il tipo di approssimazione rendendola per eccesso).

Sì una seconda parte di espressione così lunga solo per gestire un unico pixel... quello per l'approssimazione per eccesso.

[Menjoso]

E' normale che mi spaventi? :mellow: