collision check a eventi 0

[Guardian of Irael]

 

Evento 2: se la switch è On, mette delle attese, fa partire l'attacco, Jordi subisce e la switch va Off.

Condizione se switch è ON

---- switch metti OFF

---- attese varie e calcoli dopo comunque calcolate perché dentro la condizione

fine condizione

Prova così Arkady, non dovrebbe darti problemi. La switch viene messa subito OFF e non dovrebbero esserci problemi di ripetizione evento (massimo puoi ripetere di nuovo switch OFF a fine evento richiamato) fin tanto che l'eroe non è vicino al mostro e quindi la switch viene rimessa su ON. Era quello che intendevo col saltare le attese.

^ ^

[GabryHadoken]

come minimo si merita la miglior risposta infatti al "povero" Arka ho dato la best answer, se non altro per come ha eviscerato il problema fino in fondo, proponendo tra l'altro ultra dettagliate soluzioni pratiche e non solo intelligenti constatazioni teoriche, e la santa pazienza poi ^^

però il punto è che sono per natura un cocciuto quindi ci devo sbattere la testa per bene e poi cercare perlomeno di appellarmi a tutto quel che riesco perchè non mi si atrofizzi il cervello a elemosinare sempre la pappapronta, è un discorso di etica se così vogliamo chiamarla Arka, nulla dipersonale, anzi.

io ad esempio sto pensando di inserire una qualche condizione sfruttando la variabile passi del giocatore, cioè per farla semplice se dopo che il sistema acquisisce quei valori per le variabili di coordinate giocatore ed evento, se il giocatore ha fatto un passo non succede nulla. questo teoricamente mi sembra fattibile ed ora ci sto lavorando su, poi magari si rivela un altro vicolo cieco però ci devo almeno provare a far funzionare il cervello sennò tanto vale che rinuncio in partenza.

Modificato da GabryHadoken, 03 December 2016 - 23:38 PM.

[HROT]

Considerando tutto il casino che state tirando su per fare questo sistema ora mi domando.. ma ne vale la pena?

non è stato ben chiarito quale sia il vantaggio di questo metodo

serve un parallelo per OGNI nemico, e OGNI nemico ha bisogno delle sue X e Y

in una mappa molto popolata le prestazioni cadrebbero a picco

 

Usando un contatto con l'evento, come avevo suggerito, si potrebbero fare tutte le verifiche su "chi guarda chi" o su "chi preme cosa" solo ed esclusivamente quando il contatto è avvenuto (zero eventi paralleli o switch) e se i calcoli non fossero in parallelo basterebbe una sola X e una sola Y per TUTTI i nemici

 

Qualcuno può spiegarmi in cosa questo metodo dovrebbe essere migliore? (scusate se insisto, ma davvero non l'ho capito)

[GabryHadoken]

Forse sono io che mi spiego male o che prendo per scontato qualcosa che non è.

Allora, cerco di essere più comprensibile.

 

Gimmy ha calcolato le coordinate con un processo parallelo che fa unicamente questo a ripetizione: se il nemico si trova a una casella da te mette On la switch collision. Sempre, in qualsiasi istante, anche se la metti Off con un altro evento lui la rimette On immediasubito.

 

In un altro evento lui mette attese e controattese e poi parte l'attacco vero e proprio.

Di norma le attese dovrebbero prevenire i problemi, ma qui generano il paradosso che i problemi li creano loro. In un modo subdolo.

 

Normalmente che succede nel bs di Gimmy?

Evento 1: calcola la prossimità e mette On la switch.

Evento 2: se la switch è On, mette delle attese, fa partire l'attacco, Jordi subisce e la switch va Off.

 

E fin qui non c'è nessun problema: se tu sei vicino al nemico e stai fermo quello ti colpisce e fine.

 

Se invece arriva il pignolo di Arkady, questo rompiscatole fa cose strane: preme tasti vari per cercare di allontanarsi dal nemico prima di subire il danno. Il risultato è che Jordi riesce ad allontanarsi dal nemico di una o due caselle grazie alle attese che ho segnato in blu (possono trovarsi in un qualsiasi punto dell'evento prima dello switch off e ti daranno l'occasione di allontanarti). Siccome prima dell'attacco vero e proprio non c'è la condizione "se Jordi e il nemico sono vicini" il giocatore subirà l'attacco anche se già sarà arrivato in Messico nel frattempo, creando queste strane glitch (e sospetto che questa sia anche la causa della grafica che si inceppa di cui parlavi).

 

Io cosa proponevo?

Evento 1: calcola la prossimità e mette On la switch, ma al contempo la mette Off non appena ti allontani.

Evento 2: se la switch è On, mette delle attese, controlla se la switch è ancora On, fa partire l'attacco, Jordi subisce.

 

Perché ho fatto questo cambiamento? Perché l'evento 1 nel caso di Gimmy mette una volta la switch On e quella resta On finché non intervieni manualmente mettendola Off. Nel mio caso, l'evento 1 si accorge se nel frattempo ti allontani e in al caso la mette Off. L'evento 2 prima di far partire l'attacco adesso controlla se la switch è ancora On (se ti sei allontanato l'evento 1 l'avrà già messa Off) e se è Off l'attacco non parte e quindi se già hai preso la via del Messico non subisci.

 

Vai a ripescare il tuo evento e il mio.

Il tuo fa questo:

 

Spoiler

 

Se X è 0

-se Y è 1

--Switch On

-Fine

-se Y è -1

--Switch On

-Fine

Fine

 

Se Y è 0

-se X è 1

--Switch On

-Fine

-se X è -1

--Switch On

-Fine

Fine

 

Giusto?

 

 

Il mio fa questo:

 

 

Se X è 0

-se Y è 1

--Switch On

-Altrimenti

--se Y è -1

---Switch On

--Altrimenti

---Switch Off

Altrimenti

-Se Y è 0

--se X è 1

---Switch On

--Altrimenti

--se X è -1

---Switch On

--Altrimenti

--Switch Off

Altrimenti

-Switch Off

-Fine

Fine

 

Lo traduciamo in italiano? (cavolo, tradurre in italiano è la cosa per cui mi pagano nella vita, quindi almeno questo dovrei saperlo fare )

 

Se la X è 0 allora controllo se la Y è 1.

Se è 1 metto la Switch On, altrimenti mi chiedo se la Y è -1.

Se è -1 metto la Switch On, altrimenti la metto Off.

 

Fermiamoci qui. Nella parte rossa ho concatenato le due condizioni create da te, nella parte blu ho aggiunto un altrimenti che prende in considerazione il caso in cui la X è 0 e la Y non è né 1 né -1, quindi la switch deve essere Off.

 

Poi continuo con un altrimenti legato a Se la X è 0. Significa che quello che c'è scritto nell'altrimenti viene preso in considerazione se la X non è 0. Quindi continuando da sopra abbiamo.

 

Se la X è 0 allora controllo se la Y è 1.

Se è 1 metto la Switch On, altrimenti mi chiedo se la Y è -1.

Se è -1 metto la Switch On, altrimenti la metto Off.

Altrimenti

Se la Y è 0 allora controllo se la X è 1.

Se è 1 metto la Switch On, altrimenti mi chiedo se la X è -1.

Se è -1 metto la Switch On, altrimenti la metto Off.

 

Qui ho unito l'altra metà del tuo evento alla parte superiore: se la X non è 0 allora mi chiedo se la Y è 0. E aggiungo un altrimenti switch Off nel caso in cui la Y sia 0 e la X non sia né 1 né -1

Infine ci vuole un ultimo altrimenti a Se la Y è 0 per dire al programma cosa fare quando sia la X che la Y sono diverse da 0.

 

Se la X è 0 allora controllo se la Y è 1.

Se è 1 metto la Switch On, altrimenti mi chiedo se la Y è -1.

Se è -1 metto la Switch On, altrimenti la metto Off.

Altrimenti

Se la Y è 0 allora controllo se la X è 1.

Se è 1 metto la Switch On, altrimenti mi chiedo se la X è -1.

Se è -1 metto la Switch On, altrimenti la metto Off.

Altrimenti la metto Off.

Fine

 

Nel secondo Evento ho aggiunto un controllo "se la switch è On" per assicurarmi che Jordi durante l'attesa non si sia spostato, perché in tal caso l'Evento 1 l'avrà messa Off.

 

Guarda, non so come essere più chiaro di così.

Ho usato anche i colori per distinguere le varie parti del codice e non fare confusione. Il problema vero e proprio è che spiegandole le cose diventano difficili e complicate, facendole sono molto più semplici.

allora Arka usando il tuo metodo il TRacking fila liscio come l'olio, nessun glitch legato a viaggi in Messico XD

tuttavia cè qualcosa che rovina l'attacco, io sto pensando a tutto quel switchare on/off su processo parallelo.. mi si blocca il nemico quando col trigger tocco giocatore provo ad attaccarlo e nemmeno subisce l'attacco, a volte si blocca perfino per poi risbloccarsi da solo ( il nemico) riesco a dargli un colpo una volta su dieci.. cè qualcosa che non va, come l'avevo fatto prima senza switch ma assegnando il colpo direttamente al posto dello switchare ON tutto il resto funzionava bene a parte la glitch famosa.

adesso riprovo con le variabili sui passi

Modificato da GabryHadoken, 04 December 2016 - 10:17 AM.

[Guardian of Irael]

@HROT: escludendo il progetto di Gabry alcuni dei vantaggi generali solitamente sono questi:

- te ed il nemico non dovete premere "la freccia direzionale" per fare danno, ma semplicemente stare sul tile adiacente ed avere l'avversario davanti per attaccare e quindi tutte le frequenze ed i movimenti personalizzati gestiti in proposito

- possibilità con lo stesso codice di fare armi che attaccano a due tile di distanza semplicemente modificando "gli uguali"

- possibilità (caso di Gabry) del nemico di girarsi notando l'eroe che gli fa le boccacce da dietro

- possibilità di considerare contemporaneamente più nemici intorno per tecniche ad area

- possibilità dei nemici di attaccare contemporaneamente l'eroe: il tocco evento non è un parallelo non funziona se già un altro evento a tocco è in funzione, quindi se 4 nemici raggiungono l'eroe ed ognuno ci mette un secondo ad attaccare col parallello in un secondo l'eroe riceve 4 attacchi, mentre con la collisione ci vogliono 4 secondi ed ogni evento attacca a turno

- se metti un aspetta per gestire i tempi il tuo eroe rimarrà bloccato finché l'aspetta non sarà terminato senza darti la possibilità di muoverti in maniera fluida.

Tra tutti il primo e l'ultimo mi paion le cose più problematiche: non è bello dover sempre tenere premuta una freccia verso il nemico per attaccare, al giocatore non sembra "responsivo" aver davanti il nemico e non fargli nulla da fermi anche se effettivamente la spada ci va sopra e, così, muoversi e venire anche per pochi frames bloccati dal nemico vicino mentre si sta correndo in maniera fluida.

^ ^

 

Gabry usa una strategia mista ed infatti soffre sia del problema della freccia direzionale che quella del nemico che blocca i movimenti (vecchia demo).

^ ^

 

@Gabry: non l'ho provata, ma la tecnica dei passi non dovrebbe essere prioritaria rispetto a quella delle coordinate, ti conviene cercare di aggiustare l'evento parallelo del danno. Prova anche la mia soluzione di mettere la switch OFF appena la condizione è verificata, ma non scordare il fatto che come ho detto qui sopra in questo messaggio a ROT il fatto di avere collisioni a tocco fa rimanere i problemi di eroe bloccato.
^ ^

[GabryHadoken]

Considerando tutto il casino che state tirando su per fare questo sistema ora mi domando.. ma ne vale la pena?

non è stato ben chiarito quale sia il vantaggio di questo metodo

serve un parallelo per OGNI nemico, e OGNI nemico ha bisogno delle sue X e Y

in una mappa molto popolata le prestazioni cadrebbero a picco

 

Usando un contatto con l'evento, come avevo suggerito, si potrebbero fare tutte le verifiche su "chi guarda chi" o su "chi preme cosa" solo ed esclusivamente quando il contatto è avvenuto (zero eventi paralleli o switch) e se i calcoli non fossero in parallelo basterebbe una sola X e una sola Y per TUTTI i nemici

 

Qualcuno può spiegarmi in cosa questo metodo dovrebbe essere migliore? (scusate se insisto, ma davvero non l'ho capito)

non saprei Hrot al massimo l'ho provato con 3 nemici contemporanemente, e non laggava, quando risolvo il dilemma provo su mappa larga con una ventina di nemici e ti faccio sapere come va XD

essendo testardo e cocciuto non si tratta ora di cosa sia migliore o no ma solo di far funzionare questo sistema qua! non deve vincere il tool ma la caparbietà dell'eventatore ^^

se poi proprio non fosse fattibile proverò come stai dicendo te

 

 

@HROT: escludendo il progetto di Gabry alcuni dei vantaggi generali solitamente sono questi:

- te ed il nemico non dovete premere "la freccia direzionale" per fare danno, ma semplicemente stare sul tile adiacente ed avere l'avversario davanti per attaccare e quindi tutte le frequenze ed i movimenti personalizzati gestiti in proposito

- possibilità con lo stesso codice di fare armi che attaccano a due tile di distanza semplicemente modificando "gli uguali"

- possibilità (caso di Gabry) del nemico di girarsi notando l'eroe che gli fa le boccacce da dietro

- possibilità di considerare contemporaneamente più nemici intorno per tecniche ad area

- possibilità dei nemici di attaccare contemporaneamente l'eroe: il tocco evento non è un parallelo non funziona se già un altro evento a tocco è in funzione, quindi se 4 nemici raggiungono l'eroe ed ognuno ci mette un secondo ad attaccare col parallello in un secondo l'eroe riceve 4 attacchi, mentre con la collisione ci vogliono 4 secondi ed ogni evento attacca a turno

- se metti un aspetta per gestire i tempi il tuo eroe rimarrà bloccato finché l'aspetta non sarà terminato senza darti la possibilità di muoverti in maniera fluida.

Tra tutti il primo e l'ultimo mi paion le cose più problematiche: non è bello dover sempre tenere premuta una freccia verso il nemico per attaccare, al giocatore non sembra "responsivo" aver davanti il nemico e non fargli nulla da fermi anche se effettivamente la spada ci va sopra e, così, muoversi e venire anche per pochi frames bloccati dal nemico vicino mentre si sta correndo in maniera fluida.

^ ^

 

Gabry usa una strategia mista ed infatti soffre sia del problema della freccia direzionale che quella del nemico che blocca i movimenti (vecchia demo).

^ ^

 

@Gabry: non l'ho provata, ma la tecnica dei passi non dovrebbe essere prioritaria rispetto a quella delle coordinate, ti conviene cercare di aggiustare l'evento parallelo del danno. Prova anche la mia soluzione di mettere la switch OFF appena la condizione è verificata, ma non scordare il fatto che come ho detto qui sopra in questo messaggio a ROT il fatto di avere collisioni a tocco fa rimanere i problemi di eroe bloccato.
^ ^

no ma l'eroe non si blocca mai! è il nemico che si blocca ogni tanto, comunque fondamentalmente devo sbolognarmela io perchè voi conoscete parte del sistema giustamente non avete  il panorama completo, anche se alla fine cè solo il trigger tocco giocatore sull'evento per l'attacco dell'eroe che leva tot hp alla variabile hp del nemico, non cè altro praticamente.

[HROT]

<.<
Il contatto con l'evento funziona anche con la pressione del tasto azione non serve che premi la freccia
(almeno su Ace)
 
Le armi che attaccano a distanza hanno altri problemi (come i muri) quindi avranno bisogno comunque di un codice diverso
stessa cosa le tecniche ad area, avranno bisogno di memorizzare tutte le x e le y coinvolte nell'area
(in ogni caso la discussione riguarda le collisioni)

"- possibilità (caso di Gabry) del nemico di girarsi notando l'eroe che gli fa le boccacce da dietro"
questa non l'ho capita
 
Svolgere i calcoli di un contatto richiede un tempo ridicolo (soprattutto quando sono gli unici calcoli da effettuare)
..il fatto di non poter subire danni simultanei è vero, come è vero che i computer non svolgono 2 operazioni simultaneamente (ma nessuno se ne è mai accorto!)
Infatti non ci vorrebbero 4 secondi.. probabilmente mezzo decimo di secondo dopo staresti già ricevendo il secondo attacco
c'è una certa differenza tra un cold down e il tempo per eseguire i calcoli, il quale non arriverà mai a "un secondo" (a meno che non li fai eseguire a un bambino delle elementari invece che a un computer)
 
Per gestire il tempo di attesa si può aggiungere un evento parallelo (ma uno solo per l'eroe non uno per ogni nemico)
infatti il tempo di attesa del nemico è già determinato dalla sua frequenza di movimento (movimento o "tentativo di movimento" che sia)

 

EDIT:

@Gabry

Capisco bene la questione, se faccio queste osservazioni è perchè mi rendo conto che gli ABS sono un argomento complesso e che spesso bisogna scendere a compromessi

Volevo solo assicurarmi che i compromessi a cui stai scendendo siano i migliori per il tuo sistema

Modificato da HROT, 04 December 2016 - 10:57 AM.

[Guardian of Irael]

@Gabry:

 

no ma l'eroe non si blocca mai! è il nemico che si blocca ogni tanto, comunque fondamentalmente devo sbolognarmela io perchè voi conoscete parte del sistema giustamente non avete  il panorama completo, anche se alla fine cè solo il trigger tocco giocatore sull'evento per l'attacco dell'eroe che leva tot hp alla variabile hp del nemico, non cè altro praticamente.

Mi ricordo male allora? Mi pareva che nella demo che avevi rilasciato l'eroe rimanesse bloccato per pochi istanti vicino al nemico quando lo ingaggiava uno. Se vuoi fare da solo per me va bene, comunque se pensi che non conosciamo qualcosa posta tutto il codice e ci diamo un'occhiata per vedere cosa non va.

^ ^

 

@HROT:

 

Il contatto con l'evento funziona anche con la pressione del tasto azione non serve che premi la freccia
(almeno su Ace)

Il tasto azione funziona, ma deve essere lo stesso dell'attacco ed inoltre questa cosa vale per te, ma non per il nemico. Se il nemico si avvicina di un passo e tu stai fermo lui non ti attacca se non si avvicina di un altro passo ancora per tentare di andare sul tile che ti ospita.

^ ^

 

 

"- possibilità (caso di Gabry) del nemico di girarsi notando l'eroe che gli fa le boccacce da dietro"
questa non l'ho capita

Se il nemico è di spalle nel sistema di Gabry si accorge dell'eroe che gli è dietro, si gira e lo attacca. Questa cosa è possibile grazie alle coordinate, col tocco evento invece non può avvenire dato che il nemico deve andare contro all'eroe.

^ ^

 

Ah vero c'era il cool down, infatti nella prova che avevo fatto per il secondo ci voleva di meno non ci pensavo. Rimane comunque un grosso problema degli action. Non tutti gli action ci mettono pochi istanti per far attaccare. Immaginati un boss con un attacco molto potente o comunque un nemico forte che ha più istanze in campo. Pensa a giochi come Dark Soul e Monster Hunter, lì ce ne sono di attacchi lenti e tempistiche da seguire. Il fatto di avere contatti avrebbe comunque effetto e quando sono 4 ad accerchiarti anche se son pochi istanti te ne accorgi se metti animazioni appropriate e rischi anche di far perdere all'eroe le tempistiche di attacco/difesa.

^ ^

 

 

Per gestire il tempo di attesa si può aggiungere un evento parallelo (ma uno solo per l'eroe non uno per ogni nemico)
infatti il tempo di attesa del nemico è già determinato dalla sua frequenza di movimento (movimento o "tentativo di movimento" che sia)

Infatti a me piace la strategia mista del contatto e del parallelo o paralleli che richiama e mi ero dimenticato di suggerirla. Avevo risposto però al tuo...

 

(zero eventi paralleli o switch)

Se metti un parallelo a richiamo cambia abbastanza, ma ancora per quello che ti ho detto sopra in questo messaggio non è perfetto per tutte le situazioni se combinato col tocco.

^ ^

[GabryHadoken]

@Gabry:

Mi ricordo male allora? Mi pareva che nella demo che avevi rilasciato l'eroe rimanesse bloccato per pochi istanti vicino al nemico quando lo ingaggiava uno. Se vuoi fare da solo per me va bene, comunque se pensi che non conosciamo qualcosa posta tutto il codice e ci diamo un'occhiata per vedere cosa non va.

ah ti riferivi alla demo, no no quella è storia ormai. son tutto assorto nel presente.

confermo il tasto azione deve rimanere per fare da tasto azione, ho assegnato un tasto dedicato per l'attacco.

confermo anche sui nemici, questi non son scemi, si voltano verso di te e ti attaccano appena li avvicini (almeno quelli standard, nulla mi vieta poi di diversificare con nemici tontoloni che magari sembran inattaccabili frontalmente ma puoi prendere alle spalle per riempirli di botte)

[arkady18]

Boh, non so come mai hai quel problema. Potrei dare un'occhiata all'evento dell'attacco o alle demo (quella con la glitch e quella senza) per capire come mai in una funziona e l'altra no. Ma non avrò accesso a rpgmaker fino a stasera.

Come gestisci l'attacco? Deve essere lì il problema. Per caso è vincolato in qualche modo alla switch collision?
Nella correzione che ti ho proposto, in fondo, l'unica differenza è che quella switch va off, quindi non capisco perché dovrebbe bloccarti l'attacco.

Di preciso come lo gestisci? Un evento solo? Due? Potresti caricare gli screenshot dell'evento, così magari si capisce il problema?

[GabryHadoken]

Boh, non so come mai hai quel problema. Potrei dare un'occhiata all'evento dell'attacco o alle demo (quella con la glitch e quella senza) per capire come mai in una funziona e l'altra no. Ma non avrò accesso a rpgmaker fino a stasera.

Come gestisci l'attacco? Deve essere lì il problema. Per caso è vincolato in qualche modo alla switch collision?
Nella correzione che ti ho proposto, in fondo, l'unica differenza è che quella switch va off, quindi non capisco perché dovrebbe bloccarti l'attacco.

Di preciso come lo gestisci? Un evento solo? Due? Potresti caricare gli screenshot dell'evento, così magari si capisce il problema?

mi limito a postare uno screen dell'ennesimo processo parallelo a cui ho dovuto delegare il mero attacco del nemico verso il giocatore (quello vincolato allo switch 52 collision famoso) con il quale sembra finalmente risolto l'arcano ovviamente unitamente al tuo codice.

ma sono moooooolto contrariato con me stesso per questo modo di lavorare metà pappa pronta e metà a "tentativi" perchè non ritengo serva a gran cosa.

io vorrei capirle  le cose e trovare il modo di farle fare a tutti i costi. non fare copia incolla del tuo codice che per quanto spiegato bene non riesco a comprenderne ancora il senso pratico anche se funzionare funziona quindi suppongo la logica di fondo sia perfetta, ma io non l'ho ancora capita onestamente. e nemmeno "trovare" soluzioni a caso, come mi capita di fare ultimamente, ad esempio questo processo parallelo con cui ho risolto non sortiva gli stessi effetti se innestato come evento locale del parallelo delle coordinate (perchè mandava in stallo il medesimo portando la priorità sull'altra pagina) o come pagina a parte nell'evento nemico (dove a sua volta partendo in parallelo toglieva la possibilità di attivare il trigger contatto giocatore per l'attacco dell'eroe...) insomma un MACELLO...

non ti dico quante volte ho letto riletto il tuo codice ancora non mi è chiaro cosa cambia ai fini pratici.. si il discorso che nel mentre posso andare in Messico e somatizzare l'attacco a posteri mi è chiaro e l'ho sperimentato alla nausea girando in tondo di corsa o normale al nemico da ieri pomeriggio a stamattina

questo invece è l'evento sul nemico per l'attacco del giocatore 

N.B. se non metto quello switch off alla fine (anche se nel parallelo delle coordinate ce ne sono a gogo) a fine combattimento cè un altro curioso glitch,

ossia il mostro invece di sparire si ripropone semi opaco in con la grafica d'attacco così bloccato sulla mappa o_O la cosa curiosa è che controllando con F9 lo stato dello switch in entrambi i casi risulta comunque OFF a nemico sconfitto, sia che lascio questo comando nella pagina dell'attacco eroe sia che lo rimuovo, ma nel primo caso fila tutto liscio, levandolo invece (e qui mi vien da pensare che l'off scaturisca dal parallelo coordinate) si verifica la glitch descritta

Modificato da GabryHadoken, 04 December 2016 - 16:07 PM.

[Guardian of Irael]

 

ma sono moooooolto contrariato con me stesso per questo modo di lavorare metà pappa pronta e metà a "tentativi" perchè non ritengo serva a gran cosa.

io vorrei capirle  le cose e trovare il modo di farle fare a tutti i costi. non fare copia incolla del tuo codice che per quanto spiegato bene non riesco a comprenderne ancora il senso pratico anche se funzionare funziona quindi suppongo la logica di fondo sia perfetta, ma io non l'ho ancora capita onestamente. e nemmeno "trovare" soluzioni a caso, come mi capita di fare ultimamente, ad esempio questo processo parallelo con cui ho risolto non sortiva gli stessi effetti se innestato come evento locale del parallelo delle coordinate (perchè mandava in stallo il medesimo portando la priorità sull'altra pagina) o come pagina a parte nell'evento nemico (dove a sua volta partendo in parallelo toglieva la possibilità di attivare il trigger contatto giocatore per l'attacco dell'eroe...) insomma un MACELLO...

non ti dico quante volte ho letto riletto il tuo codice ancora non mi è chiaro cosa cambia ai fini pratici.. si il discorso che nel mentre posso andare in Messico e somatizzare l'attacco a posteri mi è chiaro e l'ho sperimentato alla nausea girando in tondo di corsa o normale al nemico da ieri pomeriggio a stamattina

Succede di non capire qualche pezzo di codice e di trovare soluzioni a caso! XD Vai tranquillo, però, visto che hai appena iniziato. Il codice inizia in un punto e finisce su un altro, se vedi che seguendolo non capisci qualcosa prova a chiedere che ti si spiega meglio quel punto e cosa accade usando quel determinato comando.

^ ^

 

Per quanto riguarda il codice nei due screen...

- proprio come discutevamo sopra le attese e gli aspetta (solo nel caso in cui metti aspetta per tutto il muovi evento) negli eventi a contatto con evento/giocatore bloccano il movimento dell'eroe stesso. Quindi in quel caso è possibile che l'eroe stia un po' fermo, lasciali solo se vuoi appunto che faccia una pausa mentre sta attaccando e sempre calcolando il tempo di attacco con l'animazione, ma se non vuoi dovresti spostarli in un parallelo.

- per il problema della switch da mettere per bloccare i paralleli... capita, a volte si usano degli aspetta a fine evento parallelo, il fatto è che rpg maker non è tanto furbo da far finire le cose istantaneamente e potrebbe esserci codice che si ripete due volte (succede anche con i muovi evento a salto).

^ ^

 

Di base il contatto eroe e tasto diverso da azione ti costringe a tenere sempre la freccia direzionale premuta verso il nemico, non è una gran cosa, per me dovresti iniziare a cambiare da qui, è una scomodità bella grande per un action. Inoltre con quel tipo di codice si tratta di un tenere premuti i due tasti per fare un attacco continuo. Con un aspetta fuori dalla condizione se tasto premuto migliora, ma anche con quelli che tieni dentro, in quel caso vanno bene.

Infine da come hai impostato la cosa il nemico ti colpirà sempre non appena sarai vicino ad esso, non vi è gioco di toccata e fuga. Comunque visto che vuoi fare una cosa stile attacco di mmorpg potrebbe sicuramente starci.

^ ^

[arkady18]

Boh. Non so quale sia il problema.
Prova a creare una mappa nuova con solo il nemico come unico evento e con questo stesso codice (magari non lo sai, ma c'è qualche altro evento che interferisce in qualche modo).

Se continua a non funzionare, mandami una demo anche con solo quella mappa e vedo se trovo il problema

[GabryHadoken]

Succede di non capire qualche pezzo di codice e di trovare soluzioni a caso! XD Vai tranquillo, però, visto che hai appena iniziato. Il codice inizia in un punto e finisce su un altro, se vedi che seguendolo non capisci qualcosa prova a chiedere che ti si spiega meglio quel punto e cosa accade usando quel determinato comando.

^ ^

 

Per quanto riguarda il codice nei due screen...

- proprio come discutevamo sopra le attese e gli aspetta (solo nel caso in cui metti aspetta per tutto il muovi evento) negli eventi a contatto con evento/giocatore bloccano il movimento dell'eroe stesso. Quindi in quel caso è possibile che l'eroe stia un po' fermo, lasciali solo se vuoi appunto che faccia una pausa mentre sta attaccando e sempre calcolando il tempo di attacco con l'animazione, ma se non vuoi dovresti spostarli in un parallelo.

- per il problema della switch da mettere per bloccare i paralleli... capita, a volte si usano degli aspetta a fine evento parallelo, il fatto è che rpg maker non è tanto furbo da far finire le cose istantaneamente e potrebbe esserci codice che si ripete due volte (succede anche con i muovi evento a salto).

^ ^

 

Di base il contatto eroe e tasto diverso da azione ti costringe a tenere sempre la freccia direzionale premuta verso il nemico, non è una gran cosa, per me dovresti iniziare a cambiare da qui, è una scomodità bella grande per un action. Inoltre con quel tipo di codice si tratta di un tenere premuti i due tasti per fare un attacco continuo. Con un aspetta fuori dalla condizione se tasto premuto migliora, ma anche con quelli che tieni dentro, in quel caso vanno bene.

Infine da come hai impostato la cosa il nemico ti colpirà sempre non appena sarai vicino ad esso, non vi è gioco di toccata e fuga. Comunque visto che vuoi fare una cosa stile attacco di mmorpg potrebbe sicuramente starci.

^ ^

si Guardian magari dopo aggiorno il topic di progetto così spostiamo il discorso là, direi che questo topic sulle collisioni l'Arka l'ha risolto, io ci sto lucrando sopra ma non sono per niente contento, perchè ancora non ho sviluppato quella visione d'insieme dei processi probabilmente.. mah vediamo alla prossima, tanto di sicuro gli ostacoli lungo il cammino non mancheranno XD

 

Boh. Non so quale sia il problema.
Prova a creare una mappa nuova con solo il nemico come unico evento e con questo stesso codice (magari non lo sai, ma c'è qualche altro evento che interferisce in qualche modo).

Se continua a non funzionare, mandami una demo anche con solo quella mappa e vedo se trovo il problema

Arka ho risolto spostando l'attacco del nemico su processo parallelo dedicato. E ribadendo lo switch collision OFF con l'attacco del giocatore.

PEr tutto il resto il tuo sistema è impeccabile.

PEr me il topic qua è ok.

[TecnoNinja]

mi son letto tutta la discussione, e devo dire che son parecchio contento di vedere qualcuno impegnato in qualcosa di fatto ad eventi come ai vecchi tempi... con tutti sti script, credevo che gli eventer fossero una specie in via d'estinzione xD

da quel che ho capito, sei riuscito a trovare finalmente il coraggio di buttarti sulle variabili e stai riuscendo a fare ciò che ti eri messo in testa... mi fa molto piacere.

a volte sono così complicati gli eventi, che vien voglia di mollare... tieni duro e continua a provare... ^_^

[GabryHadoken]

Grazie x l incoraggiamento Techno e soprattutto grazie a tutti x il supporto. Mi spiace un po che a intervenire siam sempre pochi