[puffolotti]

I personaggi del mio progetto corrente hanno la caratteristica di non avere una vera e propria definizione di super mosse ed hyper mosse.
Cioé, hanno delle super e delle hyper mosse, ma anche mosse normali che "migliorano" progressivamente man mano che il personaggio si "infuria"

immaginiamo ad esempio che la testata di honda divenga piú veloce e dannosa in accordo al suo livello di "furore"

diciamo che la velocitá deve essere 4 quando é "tranquillo" e 8 quando é fuori dalla grazia del buddha. Costruire la funzione su VelSet non é difficile, 4 + power/750, 0

Avendo una funzione che restituisce l´intero di un numero razionale (in ogni caso mugen tronca i numeri con troppi decimali senza problemi) si potrebbe semplificare questo processo dove sono richiesti i numeri interi, perché ho appurato che a dare un numero razionale non intero in questi casi, manda il motore di mugen a pesca di bufale.

Diciamo che quando un personaggio si infuria puó concatenare meglio le mosse, e l´ultima celluloide di una animazione persiste per 4 scatti, in una mossa che ne dura 20.

Allora sul blocco che restituisce il controllo alla fine della mossa potremo scrivere time = - power/1000 + 20 in questo modo quando il personaggio sará furente riavrá il controllo immediatamente dopo l´esplosione della mossa.

Preciso che ne "l´eclisse dei sentimenti" la barra power (chiamata "furore" nella manualistica allegata) avrá un funzionamento piuttosto dinamico, visto che molte mosse ne consumano automaticamente una frazione per migliorare in efficacia, alcune mosse normali in effetti diventano per velocitá e danno delle vere e proprie super, quando il furore raggiunge un certo livello.

la caratteristica su cui vorrei agire, in particolare, é la prioritá della scatola di collisione d´attacco.

Correntemente, per fare un esempio pratico, le spallate di narak, praticamente inutili quando é tranquillo, diventano micidiali da 4 metri di distanza quando il furore é a 3000, e questo progressivamente, trovo che sarebbe elegante dare alla spallata destra (diagonale) prioritá in questione il valore fluttuante 4+ int((power/1000))

Dove per "int" intendo dire che se power/1000 restituisce, che so, 2,21 allora int((power/1000))=2

In questo modo la spallata passerebbe dalla prioritá 4 fino a quando la barra del furore é sotto 1000, poi passa a 5 fino a ché il furore non é a 2000, e cosí via.

Andrebbe anche bene una funzione di approssimazione, basta aggiungere un fattore per portare il range da 0 a 3454

Qualcuno ha qualche idea?

[Nobun]

Uhm allora...
Ci sono alcune cose che si possono fare in modo puramente matematico, altre no.
Mi spiego meglio.
Interagire sulla velocità (intesa però come velocità di SPOSTAMENTO non di MOVIMENTO). Ovvero posso interagire con il cns in modo che l'avanzata della camminata e della corsa siano più o meno lente.
Ma con le animazioni questo principio non funziona. In poche parole, se io voglio fare una animazione di una mossa che sia più rapida di un'altra (ci impiega tot a tirare un pugno anziché un altro valore di tempo) devo velocizzare l'animazione. Per velocizzare l'animazione, l'unica è interagire nell'animazione AIR.
Ora, a me non risulta sia possibile mettere formule matematiche nella definizione delle tempistiche di durata di un frame nell'air.
Se è come penso l'unica è fare delle animazioni diverse per i diversi utilizzi tipo

[Begin Action 200] ;Pugno tempo normale
200,1, 0,0, 5
200,2, 0,0, 5
200,3, 0,0, 5

[Begin Action 201] ;Pugno velocizzato (velocità 1)
200,1, 0,0, 4
200,2, 0,0, 4
200,3, 0,0, 4

[Begin Action 202] ;Pugno velocizzato (velocità 2)
200,1, 0,0, 3
200,2, 0,0, 3
200,3, 0,0, 3

Ora, il mio esempio (per varie ragioni) fa abbastanza pena, ma serve ad illustrarti ciò che sto cercando di spiegarti.
Se io mi limitassi SOLO ad anticipare il momento del rilascio della mossa, il rischio è quello di arretrare troppo la soglia di fine, fino ad anticipare lo stesso hitdef (in poche parole la mossa finisce prima di colpire) oppure il rischio è di produrre un risultato innaturale.
Il tuo approccio, però, può essere utilizzato se si ha l'accortezza di pensare a "tempi di attesa" sufficientemente lunghi (nella velocità iniziale) per essere accorciati senza troppi intoppi.
Questo è il punto di partenza.

Io ti suggerirei di dividere la programmazione della tua idea (MOOOLTO interessante) in tre diverse logiche

1) Interazione "velocità" (intesa come velocità di spostamento, altezza del salto, ecc) che si fa a livello di cns
QUi vanno modificati gli state comuni del common1.cns andando ad interagire con le velocità come da te immaginato. Non saprei dirti, così su due piedi, la formula matematica migliore. Ma ora come ora secondo me è più importante avere chiari i passaggi su cui si deve lavorare.

2) Se vuoi fare diverse modifiche di "rapidità dei movimenti" (diverse animazioni) NEGLI STATE / ANIMAZIONI comuni (es. standing, camminata etc). Devi modificare il codice degli state comuni SENZA AGGIUNGERE nuovi state, ma prevedendo invece diversi ChangeAnim a seconda della animazione desiderata (vedi poi suggerimenti su animazioni)

3) Sempre sulla "rapidità dei movimenti", ma con riguardo alle mosse normali (es. colpi normali, specials, supers, etc) si può sia agire utilizzando delle istruzioni ChangeAnim oppure anche, se preferisci, separare le diverse casistiche (con diverse velocità di movimento) in state diversi. Qui forse può essere consigliabile separare gli state, ma dipende anche dal tuo stile personale di programmazione. DI SICURO (e non è un caso che ho separato punto 2 e 3, pur trattandosi della stessa cosa ma applicata in situazioni diverse) NEGLI STATE DI BASE (illustrati nel punto 2) non è un caso non si menzioni di questa seconda chance. Questo perché è sconsigliato, nei casi degli state di base, creare state aggiuntivi (anche perché alcune cose vengono gestite direttamente nel mugen) a meno di non avere idee estremamente chiare (che neppure io penso di avere al 100%)

Suggerimento sulle animazioni. Per non complicarti troppo le cose ti suggerisco di non fare più di 3 animazioni per mossa (1 normale, 1 velocità intermedia, 1 velocità massima)

[Squall LionHeart™]

Io non so se ho capito bene XD sono di ritorno da una giornata di uni, però se ho capito in breve, tu vuoi fare un'animazione più veloce a seconda dei casi.

La soluzione di Nobun è l'unica che io conosca per quanto riguarda questo effetto. Una variazione potrebbe essere (in effetti è la stessa cosa, però ribalti l'effetto) rallentare l'avversario.
tu ti muoveresti sempre alla stessa velocità, ma l'avversario sarebbe più lento.

Puoi farlo con un "targetvelset" ;)

Saluti

Squall

[puffolotti]

Devo essermi spiegato male.

So esattamente che non posso agire sull´AIR in questo senso, e ne conosco i motivi.

Io parlavo di

Velset/veladd sulla convocazione per le traslazioni
Damage
poweradd

il momento in cui mugen esegue un´operazione é quello in cui legge il secondo membro, fino a quel momento il secondo membro puó chiamare sé stesso,

Ad esempio, vediamo le linee in questione nell´hitdef della spallata di Ivan Narak, che funzionano benone.

[StateDef 206]
velset = 5 * power/3000 + 5, -2
Poweradd = -0.5 * power


[state 200, 1]
type = hitdef
priority = 4
Damage = 60 * power/500 + 60, 5 * power/1000 + 5

Quando Narak é tranquillo la spallata viaggia a 22 km/h, (lavoro in alta risoluzione) e ce ne vogliono 17 per stendere un avversario con 1000 di life.
Puó tirarla in ogni momento, ma il suo livello di furore viene dimezzato.
Quando il furore é al massimo (e narak é fuori dalla grazia del Buddha) narak arriva sull´avversario a 44km/h e ce ne vogliono 4 per stendere un avversario con 1000 di life.

Immaginiamo di aver fatto infuriare narak al massimo, cosa non agevolissima perché nel sistema di gioco il furore fluttua (tipo, se uno si piglia una girata di collo si incazza, ma se uno viene stordito con una ginocchiata al fegato si calma)

tira la prima spallata con furore a 3000, e connette

avrá viaggiato a 44 km/h e procurerá un danno di 360.

ora, immaginiamo di tirare una seconda spallata dello stesso tipo, adesso il furore é a 1500

la velocitá sará quindi 5 * 1500/3000 + 5 = 7,5, pari a 32,4 km/h e il danno cagionato

sará 60 * 1500/500 + 60 = 240

------ E fin qui parlo di storia antica: narak funziona in questo modo, e non c´é motivo di dubitare che gli altri personaggi facciano altrettanto -------

Ora, prendiamo il ctrlset con l´ esempio di Nobun.

[Begin Action 200] ;mossa.
200,1, 0,0, 5
200,2, 0,0, 5
200,3, 0,0, 5

Diciamo che stiamo parlando di una capriola

e finisce con

[State 200, 6]
type = CtrlSet
trigger1 = Time = 14
value = 1

[State 200, 7]
type = ChangeState
trigger1 = AnimTime = 0
value = 0
ctrl = 1

----

Ora, se voglio un alpha cancel sullo stato 830 non lo metteró qui ma nel command.

Intanto l´ong bak é una presa in volo in cui si afferra il mento dell´avversario in corsa e la si fa girare di scatto.

Quindi il comando manderá allo stato 829 che é il tuffo.

[State -1, ong bak]
type = ChangeState
value = 829
buffer.time = 5
triggerall = command = "QCF_z"
;triggerall = statetype = S ; al momento l´ong bak in aria segue la traiettoria del salto.
triggerall = power > 999
trigger1 = ctrl
trigger2 = stateno = 399 ; inversione
trigger3 = stateno = 397 ; altra inversione

; ora aggiungo l´esempio di Nobun

trigger4 = stateno = 200
trigger4 = time > 13 ; al momento arbitrario.

L´ong bak puó cosí partire in anticipo sulle altre mosse di un tick. sulle inversioni non ha senso, appena il piede sinistro tocca terra o appena il piede destro non tocca terra, puó partire... ma sullo stato 200...

Allora, intanto esaminiamo l´obbiezione di Nobun.

Quote

Se io mi limitassi SOLO ad anticipare il momento del rilascio della mossa, il rischio è quello di arretrare troppo la soglia di fine, fino ad anticipare lo stesso hitdef (in poche parole la mossa finisce prima di colpire) oppure il rischio è di produrre un risultato innaturale.

é una questione di algebra elementare...

range minimo e range massimo chiamiamoli m1 e m2

allora, il denominatore della potenza lo trovo dalla dispersione, che é D = m2-m1 ma ancora piú semplicemente "la persistenza dell´ultimo frame". o "la persistenza dell´ultimo frame" - "rigenerazione dell´immagine"

Allora, siccome avevo intenzione di lasciare una persistenza minima sul frame del cancel, il primo e l´ultimo metodo mi danno 3 di dispersione su un range 12 - 15

Il denominatore é ovviamente m2(Power)/D(cancel)

Da qui la questione é elementare.
-------------------------------

Ora, se volessi usare il metodo per valori interi, per valori di [attuale(power)] che non sono multipli di [D(cancel)] ottengo degli addendi razionali non naturali, sicuramente positivi

Quindi se metto

[State 200, 6]
type = CtrlSet
trigger1 = Time = 12 + power/1000
value = 1

Mugen funzionerá solo per 1 valore ogni 750 , le altre volte, trovando che so... 13,7382819

ragionerá circa in questo modo:


type = hitdef
Allora, (223 -253) / (223 - 253) +1 = 0 ... dai, dai che questa volta c´é...
...
poi, (54 -76) / (54 - 76) +1 = 0 evvai, che gancio!!!!

e adesso facciamolo sanguinare, il pagliaccio!!!

Bene, passiamo al prossimo.

type = CtrlSet
Dunque, setta il controllo se....
time = "mai in questo caso"
o.k., passiamo oltre.

Ecco, quello che servirebbe sarebbe assicurarsi che riceva sempre un numero intero laddove non processa i numeri razionali non interi.

In Vba esiste la funzione Int.

int(3,2634) = 3
int(3,9798) = 3

e la funzione round

round(3,2634) = 3
round(3,9798) = 4

entrambe mi andrebbero bene, nel caso della funzione round basta aggiungere 3000/(2(D)±1) a attuale(power) dove per "±" intendo dire che dopo le 17:00 non é compassionevole chiedermi se ci va il "-" o il "+" ma uno dei due va sempre bene e l´altro dei due va sempre male, ma credo il meno, in base alla teoria degli errori.

Ammesso e non concesso che tali stringhe ammettano funzioni e/o variabili, intendo naturalmente dire.

Lo verifico subito.

[State 200, 7]
type = ChangeState
trigger1 = AnimTime = 0
value = 5 * 100 /2
ctrl = 1

Perfetto, dopo il jab parte INEVITABILMENTE il calcio negli stinchi.

Diamogli ora un numero che sicuramente non rappresenta nessuna azione.

[State 200, 7]
type = ChangeState
trigger1 = AnimTime = 0
value = 5 * 100 /3
ctrl = 1

Risultato = continua a ripetere l´animazione del jab finché non si tocca un comando (mappato) qualunque, il value in questo caso funziona come un trigger.

Ora, facciamogli fare un ciclo e un tocchettino...

[State 200, 7]
type = ChangeState
trigger1 = Time = 3
value = 0
ctrl = 1

perfetto

[State 200, 7]
type = ChangeState
trigger1 = Time = 1,5 * 2
value = 0
ctrl = 1

NISBA!
Quindi non posso costruire la funzione "round()".

Passando a cose serie...

Quote

Nel CNS

10 [State 200, 7]

20 type = ChangeState

30 triggerall = USATO DAL COMPUTER (se é controllato da un umano restituisce 0, se controllato dal computer !0)

40 trigger1 = AnimTime = 0

50 trigger1 = p2state = sta contando i denti che gli sono rimasti in mano. (lo so perché stava nell´hitdef alla voce "hittime",
50 le condizioni sono: stato compreso fra 5000 e 5999, hittime - persistenza (animelem))

60 trigger1 = [random (Costante locale arbitraria cogente) ] < [quanto mi piace tirare l´anfibiata nel fegato] * [livello di difficoltá corrente]

70 trigger1 = dove ho mandato lo zoticone? = é a portata di anfibiata e alla sua velocitá corrente lo sará per tempo sufficiente a tirargliela, in base alle stesse immissioni alla stringa "50".

80 value = giá che ci sei tiragli un´anfibiata nel fegato [stato 256]

ctrl = 0

stato 256

adesso ci starebbe bene una gomitata in caduta sul naso... ma non é che si ripiglia troppo presto?

Carino, no?
Ad una decina di aperture si mette 3 opzioni

Punto 30 ha piú senso se gli si puó impedire di andare a leggere i comandi dedicati ai miserabili umani, ma comunque per quando ci arriva si é sicuramente inventato qualcosa...

Punto 60 il livello di difficoltá influisce direttamente sulla probabile lunghezza delle combo.

Diciamo che a Narak decido gli piace dopo il crasher tirare una ginocchiata, un po´meno la gomitata a rasoio, ma potrebbe voler risparmiare il furore per un doppio sunrise kick

allora, ammesso che tutti gli altri criteri siano soddisfatti

la ginocchiata mi piace 8 il livello di difficoltá é 6, quindi tiro un numero a caso fra 1 e 100, una volta su due se la becca.

Se non glie la tiro,

la gomitata a rasoio mi piace 6, il livello di difficoltá é 6, quindi il tipo che non si é beccato la ginocchiata, si becca la gomitata a rasoio 1 volta su 3, il ché significa che a livello 6 5 volte su sei dopo il crasher becca un colpo di prossimitá.

ecc. ecc.

3 controlli di questo tipo su ognuna delle aperture si fanno praticamente da soli.

heý

[Nobun]

Scusami... purtroppo le mie capacità intellettive sono limitate e questo tuo ultimo discorso mi è totalmente oscuro. Non sto riuscendo a capire quello che stai dicendo, e ti chiedo scusa per i miei limiti.
Io posso solo dirti due cose

1) Io non ti stavo obiettando. Dicevo solo che, se fai un attacco (es. un pugno) e velocizzi solo il tempo di uscita dello state, rischi che il time di durata sia inferiore a quello necessario per raggiungere l'hitdef.

2) il discorso velocità (che è diverso da RAPIDITà di movimenti) è puramente matematico, come hai detto tu. Poiché il Mugen fa riferimento comunque alle logiche del linguaggio C è ovvio che una espressione può essere in un certo senso "ricorsiva" per cui una espressione tipo

[State X, Y]
type = VarSet
v = 1
value = var(1) + 1
trigger1 = time = 0

E' assolutamente valida (quindi la var 1 incrementerebbe di 1 il valore). Ovviamente la stessa logica può essere usata ovunque (quindi anche per power etc)

3) Espressioni non intere...
Bhe le velocità (stiamo parlando di velocità ora, quindi Velset etc) sono valori di tipo float (con virgole) e non di tipo int (interi). In ogni caso in informatica l'approssimazione è sempre per difetto.

Altro non saprei dirti perché, come ti ho detto, non sono riuscito a capire cosa stavi dicendo. Purtroppo ho i miei limiti e ragionamenti troppo complessi faccio fatica a capirli

[puffolotti]

: bé, ho messo tutto il front end del processo di ricerca, comunque il concetto é che ho risolto il problema verificandone l´irresolubilitá... (nella stringa in questione ci va un numero intero, qualsiasi cosa diversa manda al default, che é quattro.)

Per informazione di (eventuale) pubblica utilitá: il computer, esattamente come hai detto arrotonda per difetto, toglie i decimali che "sporgono". In corso d´opera non ci ho mai pensato in quanto parliamo se non sbaglio di numeri dell´ordine di 1E-7 (1-10 millimetri su 1000 km.)
Le funzioni per altri tipi di arrotondamento in generale sono del tipo: dividi [X] per [R] prendi la parte intera del risultato e torna a moltiplicare per [R]
La funzione Round si basa sulla lettura da destra a sinistra del numero cifra per cifra, a meno di non stabilire un numero di cifre significatiive arbitrario, (Il computer non puó neanche emulare altro che la matematica discreta) in tal caso si da un termine di paragone.

La funzione round dovrebbe somigliare a:

Round(N) //con 3 cifre significative

Se N - int(N) >= 0,445 allora
Round(N) = int(N) + 1
Altrimenti
round(N) = int(N)

Comunque in MUGEN, a quanto pare la funzione Int(N) non puó essere applicata alle stringhe che richiedono numeri naturali. (integer)

Uhm, penso ancora di essermi spiegato male.
...Corro a mettere in ordine il file CMD di Narak... Se lo vedi cosí come é ora... mi sa che vieni a RGB a porre fine all´abominio.

A proposito, pensi che possa essere utile a qualcuno il mio metodo di pulizia del file CMD?

[Nobun]

Non saprei dirti. Più che altro non ho capito in cosa consista questo metodo.
In ogni caso, ogni idea che può avere una utilità è sempre utile (scusa il gioco di parole :P) a meno che si sa già a monte che un metodo è poco pratico (ad es. il mio modo di creare SFF non è praticissimo, ma uso quel metodo semplicemente perché mi dà più garanzie, anche considerando che uso Mee che non va bene per creare buoni Sff).

Puffolotti, ora non ti sto sviolinando, ma dico semplicemente ciò che vedo. Tu sicuramente hai delle conoscenze ed una intelligenza che vanno molto al di fuori del comune. Come preparazione, da quello che dici, dimostri ad esempio di conoscere la matematica più avanzata. Inoltre arrivi a concepire dei concetti o ad avere delle intuizioni (che poi si possono scontrare con dei limiti del motore, ma l'intuizione in sè poteva comunque avere senso) che in pochi sarebbero in grado di avere. Credo, ma questa è una mia impressione, che tu sia superiore (almeno a livello potenziale) a tutti noi, o quanto meno - sicuramente - hai delle capacità e conoscenze superiori alle mie. Il che, a volte, mi rende difficile riuscire ad aiutarti con quelle poche cose in più che conosco dalla mia piccola esperienza e che magari possono contribuire a risolvere i tuoi dubbi.
Fatta questa premessa permettimi una breve osservazione (non vederla come una critica). Cerca di capire che i tuoi interlocutori non hanno le tue stesse conoscenze. Ad esempio, io vengo da un liceo classico e ho affrontato un percorso di studi che nulla a che fare né con la matematica né con l'informatica. Quello che so in più di informatica lo devo ad una passione decennale (almeno 15 anni in realtà) per la programmazione. Quindi, se ad esempio tu mi parli di cose che presuppongono determinate conoscenze che io non ho assolutamente (per farti un esempio stupido, mi illustri un ragionamento che presuppone sapere come funzionano gli integrali che io conosco solo di nome ma non so nemmeno cosa sono) succede che io non riesco a capirti assolutamente, per quanto mi sforzi.
Cerca di capire che, per quanto "esperto" in materia di Mugen (metto le virgolette perché sono anni che dico che le mie poche conoscenze sono sempre state sopravvalutate da tutti, anche se sono riconoscente della stima che ho raccolto in questo forum), non sono un pozzo di scienza ed ho bisogno di parlare semplice.
Quando illustri un problema, o una metodologia, dovresti sforzarti di parlare in maniera tale che chiunque - anche coloro che non dispongano delle tue conoscenze - possano capire tutti i passaggi del tuo ragionamento senza perdersi.
Prendi a modello una mia spiegazione, ad esempio il mio tutorial sugli stage. Ora, non dico che devi sentirti costretto ad essere così esageratamente puntuale nel banalizzare ogni minimo aspetto, però cerca - nel limite del possibile - di sciogliere i nodi ed i dubbi con una spiegazione il più possibile lineare e semplice.
In questo modo rendi anche più agevole a me capire, anche quando illustri un problema, di riuscire a capire esattamente in cosa consiste la domanda e se sono in grado di darti una risposta. Credo questo valga anche per gli altri, ma io posso parlare solo per me (e non mi vergogno ad ammettere i miei limiti).
Quando illustri una metodologia, la questione semplificazione è ancora più importante: gli utenti - generalmente - sono ancora meno esperti del sottoscritto. Un metodo, quindi, per poter essere compreso ed eventualmente seguito da altre persone, deve essere spiegato in modo che anche l'utente meno esperto possa capirlo e valutare se seguirlo o meno.

[puffolotti]

Ti ringrazio molto dei complimenti, che non sono certo di meritare (attimo di malcelata immodesti :S)

e ti ringrazio ancora di piú per l´osservazione.
In futuro mi impegneró per adeguarmi all´osservazione che hai fatto.
Vedo il concetto di M.U.G.E.N come condivisione di metodi e di ritrovati.

Penseró al modo di far convivere teoria di base con nozioni pratiche applicate in modo chiaro ed immediato, mi sembra il modo piú semplice di dimostrare che merito almeno parte dei complimenti.