[PaToS]

Ciao a tutti!

Sto iniziando (e imparando) a programmare un char e mi trovo davanti ad un problema:
voglio fare in modo che quando salta in corsa abbia velocità diverse
rispetto a quando salta normalmente, però questo solo quando salta nella stessa direzione della corsa. Altrimenti, se salta nella direzione opposta, voglio che abbia le normali velocità.
Lo state in cui si settano le velocità è il 40 nel common, quello della

preparazione al salto (jump start).

Ho creato lo state 40 nel CNS del personaggio.
Per il salto normale funziona tutto normalmente.
Il problema sta nel fare quello che ho scritto sopra.
I miei tentativi sono stati:

[State 40, 30]
type = VelSet ; questa parte uguale per tutti i tentativi

1°:
triggerall = AnimTime = 0 && prevstateno = 100
trigger1 = Vel X > 0 && command = "holdfwd"
trigger2 = Vel X < 0 && command = "holdback"
x = ifelse (Vel X > 0, const(velocity.runjump.fwd.x), const(velocity.runjump.back.x))
y = const(velocity.airjump.y)

2°
Ho provato con le variabili al posto del command (assegnando prima i valori ovviamente)
var(50) = 1 se il comando è holdfwd
var(50) = -1 se il comando è holdback

3°
ho provato a usare il command (o le variabili) nell' ifelse al posto della Vel X

4°
trigger1 = AnimTime = 0 && prevstateno = 100
trigger1 = ifelse (Vel X > 0, ifelse (command = "holdfwd", 1, 0), ifelse (command = "holdback", 1, 0))
x = ifelse (Vel X > 0, const (velocity.runjump.fwd.x), const (velocity.runjump.back.x))
y = const (velocity.airjump.y)

5°
ho provato a fare 2 state controller
[state 40]
type = VelSet
trigger1 = animtime = 0 && prevstateno = 100 ;(quello della corsa)
trigger1 = Vel X > 0 ; (oppure command = "holdfwd", o var(50) = 1)
x = const(velocity.runjump.fwd.x)
y = const(velocity.airjump.y)

[state 40]
type = VelSet
trigger1 = animtime = 0 && prevstateno = 100 ;(quello della corsa)
trigger1 = Vel X < 0 ; (oppure command = "holdback", o var(50) = -1)
x = const(velocity.runjump.back.x)
y = const(velocity.airjump.y)

Lo state della corsa è lo stesso e serve sia per quella indietro che per quella avanti.

Quello che succede in tutti questi casi è che mentre io voglio che lo state controller si attivi solo quando corro in avanti AND salto in avanti OR corro indietro AND salto indietro, questo si attiva se corro (in qualsiasi direzione) AND salto (in qualsiasi direzione, anche diversa da quella di prima).

Spero di essere stato abbastanza chiaro.
Mi scuso se la soluzione dovesse essere una cavolata, sto ancora imparando.

Un'altra cosa, se scrivo const(xxxx) con al posto delle x:
velocity.runjump.fwd.y
velocity.runjump.back.y
e non mi ricordo quali altre costanti quando seleziono il personaggio mi dice che queste costanti non sono valide.
è normale??

Okkkaaaayyy basta!
Vi ho già dato abbastanza lavoro (se avrete voglia di rispondermi)

Grazie a tutti!

PS: so che una soluzione semplice potrebbe essere quella di fare due state separati per la corsa avanti e quella indietro, ma non capisco perchè anche così non debba andare...

[Menjoso]

Dovrebbe essere abbastanza semplice.

Prendi il velset, e fanne 2 copie uguali. Il primo lo lasci com'è, e metti:

triggerall = (Prevstateno != 100) && Command != "holdfwd"

Nell'altro invece metti questi e lo imposti con le tue velocità + alte del normale:

triggerall = (Prevstateno = 100) && Command = "holdfwd"

Non ho letto tutto il tuo post, per cui mi scuso se ho detto qualche cavolata. In caso mi sa che mi toccherà leggerlo, e io odio leggere :mellow: XD

[Nobun]

Intanto ne approfitto per farti dei complimenti. Dai tuoi tentativi si denota una buona padronanza della programmazione Mugen generale.
Il tuo errore (comprensibilissimo) è quello di limitarti allo state 40, ma - quando c'è da mettere mano agli state common - il lavoro è molto più complesso e articolato.
Se l'effetto è solo la volontà di programmarti un salto più veloce in corsa, basta solo calibrare le costanti CNS e NON programmare lo state 40 (utilizzando quindi quello prestabilito).
Se però vuoi proprio mettere mano nella programmazione del salto non puoi prescindere da un'analisi degli state interessati nel common1.cns

Devi quindi andare a prenderti il codice degli state 40 e seguenti (non basta quello dello state 40) guardando il common1.cns (si trova, come tu saprai, nella cartella "data" del Mugen).
Come vedrai l'idea di base è simile a quella del tuo primo tentativo, ma è un po' più elaborata (vengono messe in gioco delle espressioni un po' più complesse e l'uso delle sysvar). In poche parole (come sempre si fa quando si mette mano ad uno state common) prima di tutto si deve copiare il codice originale nel proprio CHAR, per poi modificarlo partendo dalla versione originaria (riadattandola alle proprie necessità).

[PaToS]

Io sono partito proprio dal common per fare lo state, e cmq riesco a fargli fare il salto usando le costanti della corsa mentre corre e quelle normali se non è in corsa. Ho provato anche usando una variabile normale allo stesso modo della sysvar nel common, ma niente, ho sempre lo stesso problema. Immagino che se usassi due state diversi per la corsa in avanti e indietro sarebbe più semplice perchè potrei fare due state controller uno con trigger prevstateno = 100 e l'altro prevstateno = 105.
Ma con una delle scritture che ho usato, per esempio la prima, non dovrebbe attivarmi il velset solo se:
1 - è finita l'animazione dello state corrente (di preparazione al salto)
2 - vengo dallo state 100 (della corsa)
3 - o la velocità è maggiore di 0 (mi muovo in avanti) e premo avanti
o la velocità è minore di 0 (mi muovo indietro) e premo indietro
Invece quello che accade è che mi usa la velocità che voglio solo in questi casi anche se per esempio la velocità è maggiore di 0 (corro in avanti) e premo indietro...

Chiedo scusa a menjoso per la mia lunghezza nello scrivere, anche io odio tremendamente leggere, ma è per cercare di essere il più preciso possibile.
Imparerò a essere sempre più corto!

Grazie per i complimenti nobun!!

[Nobun]

E' per me comunque una cosa interessante (mi piacciono le sfide :P)
Purtroppo fino a giovedì-venerdì non posso fare prove, poi vedo cosa riesco a combinare su Nobunaga (che non ha né la corsa né l'Hop né il salto in corsa, ed è quindi il char più "neutro" su cui posso fare esperimenti). Per ora posso andare solo ad ipotesi teoriche... per ora non vedo degli errori nel ragionamento, al massimo vedo solo una necessità di integrare anche gli state successivi del salto e non solo il 40... ma non potendo fare test diretti posso dirti ben poco, anche perché in alcune situazioni riguardanti gli state common ci sono anche degli eventi "esterni" alla programmazione stretta che vengono gestiti autonomamente dall'Engine (ad esempio, per la gestione della morte, se lo state finale non è il 5150, a prescindere da ciò che scrivi dentro, il char rimane bloccato e l'annuncio di fine round tarda ad arrivare)

EDIT: ANTICIPAZIONE DI CORREZIONE. Rileggendo la tua ultimissima risposta ho FORSE intravisto un possibile errore (ho degli elementi in più per capire ciò che succede). Non posso darti maggiori dettagli perché devo rileggere tutto con calma e ragionarci un po' su (mi si è "accesa una lampadina" ma non ho ancora focalizzato del tutto il punto. ti farò sapere al prossimo edit / prossima risposta... credo in serata quando potrò rileggere a mente fresca il tutto - ora devo andare via).

[PaToS]

Ok grazie Nobun!

Anche perchè questo problema coi trigger me lo da anche in un altro caso.
Sembra che se metto più di un trigger1, non vuole per forza che siano tutti soddisfatti. Tipo gli ho messo uno state che diminuisce la velocità in corsa solo ogni volta che si trova nel frame 2 (che ha time -1) e la velocità è diversa da zero.
Poi gli ho detto che quando la velocità è 0 deve cambiare state.
Quello che succede è che:
-nei primi tentativi il personaggio rallentava, si fermava e poi si spostava sempre più velocemente indietro perchè la velocità diventava negativa.
-negli ultimi tentativi il personaggio si ferma ma non cambia state.
Cmq se stasera ancora non avrò risolto ti spiegherò meglio.

Per il salto in corsa ho risolto facendo 2 state separati per la corsa in avanti e quella indietro. Ora fa ciò che volevo. Stasera spiegherò meglio l'altro problema sorto facendo i due state separati. Appena riuscirò a far funzionare il tutto correttamente lo posterò per chiunque possa essere interessato.
A stasera

[Nobun]

Bhe se hai risolto il primo problema tanto meglio :D
Avrei potuto iniziare ad analizzare il codice solo ora... 0:)

Comunque ti rassicuro su una cosa... per realizzare una condizione trigger devono essere rispettati TUTTi i trigger con lo stesso indice (più ovviamente i triggerall che devono essere sempre validi) e non è mai stato riscontrato alcun malfunzionamento su questa caratteristica dei trigger... qui probabilmente l'errore sta nel non aver ben calibrato le casistiche e - probabilmente - l'evento viene valutato come vero in due o più tick di tempo perché gli eventi non sono stati tutti ben calibrati.

Se il problema è questo posso intanto consigliarti di aggiungere il parametro persistent = 0 che fa in modo che l'effetto si verifichi UNA e UNA SOLA volta dopo l'inizio degli state (quindi, se tutte le condizioni trigger risultano vere, ma il comando è giàstato eseguito una volta dall'entrata nello state, il comando non viene più eseguito perché persistent = 0 impedirà ulteriori esecuzioni).

Nota: il parametro persistent NON ha effetto negli states negativi (-1, -2 e -3) (anche se ora non ti serve meglio saperlo). Maggiori dettagli sui parametri "persistent" ed "ignorehitpause" (due parametri valevoli per ogni istruzione CNS) li trovi nel tutorial "cns" della documentazione ufficiale Mugen.

[PaToS]

Sì quel problema l'ho risolto, alla fine ho fatto due state separati per la corsa avanti e per quella indietro. L'ultimo mio problema era quello di far frenare il mio personaggio. Anche questo l'ho risolto, ma non ho ancora ben capito come funziona lo state controller VelAdd (e non ho trovato quello che cerco sulla guida del mugen).
Tra un ora circa se sei ancora qui ti spiego bene, ora devo andare.
A dopo e grazie!!

Cambio di programma.
Allora il punto è questo, la mia velocità di corsa è 5.
se nello state della corsa scrivo

[state 100]
type = VelAdd
trigger1 = animelem = 2, >=0 && Vel X != 0
x = -.1

questo dovrebbe abbassare la velocità di .1 ogni tick fino a 0, poi non dovrebbe attivarsi e ho un altro state che quando la vel è 0 passa allo state 0.
Se il valore che scrivo è -.1, il personaggio corre, rallenta e po si muove indietro.
Se scrivo -5 invece appena arriva all'animelem 2 si ferma, se scrivo -.5 si ferma dopo 10 tick che è nell'animelem 2, se -.25 dopo 20.
Perchè col -.1 non funziona come dovrebbe?? In teoria dovrebbe fermarsi e cambiare state dopo 50 tick, non muoversi indietro.
Alla fine la cosa che mi interessa è una, voglio soltanto essere sicuro che con VelAdd non faccio altro che una somma algebrica, anche se per -.1 non mi ha funzionato.
Potete darmi questa certezza?? Io cmq il problema l'ho risolto in un altro modo.
Se dovessi avere altri problemi non mancherò di scrivere!!
Grazie!
Ciaoo!

[Nobun]

Innanzi tutto mi scuso in anticipo sia con te che con tutte le persone che (come il povero Menjo :P) non avranno molta voglia di leggere tutto e si annoieranno fin dalle prime righe di questo mio prolisso intervento.
Un po' perché è per me stimolante parlare ogni tanto di programmazione Mugen un attimino avanzata (credo sia una delle rare volte che mi capitano occasioni come queste), un po' perché secondo me la questione richiede una risposta quanto più completa possibile, non ho potuto liquidare il discorso in poche righe.
Aggiungo anche che sono ben consapevole che la maggior parte delle cose che dirò saranno quasi sicuramente di tua conoscenza (mi sembri un programmatore in gamba che non lascia nulla al caso), solo che non potevo prescindere dalle stesse per avere una spiegazione completa e comprensibile anche ad altri utenti (ovviamente quello che dirò potrebbe essere complicato per un niubbo). ora passiamo alla risposta...

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

Ti avevo già scritto questa mattina, ma mi era saltata la connessione ed avevo perso tutta la pappardella di roba che avevo scritto (spero di ricordarmi tutto). Per evitare lo stesso problema ora ho scritto su un file di testo, che poi ho postato qui con la funzione taglia-incolla.
(spero di ricordarmi tutto ciò che ti avevo detto)

I vari "step" che mostro non sono vere e proprie "fasi di intervento" quanto piuttosto diversi fattori di cui tenere conto.

STEP 1: Alcune indicazioni iniziali

Per prima cosa è (a mio modesto avviso) sconsigliabile mettere la frenata nello state 100, proprio perché la frenata è successiva al rilascio del "forward". Non che non si possa fare, ma secondo me è meglio fare uno state a parte (ma qui sono un po' condizionato dal mio stile di programmazione... io tendenzialmente tendo a separare in più state in caso di cambio di dinamica, per aver un maggior controllo di ogni fase)

Andiamo poi al tuo codice. In primo luogo c'è un piccolo errore (comprensibile) riguardante l'espressione trigger. In particolare il codice non tiene conto del fatto (che, a dire il vero non è scritto chiaramente nella documentazione, ma si scopre solo sperimentalmente) che il trigger "animelem" va poco d'accordo con le espressioni. Il primo consiglio è quindi di separare le due espressioni in due trigger1 (il tuo codice concettualmente non sarebbe sbagliato, però bisogna tener conto di quanto ti ho appena detto)
Discorso simile (esco un attimo dal discorso) vale anche per il trigger "command" che richiede di essere "isolato", proprio perché altrimenti possono verificarsi anche eventi imprevisti.
Es. un codice del genere

trigger1 = command = "uno" && command != "holddown" && time = 0

può creare anomalie anche qualora corretto (verificato di persona mentre programmavo KingLion... a volte le anomalie erano parecchio gravi) Per questo è quindi consigliabile separare le espressioni, isolando ogni singolo command

trigger1 = command = "uno"
trigger1 = command != "holddown"
trigger1 = time = 0

Ricapitolando: i trigger "command" ed "animelem" è sempre consigliabile tenerli separati ed isolati (uno per uno).

Nota per gli altri lettori: il tuo codice "frenante", dati i triggers inseriti, è attivo solo qualora stiamo nel secondo elemento della animazione di corsa e lungo tutto il suo tempo di durata, ragion per cui la frenata rimane "inattiva" durante l'esecuzione degli altri frame della corsa.

STEP 2: Delucidazioni su VelAdd

Prima di dire cavolate ho fatto alcuni rilievi in forma di test. Ti posso confermare che VelAdd opera una somma algebrica che opera solo nel tick (o NEI TICK) di tempo in cui è attivato (quando è disattivo rimane il valore Velocità così come modificato).
Ho però anche riscontrato che:
- Partendo da velocità 0 (velset = 0,0)
- Con Physics = N (nessuna alterazione di frizione dal Mugen)
- Utilizzando VelAdd (con x = 1)
ottenevo un valore di velocità con un eccesso di valore di 0,00082 (il che mi fa pensare che comunque ci sono forme di approssimazione non precise).

Per questi motivi io consiglio di sostituire il trigger

Vel X != 0

con

Vel X != [-0.1,0.1] ;eventualmente da calibrare

E poi aggiungere (subito dopo) una frenata definitiva finale con

[State 100, stop]
type = VelSet
x = 0
trigger1 = Vel X = [-0.1, 0.1]
trigger1 = Vel X != 0

Per completezza (lo dico soprattutto a beneficio di chi legge, non a te che sicuramente lo sai dato il tipo di codice che hai scritto) che quello che qui si propone va bene perché si sta avanzando. Ma in caso di "retromarcia" bisognerebbe usare valori positivi di X, anziché negativi.

STEP 3: La "Frizione di sistema"

...ovvero l'importanza del parametro Physics così come specificato nello statedef iniziale.

Il parametro Physics permette al Mugen di utilizzare una propria frizione a seconda delle seguenti eventualità:
S = Standing. In questo caso l'attrito è solo orizzontale ed attribuisce un potenziale frenante sul suolo (un valore di X abbastanza elevato, c'è per l'appunto il suolo che fa attrito).
A = Air. In questo caso l'attrito x è decisamente minore (in aria non hai la stessa decelerazione che in terra) ma c'è anche la forza di gravità, o meglio una forza y che ti porta verso il basso.
N = Neutro. Non c'è alcuna frizione prestabilita e quindi la velocità non ha variazioni se non quelle che tu programmi esplicitamente
(c'è anche il Physics = C, ma questo a noi interessa poco ora).

Se quindi io nello statedef 100 ho physics = S, la frenata è variata, oltre che dal tuo codice, anche dal moltiplicatore di velocità dettata dalla costante CNS di frizione tipo standing (quindi abbiamo una situazione alterata rispetto al tuo quadro mentale).
Ecco quindi che il comportamento non è più quello esattamente programmato (per cui si potrebbe consigliare un Physics = N).
Quindi la variazione di velocità, in caso di Physics = S non sarebbe più

Velocità X = Velocità X tick precedente - 0.1 (valore dettato da te con VelAdd ogni qual volta il trigger è valido)

ma invece

Velocità X = (Velocità X tick precedente * 0.85) - 0.1
(0,85 è il valore di frizione prestabilito in KFM, ovviamente il valore cambia se hai deciso una diversa costante di frizione)

STEP 4: Per un miglior "sistema frenante"

Usare VelMul anziché VelAdd.
La ragione è duplice:

1) In primo luogo perché l'effetto è più "vero" e la resa è decisamente migliore (anche nella realtà - la fisica lo insegna - gli attriti sono delle forme di moltiplicazione di velocità... es. la forza di gravità). Non a caso la unità di misura dell'accelerazione è m/s2 (dove s2 sta per s al quadrato).

2) In secondo luogo anche per semplicità dell'effetto stesso. Se applichi un moltiplicatore di velocità (con un valore maggiore di 0 ma minore di 1) ottieni una "frenata automatica" senza bisogno di dover controllare una eventuale "retromarcia". Applicando la frenata (basata sulla moltiplicazione di velocità) e lasciando la frenata attiva (lasciando i trigger validi lungo tutto il tempo di frenata) il char si FERMERà e NON tornerà MAI indietro in retromarcia. Con il moltiplicatore attivo, una volta che il personaggio è fermo, il risultato è quello di un char che continua a rimanere fermo senza più ulteriori modifiche alla velocità ormai divenuta nulla (qualunque numero, moltiplicato per 0, produce il risultato 0).

---------

Mi rendo conto di aver detto cose anche in eccesso (capirai quindi quanto mi è costato scrivere le stesse cose due volte), ma l'ho fatto sia per essere completo (anche per gli altri eventuali lettori) sia perché spero di aver individuato tutti i punti che potevano richiedere un chiarimento.
Spero che almeno parte di quello che ho scritto possa esserti utile alla soluzione dei tuoi problemi. Fammi sapere.

[PaToS]

Ciao Nobun!
La soluzione che ho adottato alla fine è simile a quella che mi dici tu, ovvero ho usato sempre il veladd, ma gli ho detto di agire solo per valori maggiori di 0 invece che diversi, e ho messo un changestate attivato quando la velocità è <= 0. E' più o meno quello che hai fatto tu con l'intervallo [-0.1,0.1], l'effetto in questo caso è più o meno lo stesso. Ho pensato anch'io che fosse un problema di approssimazione, ma non ne ero sicuro, e ora ne ho la conferma.
Non mi ricordo se ho scritto physics = S o N nel post, ma nella versione finale era N perchè lasciando .85 (per ora non voglio cambiarlo) frenava troppo velocemente.
Ascolterò il tuo consiglio del VelMul invece che VelAdd e proverò. Ho usato veladd perchè in teoria con velmul non arriverebbe a 0 la velocità, se non in modo approssimato (cosa che ora che ci penso dovrebbe funzionare benissimo).
Comunque non so se era chiaro ma la mia non voleva essere una corsa continua, ma volevo che quando schiacciavo "FF" faceva qualche metro e frenava, senza che io dovessi tener premuto o lasciare alcunchè.

Una domanda: le costanti in Movement funzionano tutte come come VelMul?

Bhè infine che dire, grazie per la smisurata attenzione!
Di sicuro se avrò altri problemi mi rivolgerò a questo forum (a te in particolare se la cosa ti diverte).

Notte!!

[Squall LionHeart™]

Dannazione mi sono accorto tardi di questo post XDXDXD come dice nobun è raro poter discutere di programmazione, mannaggia XD

cmq, davvero un applauso a Nobun, perché credo che anche un niubbo avrebbe capito quello che hai scritto XDXDXD

Saluti

Squall

[Nobun]

Quote

Ascolterò il tuo consiglio del VelMul invece che VelAdd e proverò. Ho usato veladd perchè in teoria con velmul non arriverebbe a 0 la velocità, se non in modo approssimato (cosa che ora che ci penso dovrebbe funzionare benissimo).

Discorso giustissimo se si guarda alla matematica "pura" (che IN TEORIA non ha limiti di approssimazione), non corretto se si guarda alla matematica "informatica" (che invece ha sempre un limite di approssimazione dettata dal numero di byte riservati ad ogni singola variabile).
In Informatica il risultato di una operazione di divisione (o, che è la stessa cosa, di una moltiplicazione per un numero maggiore di 0 e minore di uno - intese come valore assoluto, e quindi vale anche per i negativi) è sempre una approssimazione per difetto.
Ad esempio se io faccio x = 5/3 (dove x è una variabile di tipo intero, che non salva i valori dopo la virgola) io ottengo che x = 1
Stesso discorso vale per i numeri in virgola mobile (tipo float) che hanno sempre un limite di cifre dopo la virgola. Anche qui le cifre successive al limite di virgola vengono semplicemente troncate, ottenendo quindi sempre una approssimazione per difetto.
Per questo motivo, se continuo a moltiplicare persistentemente per un valore di 0.85, ad un certo punto otterrò il valore di 0 (frutto di varie approssimazioni per difetto) anche se IN TEORIA una continua divisione (pensando alle regole della matematica vera e propria) dovrebbe SOLO avvicinarmi in maniera infinita a 0 senza mai raggiungere tale valore. Questo discorso, fatto per 0.85, vale per qualunque valore tu possa specificare.

Quote

Comunque non so se era chiaro ma la mia non voleva essere una corsa continua, ma volevo che quando schiacciavo "FF" faceva qualche metro e frenava, senza che io dovessi tener premuto o lasciare alcunchè.

Onestamente questo non lo avevo capito... allora va bene programmare l'effetto anche nello stesso state della corsa.

Quote

Una domanda: le costanti in Movement funzionano tutte come come VelMul?

le costanti

yaccel
stand.friction
crouch.friction

Non sono sicuro della risposta, pensando soprattutto a yaccel e al comando Gravity: nella "caduta" gravitazionale, infatti, non solo c'è un "freno" al tuo char che sale, ma poi lo stesso cade verso il basso... il che mi fa pensare che nel discorso che ho fatto prima probabilmente ho commesso un errore grave anche concettuale... comunque ti posso rassicurare che l'uso di VelMul per la frizione X ottiene il risultato che ti ho detto con un effetto minore (provato sperimentalmente)...

Poi, rimuginando un po' meglio, sono quasi sicuro di aver detto una cazzata sul concetto di Accelerazione come moltiplicazione di velocità... credo sia un discorso che vada bene per la frizione, ma non per la accelerazione che, come dici tu, dovrebbe essere una somma di velocità
(cazzarola, dalla stanchezza - ieri sera - non mi sono accorto che ho scritto quasi sicuramente una cazzata). Ieri mi sono fatto ingannare dalla unità di misuta, ma non ho pensato alla sua analisi (che significa m/s per ogni secondo... e quindi dovrebbe essere una aggiunta di velocità e non una moltiplicazione). Sempre in fisica (sempre se non ricordo male, ma visto che ho detto già una cazzata ieri, ora non sono del tutto sicuro) credo che la Frizione sia una FORZA (dovrebbe essere la forza di inerzia) quindi, se è così, ho detto una cosa in parte giusta ed in parte sbagliata...

E quindi (ammesso che ora abbia ragione) la risposta dovrebbe essere

Per le accelerazioni (come quella gravitazionale) abbiamo una somma di velocità (VelSet)
Per la frizione (FORZA di inerzia) dovremmo avere una MOLTIPLICAZIONE di velocità (VelMul)

Sostanzialmente il discorso fatto sulla frizione x e sull'uso di VelMul rimarrebbe corretto (e comunque valido perché verificato anche sperimentalmente). Di sicuro, al 300%, vale il discorso che ho fatto all'inizio sulla "matematica informatica"

----

In ogni caso Le costanti

airjump.num
airjump.height

Non centrano con le variazioni di velocità. Il primo dice quanti salti "consecutivi" sono possibili (1 se vuoi che il tuo char possa solo saltare normalmente, 2 se vuoi che il tuo char possa fare un secondo "balzo in alto" mentre è già in aria, 3 o più se vuoi che il tuop char possa fare altri "balzi in alto" in aria)
Il secondo dice la distanza minima dal suolo (espressa in pixel. presumo) in cui è permesso fare un "balzo in alto" (qualora permesso perché rimasti a disposizione)

Quote

Bhè infine che dire, grazie per la smisurata attenzione!
Di sicuro se avrò altri problemi mi rivolgerò a questo forum (a te in particolare se la cosa ti diverte).

Bhe figurati, quando è possibile io aiuto chiunque, specie quando ho l'occasione di trattare di programmazione avanzata. Devo però dirti (anche per onestà intellettuale: sei nuovo e potresti non saperlo) che io, ufficialmente, ho abbandonato la scena perché mi devo dedicare anima e corpo a delle cose personali a tempo pieno.
Ciò non toglie che quando posso (e se posso) cerco di dare uno sguardo al sito e dare il mio contributo laddove altri collaboratori (validissimi) potrebbero avere delle difficoltà (perché alcune cose si imparano anche con gli esperimenti di programmazione PURA ... nel senso di cimentarsi con il C++ etc). Ma non posso mai garantire che, ad esempio, un giorno o l'altro possa sparire del tutto senza preavviso (magari rimanendo inattivo per mesi).
Io comunque spero tu continuerai a frequentare lo stesso questo forum (abbiamo comunque degli utenti che promettono bene) anche perché una persona che, come te, ha dimostrato un livello di competenza molto buono serve sempre.

Quote

Dannazione mi sono accorto tardi di questo post XDXDXD come dice nobun è raro poter discutere di programmazione, mannaggia XD

cmq, davvero un applauso a Nobun, perché credo che anche un niubbo avrebbe capito quello che hai scritto XDXDXD

Saluti

Squall

Grazie, troppo gentile, soprattutto se detto da un utente del tuo calibro :rulez:
(per PaToS... ecco un esempio di un altro ragazzo che secondo me ha buone basi)

Messaggio modificato da Nobun il 28 May 2008 - 10:32

[Squall LionHeart™]

Nobun, detto:

Grazie, troppo gentile, soprattutto se detto da un utente del tuo calibro rulez.gif
(per PaToS... ecco un esempio di un altro ragazzo che secondo me ha buone basi)

:blush: :blush: :blush: :blush: :blush: troppo lusinghiero :ph34r: XD

sono una divinità suprema io, mica il signore incontrastato dell'universo U_U... XDXDXDXDXD

Saluti

Squall

[PaToS]

Nobun, su May 28 2008, 11:06, detto:

Bhe figurati, quando è possibile io aiuto chiunque, specie quando ho l'occasione di trattare di programmazione avanzata. Devo però dirti (anche per onestà intellettuale: sei nuovo e potresti non saperlo) che io, ufficialmente, ho abbandonato la scena perché mi devo dedicare anima e corpo a delle cose personali a tempo pieno.

Se questo è abbandonare la scena!! :D:D

Comunque mi permetto di correggerti una cosa soltanto, la friction onestamente penso sia l'attrito e ti spiego perchè:
La forza di inerzia è una forza che tende a non modificare lo stato di moto del corpo, quindi se io sono in corsa la forza di inerzia mi spinge ad andare avanti, ed è quella la forza che devo vincere per fermarmi. Se invece io sono fermo è la forza che devo vincere per iniziare a muovermi.
L'attrito invece è in questo caso la forza che ti fa rallentare. Infatti se non ci fosse attrito col terreno quando si appoggia il piede, si continuerebbe ad andare avanti per inerzia (immagina com'è doversi fermare sul ghiaccio o ancora peggio nell'olio, oppure iniziare a correre).
Ciò conferma comunque che per la friction è meglio velmul, infatti la forza d'attrito ti fa fermare, non invertire la corsa (come quella di gravità).

Un ultima cosa, non per infrangere i vostri sogni, però io ho iniziato 2 settimane fa a guardare il mugen più da vicino... e fin'ora l'unica programmazione che ho fatto è stata con turbo pascal (al liceo, ma veramente poca roba) e un po' (ma poco davvero) di html ad un corso. Ciò non toglie che se potessi essere d'aiuto non macherò...

[Nobun]

Bhe ti ringrazio per la tua correzione e spiegazione. Ho imparato qualcosa di nuovo (non si finisce mai di imparare).

Quote

Un ultima cosa, non per infrangere i vostri sogni, però io ho iniziato 2 settimane fa a guardare il mugen più da vicino...

Questo può anche essere letto al contrario... se in così poco tempo sei già riuscito a padroneggiare (seppur magari in maniera non completa) concetti che ai più sfuggono, dimostri comunque un ottimo potenziale di apprendimento.
E poi ho sempre sostenuto che la bravura non sta tanto nel CONOSCERE la risposta, quanto piuttosto nel SAPERLA TROVARE... io stesso non mi vergogno a dire di essere uno che legge continuamente i tutorial ufficiali Mugen non appena ha anche un minimo dubbio.
In ogni caso, già adesso, dimostri comunque una solidità di conoscenze e di modo di ragionare che ti permettono essere ad un livello molto superiore rispetto ad un normale programmatore alle prime armi.
Ovviamente, come tutti, imparerai anche con l'esperienza ed ascoltando chiunque (a volte si impara molto anche dall'intuizione e dalle conoscenze di un utente che, sulla carta, può apparire meno esperto di te).

Quote

Ciò non toglie che se potessi essere d'aiuto non macherò...

Attenzione alla cosecutio...
In questo forum abbiamo una spietata iniziativa volta ad incentivare l'utilizzo di un italiano corretto. I nostri sadici utenti potrebbero inserire una frase come questa nel topic (che dovrebbe essere temutissimo dai nostri utenti :P) intitolato "lezioni di italiano" (si trova in "umorismo"). :ph34r:

[Verza]

Nobun, su May 28 2008, 13:10, detto:

Attenzione alla cosecutio...
In questo forum abbiamo una spietata iniziativa volta ad incentivare l'utilizzo di un italiano corretto. I nostri sadici utenti potrebbero inserire una frase come questa nel topic (che dovrebbe essere temutissimo dai nostri utenti :P) intitolato "lezioni di italiano" (si trova in "umorismo"). :ph34r:

Mi fischiano le orecchie,qualcuno parla di me? :rotfl:
Tranquillo gli errori di digitazione non vengono segnalati,anche se è meglio scrivere bene.

[SlayerGatsu]

intro-inter-missione...

scusa e'... ma il motivo per cui ti cominciava ad andare indietro e' probabilmente che l'animazione finisce prima di 50 tick, O e' a loop infinito, in qual caso (se l'ultima immagine e' con ticks -1) il codice del trigger si proverebbe sempre vero.... e l'anim non combierebbe...

pero' puoi fare un changestate per mettere a 0 quando la vel e' = o minore di 0.

quel semplice change state ti rimette nella stand, e fa si che smetti di muoverti indietro (perche a un velset = 0,0...)

cosi' non hai problemi....

altra cosa... lo state del salto dovrebbe essere uno solo, dovresti usare il veladd ed aggiungere velocita' se vieni dalla corsa... magari anche cambiare animazione!
difatti l'unico motivo di fare modifiche qui, dovrebbe essere di avere un changeanim che porta l'animazione differente per il salto, se il prevstateno e' = 100...
ma invece di fare col pravestateno fai un varset nello stato della corsa, e poi nel 40, se la var e' settata applichi l'animazione differente.
ci sta' un modo migliore per farlo... con cui e' fatto anche Gill... che permette di scrivere meno e non dover modificare niente altro che una 3 linee di codice in totale...

comunque si, mi stupisce il fatto che finalmente si parla di cose interessanti! B)

[PaToS]

SlayerGatsu, su Jun 2 2008, 06:48, detto:

pero' puoi fare un changestate per mettere a 0 quando la vel e' = o minore di 0.

Infatti è così che avevo fatto.
All'inizio avevo solo messo che doveva cambiare quando la velocità era = 0, poi ho messo il <= 0 che mi toglieva il problema. Cmq non ricordo se l'ho cambiato ancora alla fine o è rimasto così.
Quello che non capivo è che alla fin fine io gli stavo dicendo di diminuire la velocità fino a 0, e una volta arrivata a 0 il veladd non doveva più attivarsi (trigger1 = .... && vel x !=0). L'ultimo animelem era con tempo -1, ma la condizione sulla velocità diversa da 0 avrebbe dovuto farmi fermare.

Per il salto in corsa il problema era che non riuscivo a fargli applicare le velocità diverse solo nella stessa direzione della corsa. Eppure il comando mi sembrava giusto. Onestamente non mi ricordo se alla fine ho capito che sbagliavo. Vabbè...

Era la mia prima discussione ma ha preso parecchio anche a me!!
Speriamo che ricapiti!

Ciao

[SlayerGatsu]

prova a fare qualcosaltro che vediamo dai B)

[PaToS]

Ho provato a fare molte altre cose, ma i problemi che sono saltati fuori li ho risolti da solo!
Peccato..... ih ih