[ninja]

Vorrei chiedervi 3 cose.
1) Perchè nel CMD è possibile definire lo state -1 di una mossa?? A cosa serve?
Si possono applicare trigger come se fosse lo state in un file CNS?

2)Nel CNS cos'è lo STATEDEF ??? Serve sempre per ogni mossa? E' simile allo state -1 nel file CMD?

3)Nel CNS perchè uno state è composto anche da un numero che incrementa?
tipo
[State 200,0]
...
[State 200,1]
...
[State 200,2]
...
E' un ordine di esecuzione??? Al posto dei numeri progressivi (0,1,2,...) ci possono essere anche delle lettere oppure solo numeri?

[Ice King]

allora, il numero ke te vedi scritto nn deve x forza essere un numero:

te definisci uno stato con

[statedef ####]
...

poi le singole operazioni
[state ####, explod]

....

capito come è articolato? x vedere poi come funziona lo state -1 guarda sui tutorial nel mugen

[SlayerGatsu]

Innanzi tutto benvenuto B)

allora

un file Cmd specifica i COMANDi del personaggio,
gli stati che scrivi al suo interno sono come dei "grilletti" (trigger) che fanno accadere uno statedef

uno

[statedef ###] ;(# sta per un numero)

definiscie una situazione ( o un attacco se preferisci, ma dire attacco e' limitativo)

qui infatti sono situati gli

[state ###]

uno state puo' essere numerato o chiamato come ti pare, non deve essere in seguenza matematica, NE il numero dello state deve essere uguale a quello dello statedef.
ANCHE SE
per un fatto di ordine e pulizia io RACCOMANDO di tenere i numer degli state in ordine...

[state 9numero statedef), {Parola o numero in ordine Logico o alphabetico} ]



dove definisci con parametri diversi cosa fara il char (sono il mezzo cun cui definisci)


Come la propria liberta gli stati e' gli state def cominciano dove comincia la liberta' di un altro, O meglio dove comincia un altro state o statedef


adesso lo State -1
non e' Come noterai uno state
BENSI uno Statedef!

[statedef -1]

infatto sotto di lui vengono definiti TANTI "grilletti" con degli Stati
ogni uno fa succedere qualcosa in relazione ai comandi.

che altro vuoi sapere?

[Nobun]

Chiarisco......

Con [StateDef X] (dove X è un numero) tu definisci l'inizio di uno state.

Ogni State contiene la programmazione di una azione (o di una parte di azione per le operazioni più complesse).

Ad esmpio lo [StateDef 0] contiene la programmazione del personaggio che sta fermo in piedi (contenuta in common1.cns per questo non lo vedi).

Vogliamo fare un pugno?

Devo dire al personaggio non solo come muoversi (l'animazione) ma anche che tipo di colpo sta sferrando, che suono produce, quanti danni procura, cosa succede all'avversario quando viene colpito......

quindi facciamo uno state 200 per il pugno

[StateDef 200]; i parametri degli StateDef sono spiegati nel tutorial CNS
type = S
movetype = A
physics = S
velset = 0,0
anim = 200
poweradd = 20
sprpriority = 2
ctrl = 0

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

Per far passare quindi il personaggio dallo stato di fermo in piedi (state 0) allo stato di "sferra il pugno" devi passare allo state 200 dove è stato programmato il pugno.

Quindi il valore contenuto in [StateDef X] serve a dare un numero allo state in questione e definire il punto di inizio dello stesso (finisce quando incontra un nuovo [StateDef] ).

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

ma poi devi programmare le singole istruzioni. Ognuna delle quali viene introdotta da

[State X, Y]

X e Y possono essere settati con una qualsiasi stringa, ma per avere un char ordinato e più facile da leggere (e quindi da correggere se vi sono errori) è consigliabile settare X come il valore di StateDef ed Y con una stringa o con un numero che ti permetta il riconoscimento nella segnalazione di errori.

quindi ad esempio:

[StateDef 200]
...
[State 200, QUELLO-CHE-VUOI] 
...

----

[StateDef 1100]
...
[State 1100, QUELLO-CHE-VUOI]

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

Tornando all'esempio del pugno

[StateDef 200]
....

;definisci il colpo. Quanti danni fa e cosa comporta
[State 200, 1]
type = HitDef
....
trigger1 = ...

;torna a stare fermo in piedi appena terminato il colpo
[State 200, 2]
type = ChangeState
value = 0
ctrl = 1
trigger1 = animtime = 0

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

lo [StateDef -1] utilizzato nel CMD è uno statedef speciale. Vedi che ha un numero negativo? (a parte gli state speciali -1, -2 e -3 sono ammessi solo valori positivi per gli statedef).

Serve al CMD uno [StateDef -1] perchè deve poter avere il modo di far sapere al char quando passare all'attacco.

[StateDef -1]

[State -1, Pugno debole normale]
type = ChangeState
value = 200
triggerall = command = "x"
triggerall = command != "holddown"
trigger1 = statetype = S
trigger1 = ctrl

l'istanza [state -1] dice al command:

"caro mio buon char, quando il giocatore preme il tasto x (triggerall = command = "x".... lascia per il momento perdere le altre istanze) tu devi andare allo state 200 (programmazione colpo debole)"

Quindi, come vedi è indispensabile.

------

Ovviamente gli [State -1] possono contanere qualunque tipo di istruzione CNS. L'istruzione però largamente preponderante è il ChangeState, visto che il compito principale del CMD è quello di chiamare l'azione del char associata ad un certo tipo di comando.

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

spero solo di non averti confuso le idee ulteriormente :wacko:

[ninja]

Grazie mille ora mi è piu' chiaro tutto il meccanismo

Cmq se io Scrivessi una cosa del tipo
[Statedef 200]
...
[State 200,1]
...
[State 1100,2] <---Fa parte dello statedef 200??
...


[Statedef 1100]
...
[State 1100,1]
...
[State 200,2] <---Fa parte dello statedef 1100??
...

Cioè gli "state" sono definiti subito dopo la dichiarazione dello "statedef"??? Il loro nome non conta proprio a nulla per il mugen? Serve solo al programmatore per tenere un determinato ordine?

Se il nome dello state non ci fosse? Tipo
[State] oppure [State 200] si riferiscono comunque al loro Statedef "padre"?

[Cayenna]

ninja, su Sep 2 2005, 14:19, detto:

[State 200,2]  <---Fa parte dello statedef 1100??
...

YES.

A, ciao e benvenuto.

[Nobun]

Esatto! :lol:

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

Ma è meglio far corrispondere il primo argomento col numero dello [StateDef].

Questo:

1- perchè la segnalazione di errori viene meno incasinata (in caso di problemi) [vedi esempio sotto]
2- perchè la lettura del tuo codice risulta più ordinata e corri meno rischi di fare confusione quando rileggi il codice.

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

Per farti capire il discorso dell'ordine pensa ad uno [StateDef X] che contiene 100 istanze (va bè, ho esagerato volutamente :P )

[StateDef 200]
..
[State 201, x]
..
[state 1200, x]
..
[state 1700, x]
.. 
[State...]

quando cerchi l'errore potresti avere difficoltà, quando rileggi il tuo CNS, a riuscire a capire che tutti gli [state] sono istanze dello state 200.

invece facendo corrispondere

[StateDef 200]
...
[state 200, x]
...
[State 200, y]
...
[state...]

salta subito all'occhio che tutto si riferisce allo state 200.

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

Poi segnalazione di errori (adesso sto andando a memoria, l'ordine e i messaggi potrebbero non essere identici a quelli che ti sto indicando in modo esemplificativo):

error loading p1
error loading char.def
error loading char.cns
error in [StateDef 200]
error parsing ChangeState
error in [State 1120, fine]
invalid parameter: vflue

quando leggi li messaggio di errore potresti essere indotto a pensare che l'errore stia nello stateDEF 1120 ed invece è nello stateDEF 200.

Quindi non è di poca utilità seguire il consiglio di usare una corrispondenza [State X, y] con X = numero dello [stateDef], perchè quello che tu scrivi in [state x, y] appare nella segnalazione di errori. E pertant, così facendo, non corri il rischio di essere fuorviato nella individuazione dello state in cui c'è il problema.

(il parametro y di [State X, y] serve per la segnalazione di errori. Y ti indica quale delle istanze contiene l'errore - nell'esempio y = fine).

:D :birra:

Sg: maestro perdi colpi.... state e statedef... gli mischi le idee in partenza :wacko:

[ninja]

Bene.... Thanks

Altra domandina:

in uno state si possono (o forse "si devono") inserire trigger...ma....
perchè in uno state a volte c'è trigger1 a volte trigger2......li mettono per usare tipi di condizioni uguali tipo:

trigger1 = time = 0 <---usa la condizione "time" (uguale a sotto)
trigger2 = time = 40 <---usa la condizione "time" (uguale a sopra)

oppure per ogni condizione (sia essa uguale o diversa da un'altra) il trigger aumenta di una unità tipo:

trigger1 = Pos Y != 0
trigger2 = AnimTime = 0

Io penso la prima che ho scritto sia quella giusta ma non ne sono certo...

[SlayerGatsu]

sono azioni differenti

trigger1 = 1 e' sempre vere ed e' la prima condizione

trigger2 = var920=3 e' solo valido se la ia variabile da quel risultato

SONO dipendenti ed indipendenti...

dipendenti nel senso che:

non puoi scrivere trigger2 SENZA avere un trigger1

indipendenti nel senzo che

trigger1 si riferisce ad una cosa

trigger2 ad un altra.


[state 200, 1]
tyoe = hitdef
trigger1 = animelem = 2
trigger2 = animelem = 3
trigger3 = animelem = 4
ecc...

crea un colpo che lolpiscie SIA con la seconda che con la terza che con la quarta animazione (tre trigger)

mentre scrivere
[state 200, 1]
tyoe = hitdef
trigger1 = animelem = 2
trigger1 = animelem = 3
trigger1 = animelem = 4

risulterebbe in una situazione totalmente impossibile... Si attiva quando l'immaggin e' contemporaneamente 2,3,4 cioe' MAI...

In oltre Quando vuoi creare molti parametri per definire un trigger devi usare le operazion...

&& per E

|| per O

quindi

trigger1 = (Statetype != A || atatetype != C || Statetype != S) && animelem = 1

Funziona Qundo (mail) il tipo di mossa non e' in aria O non e' in ginocchio O non e' in piedi, E l'elemento dell'animazione e e' il primo.

ok?

[Ice King]

complimenti ninja, impari in fretta!!! :birra:

[ninja]

Grazie ancora della risposta ...Piu' o meno ho capito...

...Dunque scrivere ...

[state 200, 1]
type = hitdef
trigger1 = animelem = 2
trigger2 = animelem = 3
trigger3 = animelem = 4

è la stessa cosa di scrivere

[state 200, 1]
type = hitdef
trigger1 = (animelem = 2 || animelem = 3 || animelem = 4)

invece scrivere ....

[state 200, 1]
type = hitdef
trigger1 = animelem = 2
trigger1 = animelem = 3
trigger1 = animelem = 4

è la stessa cosa di scrivere

[state 200, 1]
type = hitdef
trigger1 = (animelem = 2 && animelem = 3 && animelem = 4)

GIUSTO???


Inoltre il numero di trigger fino a che punto puo' arrivare...intendo..
trigger1
trigger2
trigger3
.
.
.
triggerX <---- il numero massimo di trigger qual'è????

Invece la concatenazione di condizioni ???
trigger1 = "condizione1" && "condizione2" || "condizione3" && ecc.... ha un limite massimo???

[SlayerGatsu]

NO! B) non ci sono limiti XD

o meglio... che ci e' mai arrivato?

i trigger Potrannno essere max 99 MAGARI, ma dubito che qualcuno ci sia mai arrivato.

l'altro e' infinito, MA alcuni parametri possono essere messi SOLO come ultimi... e' specificato nei docs...

Il resto era tutto giusto B)

[ninja]

AZIONE DA FARE: Il mio personaggio deve poter correre schiacciando 2 volte il "Forward" pero' alla fine della corsa (ovvero quando l'utente rilascia il pulsante) deve eseguire una animazione che sarebbe la frenata della corsa e poi ritorna allo stato normale in piedi.

Ho provato a sperimentare tale sequenza su un personaggio a caso che avevo ("AND16") il problema è che si mette a camminare, non corre, e esegue l'animazione al momento sbagliato quindi

--------------------FILE CMD--------------------

[Command]
name = "FF";Required (do not remove)
command = F, F
time = 10

[Command]
name = "frena"
command = ~F
time = 1

....altri command (sotto c'è anche il "/$F")....

[State -1]
type = ChangeState
value = 100
trigger1 = command = "FF"
trigger1 = statetype = S
trigger1 = ctrl = 1

[State -1]
type = ChangeState
value = 555
trigger1 = command = "frena"
trigger1 = statetype = S
trigger1 = ctrl = 1

--------------------FILE CNS--------------------

[Statedef 100]
type = S

[State 100, 1]
type = VarSet
trigger1 = Time >= 0
v = 10
value = 1


[Statedef 555]
type = S

[State 555, 1]
type = ChangeState
trigger1 = Var(10) = 1
value = 214

[State 555, 2]
type = VarSet
trigger1 = Var(10) = 1
v = 10
value = 0

Il personaggio schiacciando "F" cammina e rilasciandolo esegue l'animazione 214... se invece tento di farlo correre "FF" al primo rilascio del pulsante "F" mi fa l'animazione e quindi non corre mai!!!! Ma l'animazione dovrebbe farmela solo se Var(10) è uguale a 1 e Var(10) viene impostata a 1 solo nella corsa...molto strano

[Nobun]

La corsa è una cosa un po' particolare.....
....non è un evento come tutti gli altri.....

infatti richiede al'attivazione di un AssertSpecial (similmente alle intro e alle inding posiztions).

per la corsa l'assertSpecial deve essere definito, all'interno dello state dedicato alla corsa, in tale maniera.

[State X, Y]
type = AssertSpecial
flag = nowalk
trigger1 = 1 ;

In tal modo il personaggio che deve continuare la corsa sa che non deve comportarsi come di norma avviene e quindi, quando tu tieni premuto il tasto per far avanzare il char, non passa in automatico alla camminata come normalmente farebbe, ma rimane a correre.

--------

Per la frenata: rimuovi quel comando "frenata" e quel ChangeState che punta alla frenata dal tuo CMD.

Una scelta come questa, in questo particolare caso, crea conflitto con la programmazione di default della camminata (contenuta in common1.cns).

Per risolvere tutti i problemi (frenata e camminata) devi cambiare la programmazione dello [StateDef 100]

[Statedef 100]
type    = S
physics = S
anim = 100
sprpriority = 1

[State 100, 1]
type = VelSet
trigger1 = 1
x = const(velocity.run.fwd.x)

[State 100, 2];evita il passaggio automatico alla camminata.
type = AssertSpecial
trigger1 = 1
flag = NoWalk

[State 100, 3];Prevent from turning
type = AssertSpecial
trigger1 = 1
flag = NoAutoTurn

[State 100, 4]
type = ChangeState
trigger1 = command != "holdfwd"
value = 555

(in poche parole è uguale a quello di default, ma anzichè passare alla camminata quando non tieni più premuto in avanti passa alla frenata)

Potrebbe essere poi necessaria qualche modifica nella programmazione dello state della frenata (555). (Anzi è cosa quasi certa).

P.S. Hai scelto però un brutto numero. Gli state 400-600 generalmente sono usati per le mosse tipo crouching (da accucciato). Cfr. il tutorial air nella sottocartella docs del tuo Mugen.
(comunque nessuno ti vieta di lasciare la frenata nello [StateDef 555] ;) ).

P.S.2. Complimenti anche da parte mia per la rapidità nell'apprendimento :wow: :birra:

[SlayerGatsu]

scusa e'.... ma e' alquanto inutile...

[State 100, 4]
type = ChangeAnim
trigger1 = command != "holdfwd"
value = 555 

[State 100, 4]
type = Changestate
trigger1 = command != "holdfwd" && time = 30
value = 0

Cosi' non dovrai definire uno stato 555, Ma cambiera' l'animazione...

Se vogliamo sistemare ANCHE un EFFETTo di frenata lo possiamo fare RELATIVO all'animazione in questo stesso stato...

[state 100, brake]
type = veladd
trigger1 = anim = 555
X = -.99


la valuta -.99 e' PURAMENTE casuale (o ad occhio) dovrai fare delle prove per sistemarla... l'ultima cosa deve essere il changestate.

facci sapere se funziona B)

[Nobun]

Ehm, slay.....

quel codice non è corretto.

Se si vuole usare quella tua soluzione il ChangeState 0 deve essere cambiato.

[state 100,5]
type = ChangeState
value = 0
trigger1 = anim = 555 && animtime = 0

altrimenti è quasi certo che il char non passi mai allo state 0 (che time viene calcolato da quando si comincia la corsa!!!!).

Ed usare un'altro tipo di istanza di time può rischiare di far passare subito il char allo state 0 (perchè non puoi sapere per quanto tempo si è deciso di correre prima di frenare).

Comunque secondo me è meglio fare due state separati. Così la frenata la si può gestire meglio.

[Ice King]

Scusate, io x nn saper ne leggere ne scrivere ho fatto in modo tale ke, quando lascio il pulsante x la corsa cambia automaticamente stato e va in frenata... nn è meglio?

cioè avevo scritto una cosa del genere nello stato di definizione della corsa:

[state ###, frenata]
type = changestate
trigger1 = command != "Run_FWD"
value = 'lo stato della frenata'

poi ho definito lo stato della frenata come un semplice stato in cui, appena fatta l'animazione torna nella posizione di stand

penso ke sia + semplice e anke meglio

[ninja]

Grazie Nobun della risposta, la tua soluzione è perfetta

Inoltre ho messo un tempo di corsa che se inferiore a 10 ticks non esegue l'animazione della frenata ma ritorna allo stato "0"

[Statedef 100]
type    = S
physics = S
anim = 100
sprpriority = 1

[State 100, 1]
type = VelSet
trigger1 = 1
x = const(velocity.run.fwd.x)

[State 100, 2];evita il passaggio automatico alla camminata.
type = AssertSpecial
trigger1 = 1
flag = NoWalk

[State 100, 3];Prevent from turning
type = AssertSpecial
trigger1 = 1
flag = NoAutoTurn

[State 100, 4]
type = ChangeState
trigger1 = command != "holdfwd"
trigger1 = Time >= 10
value = 555 

[State 100, 5]
type = ChangeState
trigger1 = command != "holdfwd"
trigger1 = Time < 10
value = 0 

[Statedef 555]
type = S
anim = 214

[State 500, 1]
type = VelSet
trigger1 = 1
x = 0

[State 500, 2]
type = ChangeState
trigger1 = AnimTime = 0
value = 0
ctrl = 1

Cmq se il mio personaggio dovesse subire una trasformazione e continuare a lottare da trasformato dovrei utilizare le variabili giusto?
Ad esempio la camminata da normale e la camminata da trasformato avrebbero animazioni diverse ma sarebbero eseguite sullo stesso command.

Le variabili come funzionano precisamente nel mugen?

[Nobun]

Ice King, su Sep 4 2005, 11:30, detto:

Scusate, io x nn saper ne leggere ne scrivere ho fatto in modo tale ke, quando lascio il pulsante x la corsa cambia automaticamente stato e va in frenata... nn è meglio?

Infatti questa era la mia soluzione. Nel socondo topic di risposta a Slayer correggevo un errore all'interno del proprio codice utililizzando quel metodo. In tal modo ho lasciato scegliere a Ninja quel metodo adottare lasciando anche aperta la via indicata da Slayer (anche secondo me più complessa, ma è una questione di stile.... gonuno ha il suo :lol: ).

ninja, su Sep 4 2005, 14:39, detto:

Grazie Nobun della risposta, la tua soluzione è perfetta

Inoltre ho messo un tempo di corsa che se inferiore a 10 ticks non esegue l'animazione della frenata ma ritorna allo stato "0"

Ottimo B)

ninja, su Sep 4 2005, 14:39, detto:

Cmq se il mio personaggio dovesse subire una trasformazione e continuare a lottare da trasformato dovrei utilizare le variabili giusto?
Ad esempio la camminata da normale e la camminata da trasformato avrebbero animazioni diverse ma sarebbero eseguite sullo stesso command.

Le variabili come funzionano precisamente nel mugen?
<{POST_SNAPBACK}>

Sì sono necessarie le variabili (almeno questa mi sembra la via migliore).

Tra l'altro ho in mente di dirigere una sorta di progetto aperto a chiunque voglia partecipare per la realizzazione di un char che richiederebbe un lavoro immenso (non è quello a cui sto attualmente lavorando) capace di compiere trasformazioni (ho già detto troppo :P ).

Come funzionano le variabili? Semplicissimo. Una variabile è un posto in cui registrare dei valori che vengono cambiati secondo l'utilizzo che si preferisce.

Esistono 2 tipi di variabili nel Mugen (in realtà sarebbero 3 considerando le SysVar, ma esse vengono usate solo dentro il common1.cns): le variabili tipo intero (ad 0 a 59) in cui puoi memorizzare solo numeri interi (positivi o negativi che siano) e le variabili tipo "floating" o "a virgola mobile" (da 0 a 39, mi sembra ma non sono sicuro) in cui memorizzi valori decimali (tipo 2.354231).

ogni var viene utilizzata in questo modo all'interno dei trigger.

triggerX = var(x) = y .

x indica quale variabile si sta utilizzando (quella indicata con indice numero..... da 0 a 59 per le intere)
y è il valore

(ovviamente puoi usare non solo il segno di uguaglianza, ma anche tutte le varie espressioni possibile - cfr tutorial exp).

Per settare una variabile

type = VarSet ;per settare il valore esatto
type = VarAdd ;per aggiungere (o sottrarre utilizzando un numero negativo) al valore già memorizzato
type = VarMul ;per moltiplicare (o dividere) per il valore già memorizzato
type = VarRandom ;per assegnare un valore casuale

poi i parametri (uguali per tutte le istanze)

v = indice della variabile ;scegli quale variabile utilizzare
value = indice il valore da impostare (moltiplicare o aggiungere a seconda di quale comando si sta usando)
e poi non dimenticarti i trigger ^_^

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

Per le variabili tipo float va aggiunto un "f"

triggerX = fvar(x) = y

type = FVarSet
type = FVarAdd
type = FVarMul

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

La scelta di come usare le variabili è totalmente libera. Non vi sono variabili riservate per i controlli di routine (a parte le sysvar che non si usano).

Quindi ti puoi sbizzarrire.

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

Esempio di uso delle var.

Nel mio nobunaga la var(10) gestisce il comportamento della spada infuocata.

Var(10) = 0 ;spada in tasca
Var(10) = 1 ;spada impugnata in mano
Var(10) = 2 ;spada in lancio (mossa sword-launch)
Var(10) = 3 ;spada che sta colpendo l'avversario (mossa sword-launch)
Var(10) = 4 ;spada a terra pietrificata (avevi fallito lo sword launch. Non puoi recuperarla da terra finchè non torna attiva)
Var(10) = 5; spada a terra attiva

Se dai un'occhiata alla programmazione vedrai che tale var è praticamente onnipresente

[SlayerGatsu]

Quote

Cmq se il mio personaggio dovesse subire una trasformazione e continuare a lottare da trasformato dovrei utilizare le variabili giusto?
Ad esempio la camminata da normale e la camminata da trasformato avrebbero animazioni diverse ma sarebbero eseguite sullo stesso command.

se aspetti un po' potrai scaricare Gill e prendere e editare il suo common.

dovrai sostiruire le variabili con il parametro dei trigger che si chiama Facing = 1 o -1

Ti conviene per 2 motivi:

usi delle animazione "standard" che ho definito per gill
non hai problemi con quando vieni colpito B)