[SlayerGatsu]

Ragazzi ho reperito una copia di winmugen con i dannati parametri per il debug,
se vi serve mandatemi una mail che saro' lieto di spedirvelo,

e' solo l'.exe perche ovviamente usa gli stessi parametri e .dll in oltre gli stessi plug ins....

e contiene anche le nuove immaggini e sprites richiesti per il char! quindi si garantisce per il bug testing dei Winmugen Chars! B)

[Ice King]

:huh: Quindi i dos mugen chars nn dovrebbero + dare tanti problemi come fanno ora?

[SlayerGatsu]

bhe e' solo piu' facile sapere quali azioni e sprite aggiungere! B)

[Ice King]

fico :D

[Nobun]

Ho scoperto finalmente come risolvere il problema "assert failure....."

E' una stupidagine solo del winmugen.

Pensate che dipenda dall' sff? dall' air? dal cns? dal cmd?

SBAGLIATO.

Dipende semplicemente dal Def, precisamente da un non corretto utilizzo della linea pal.defaults (si trova in [info])

Sul winmugen pal.defaults DEVE essere presene e deve elencare una sequenza di tutte le palette.

Se sono tre:

pal.defaults = 1,2,3

se sono quattro:

pal.defaults = 1,2,3,4

e così via.

L' ordine dei valori può essere anche diverso, ma deve contenere tutti i numeri delle palette usate (1=pal 1, 2=pal 2 e così via) una sola volta. Insomma si deve dare una sequenza perfetta.

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

Inoltre la presenza dei parametri "versiondate" e "mugenversion" all' interno della sezione [INFO] del def può dare problemi col winmugen. Meglio cancellarli.

[SlayerGatsu]

:fiuu:
verifichero', am allora teoricamente gill dovrebbe dare lo stesso erroe!
la definizione inizia da 4
e poi pensavo rappresentasse il conto di quale tasto premere per dare il via al selezionamento della prima palette... almeno mi ricordo di aver letto cio' su qualche doc, e poi non capisco perche, il char maschera de muerte dei seya mi dava l'errore per i priumi 15 giorni e poi non lo habbia mai Piu dato in seguto...
comunque per quanto vale...

fate tutti un test, create uno stage chiamato random...

(ne ho fatto uno e lo posto a brave)

esso e' la risoluzione ipotetica al problema Continua in modalita' arcade...

in pratica se non hai uno stage chiamato random, il pc dice che non trova uno stage chiamato random, percio' con uno stage chiamato random mugen trova lo stage ed usa esso, anche se esso non e' scritto nel select! (dato che e' totalmente indipendente... )
fate un tentativo che la teoria regge! :rotfl:

[Nobun]

Mi ero spiegato male....

Se ad es. hai 4 palette puoi scrivere qualunque combinazione tu voglia. EX:

pal.defaults = 4,1,2,3

pal.defaults = 4,2,3,1

pal.defaults = 3,1,4,2

....

e così via. (ovviamente da usare una sola volta. Parametro obbligatorio in winmugen altrimenti si chiude senza messaggi).

Quello che intendevo dire è che devi usare tutti i numeri di tutte palette usate una sola volta, creando una combinazione completa. L'ordine è libero.

-------

Poi, non lo avevo detto, per qualche strana ragione l'assert failure sembra manifestarsi solo nelle modalità tipo ARCADE (vs cpu) e non anche nelle modalità tipo VERSUS (vs player). Sperimentato ieri sera. Comunque fai i tuoi tentativi e tienimi informato.

[SlayerGatsu]

INVECE, dopo accurato studio del fix di un personaggio...

si e' rtivelate per me giusta la mia Primissima Ipotesi.

si trattava infatti del file Air, Nel quale erano buttati li 2 clsn SENZA nessuna riga per sprite sottostante.

come? costi...

; �U‚è•Ô‚è“®�ì
;[Begin Action 5]
Clsn2Default: 2
 Clsn2[0] = -10,  0, 10,-79
 Clsn2[1] =  -4,-92,  6,-79

; ‹ü‚Ý‚È‚ª‚ç�U‚è•Ô‚è“®�ì
[Begin Action 6]
Clsn2Default: 3
 Clsn2[0] =  10,  0,-10,-47
 Clsn2[1] =   5,-47, -5,-60
 Clsn2[2] =  10,-39, 15,  0

; —§‚¿�ó‘Ô‚©‚ç‹ü‚Ý�ó‘Ô‚ÖˆÚ�s‚·‚é“®�ì
[Begin Action 010]

Ovviamente in questo caso i file erano Puramente inutili pertanto li ho commentati ed esclusi B)

il char funziona perfettametne B)

[Nobun]

Ok, ma anche l'errore che ti ho indicato io dà l'assert failure.
Quindi, direi che l'asser failure può avere più cause:

1) Def errato: uno dei parametri (testato solo con pal.defaults) è male settato.

2) Air errato: definizione di un clsnboxes errato (come da te spiegato sopra).

Se trovate altri casi di assert failure postateli qui. Poi ci facciamo un tutorial.

[SlayerGatsu]

ebbene SI ma... ho una teoria

1) Def errato: uno dei parametri (testato solo con pal.defaults) è male settato.

2) Air errato: definizione di un clsnboxes errato (come da te spiegato sopra).

3) Pcx errati.... si visualizzano Ovunque MA non se li estrai... quindi mettere lo shot sul Mcm, fare una foto allo schermo e ripulire lo sprite... poi lo editi e hai ricreato quello buono... adesso pero' inventero qualcosa di rapido anche per questo...


4) Ogni errore che il mugen NON sa' cosa sia! in pratica essendo Winmugen un Beta, e' il rimasuglio di un debug....

[Nobun]

Possibile.... anch' io penso che la ragione comune dell' assert failure sia quella da te descritta al punto 4 (a confermare ciò i fatto che tale problema sul LinuxMugen - la versione originale da cui il winmugen deriva - sembra non avere tale tipo di errore).
...comunque testiamo tutte le hp così ci possiamo fare un tutorial.

La prima è stata testata da me. La seconda da te. La terza la hai testata? Prova a fare qualche sff strampalato e associalo ad un char in caso non ci fosse stato un test.

Dai che se troviamo tutte le possibili cause dell'asert failure diventiamo degli invidiati bug-testers :P

[SlayerGatsu]

Questo parametro, Scritto cosi come lo posto,
In qualsiasi punto di programmazione darra l'errore
Assert Failure in Array.h line 101

[State 3050, 2]
type = NotHitBy
trigger1 = AnimElemTime(0) >= 0 && AnimElemTime(6) < 2
value = , AA, AP

da oggi in poi bisogniera' controllare anche la programmazione, E lo stato lo potete trovare solamente Individiando i tasti che premete, e derivandolo dal Cmd.

E per essere precisi, E' il trigger che risuta ERRATO

AnimElemTime(0) >= 0 && AnimElemTime(6) < 2

in Winmugen di fatto ha poco senzo scritto cosi'...

Nobun Edit: e come dovrebbe essere scritto invece questo trigger per non dare errore? Scrivilo qui ed edita nuovamente questo topic, scrivendo la risposta al posto di queste righe. Grazie. :lol:
slayer edit: e io sto attualmente cercando di dare un senzo al trigger... per ora fa sesso

----
Nobun edit: secondo me va sostituito all' AND un OR....
quindi AnimElemTime(0) >=0 || AnimElemTime(6) < 2
In effetti AniElemTime(0) >=0 significa che devi essere al frame 0 (ma esiste il frame 0???), a tempo >= 0.
AnimElemTime(6) <2 significa che devi essere al frame 6 a tempo <2.
Ma come è possibile che si verifichi la codizione in cui venga visualizzato (di una stessa animazione) l'elemento 0 con l'elemento 6? E' impossibile.
Forse l'autore voleva che la condizione fosse valida DA AnimElemTime(0) >=0 A AnimElemTime(6) < 2.

In tal caso meglio trigger1 <= TIME dove time è la somma dei valori dei tempi dei primi 6 elementi dell'animazione + 2 es.

200,1, 0,0, 5
200,2, 0,0, 5
200,3, 0,0, 5
200,4, 0,0, 5
200,5, 0,0, 5
200,6, 0,0, 5

in questo caso TIME = (5*5) + 2 = 25 + 2 = 27

quindi in questo caso il trigger sostitutivo sarebbe: trigger1 = time <= 27

[Nobun]

Novità sul panorama "Assert Failure".

Come giustamente hai detto alla guild ci sono arrivati, ma sono al nostro stesso livello se non più indietro.

Hanno anche loro scoperto l'assert failure dipendente da pal.defaults (FILE DEF).
Ma solo in parte perchè non hanno capito bene - a differenza mia - come funziona la cosa (hanno detto... dà errore perchè manca, mentre può anche causarlo quando c'è ma è mal settato).

Ma non mi sembra abbiano scoperto il fatto dell' AIR e del CNS.

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

Inoltre ne hanno scoperto uno dipendente dall' uso (che noi non facciamo) di MWC4 (Mugen Windows Configurator). Tale scoperta sarebbe stata per noi impossibile visto che NON USIAMO Mwc4 e ne sconsigliamo caldamente l'uso (crea solo casini quel programma... andrebbe bandito!).