Comando aspetta attesa gestione eventi caso dell' evento parallelo

[GabryHadoken]

Questo screen è stato estrapolato da una mini guida/tutorial segnalatami l'altro ieri da Arka per fare un battle system in tempo reale.

io avevo già eventato di testa mia quello per TRIP TRAP ma comunque ho pensato di dargli uno sguardo e (uso delle variabili a parte) come concetto infatti si somigliano molto, una cosa però non mi torna.. vorrei che analizzaste il testo selezionato e mi deste conferma se anche voi vedete un errore di programmazione come lo vedo io..

http://i63.tinypic.com/20uab0o.png

Edited November 24, 2016 by GabryHadoken

[HROT]

Il contatto dev'esser "con l'evento" altrimenti il mostro non può attaccare di sua iniziativa

(sostanzialmente se il giocatore stesse fermo non riceverebbe danni)

 

Non ho capito bene il problema riguardante la temporizzazione

[Guardian of Irael]

A parte il contatto evento. E' una tecnica poco precisa che comunque sul 2k3 male non funzionava, anzi anche con gli altri tool. Ti dà quell'attesa per l'attacco all'inizio e poi parte con la condizione del tasto o del danno. In effetti non è una gran cosa, ma bene o male ha funzionato sempre. L'ideale sarebbe far partire contemporaneamente eventi di reazione per eroe e nemico disattivandoli con switch a seconda di quale viene prima o mandandoli a segno tutti e due se non si fa in tempo a scappare. Il calcolo di coordinate è sempre più preciso.

Ma è una domanda od un indovinello?? XD Se sai un metodo più comodo facci un tutorial invece di fare qui la domanda! XD

[GabryHadoken]

Il contatto dev'esser "con l'evento" altrimenti il mostro non può attaccare di sua iniziativa

(sostanzialmente se il giocatore stesse fermo non riceverebbe danni)

 

Non ho capito bene il problema riguardante la temporizzazione

esatto

 

A parte il contatto evento. E' una tecnica poco precisa che comunque sul 2k3 male non funzionava, anzi anche con gli altri tool. Ti dà quell'attesa per l'attacco all'inizio e poi parte con la condizione del tasto o del danno. In effetti non è una gran cosa, ma bene o male ha funzionato sempre. L'ideale sarebbe far partire contemporaneamente eventi di reazione per eroe e nemico disattivandoli con switch a seconda di quale viene prima o mandandoli a segno tutti e due se non si fa in tempo a scappare. Il calcolo di coordinate è sempre più preciso.

Ma è una domanda od un indovinello?? XD Se sai un metodo più comodo facci un tutorial invece di fare qui la domanda! XD

èuna domanda conferma

 

ma vi risulta che il comando ASPETTA (ATTESA chiamiamolo pure come vogliamo) che dovrebbe dare il tempo necessario a premere il tasto NON SERVE A NIENTE PERCHè A MENO CHE NON CI SIA UN TRIGGER di tipo PARALLELO GLI INPUT VENGONO IGNORATI? (e non parlo che lo schiacci non succede nulla sul momento e allo scadere del tempo succede, no no, è proprio come che non l'aveste mai premuto!)

[Guardian of Irael]

 

èuna domanda conferma

Ah credevo che avessi una soluzione migliore per la seconda parte e la tenessi segreta! XDXD

 

 

ma vi risulta che il comando ASPETTA (ATTESA chiamiamolo pure come vogliamo) che dovrebbe dare il tempo necessario a premere il tasto NON SERVE A NIENTE PERCHè A MENO CHE NON CI SIA UN TRIGGER di tipo PARALLELO GLI INPUT VENGONO IGNORATI? (e non parlo che lo schiacci non succede nulla sul momento e allo scadere del tempo succede, no no, è proprio come che non l'aveste mai premuto!)

Guarda, più o meno non è tanto sbagliato quel che dici. Mettere un'attesa a quel modo è sempre una bruttissima cosa da fare in programmazione. Però rpg maker pure è brutto e così brutto che spesso queste cose un po' funzionano. Anzi se tu guardi la programmazione di menù e simili con pressione di tasti un'aspetta è sempre consigliato anche di pochi pochi frame perché ti impedisce di considerare più volte il tasto relativo se lo tieni premuto.

^ ^

[HROT]

Durante l'attesa puoi acquisire tasti in ingresso

 

Il controllo del tasto premuto viene fatto solo quando l'evento arriva a quell'istruzione

ovviamente se metti un attesa di 10 secondi e il tasto lo premi E LO RILASCI prima del controllo non funziona

 

In oltre c'è un altra considerazione da fare.. quando tu hai un evento in movimento, quello che vedi muoversi sullo schermo NON è l'evento ma solo la sua grafica

Gli eventi si muovono a scatti casella per casella(poi la grafica raggiunge la casella dell'evento)

Quindi in teoria il contatto dell'evento con l'eroe avviene qualche istante prima che il giocatore abbia modo di vederlo, aggiungere un lieve tempo di reazione non è del tutto sbagliato

[GabryHadoken]

Durante l'attesa puoi acquisire tasti in ingresso

 

Il controllo del tasto premuto viene fatto solo quando l'evento arriva a quell'istruzione

ovviamente se metti un attesa di 10 secondi e il tasto lo premi E LO RILASCI prima del controllo non funziona

 

In oltre c'è un altra considerazione da fare.. quando tu hai un evento in movimento, quello che vedi muoversi sullo schermo NON è l'evento ma solo la sua grafica

Gli eventi si muovono a scatti casella per casella(poi la grafica raggiunge la casella dell'evento)

Quindi in teoria il contatto dell'evento con l'eroe avviene qualche istante prima che il giocatore abbia modo di vederlo, aggiungere un lieve tempo di reazione non è del tutto sbagliato

le considerazioni da fare sarebbero tante!!!!!!!!!! il discorso è tutt'altro che semplice come potrebbe sembrare, quello che hai fatto notare sul contatto evento è vero, il VERO trigger si attiva NON quando ti si piazza nella casella adiacente ma a cavallo della mossa successiva (Che non vediamo visivamente ma dobbiamo immaginare come che ci sia l'opzione "attraversa" attiva e finisca a sovrapporsi con l'eroe), però cè da dire anche che il contatto evento INCLUDE sia il tasto azione che il contatto giocatore come triggers! che significa questo, beh significa tante cose, significa che anche se quell'evento non ti ha ancora toccato ma te lo ritrovi davanti il trigger potrebbe anche essere che tu "ti muovi verso l'evento" in modo da stabilire il contatto giocatore, o che tu in quell'occasione schiacci il tasto azione.

ma non è finita.......... discorso "ATTESA"

 

cit "durante l'attesa puoi acquisire tasti in ingresso"? ma sei sicuro? non so sè fatta male la traduzione ita o se sto prendendo fischi per fiaschi io ^^

comunque lasciando il mouse fermo la descrizione dice questo

 

http://i66.tinypic.com/2lceh3.png

 

 

cmq mettiamo un attimo da parte il discorso tocco evento o tocco giocatore come trigger (tanto ai fini della osservazione che mi accingo a fare poco cambia)

la logica di fondo di mettere un attesa di una frazione di secondo sarebbe quella di dare il tempo alla persona di schiacciare il tasto e quindi all'eroe di attaccare prima di essere attaccato, la sostanza in gameplay si traduce così, un nemico o meglio due o tre ti vengono addosso, devi essere svelto da "intercettarli" e anticiparli con l'attacco prima che loro attacchino te. in teoria non fa una grinza, in pratica è doppiamente una porcata sia perchè l'attesa blocca il gioco togliendo quindi il controllo al giocatore e la cosa è brutta alquanto fosse anche per una frazione di secondo molto più breve, sia perchè come ho già detto salvo che il trigger non sia di tipo parallelo, in tutti gli altri casi il comando input viene bellamente ignorato quindi per farla breve NON SERVE A UN EMERITO a parte il fastidio come detto di trovarsi il giocatore bloccato li a non fare nulla

 

EDIT comunque grazie per il confronto, ho trovato finalmente la risposta al mio dilemma e ce l'avevo sotto il naso mannaggia!!

Edited November 24, 2016 by GabryHadoken

[HROT]

http://tinypic.com/player.php?v=23wjiic%3E&s=9#.WDb3FfnhDcs

Ll'input viene ignorato (infatti il giocatore non si muove) ma viene ugualmente acquisito

 

In oltre in molti giochi durante l'animazione di attacco il personaggio si ferma sul posto

Edited November 24, 2016 by HROT

[Guardian of Irael]

Ne stavamo discutendo anche per MP. Per chiarire una cosa:

- la pressione dei tasti funziona perché gli altri eventi sono in processo, comunque sappiamo che la considera.

- l'evento stesso? Se l'evento stesso fosse il pulsante? E fosse a contatto evento? Funzionerebbe comunque prima o dopo l'attesa? Lo faccio io l'indovinello! XD

^ ^

[GabryHadoken]

@Hrot eventato come? specifica perchè postando così non impara niente nessuno XD

primo perchè il video può essere fatto in milioni di modi/trucchi ^^

secondo perchè anche solo guardando al rallenty si vede che i primi comandi impartiti quando parte l'attesa non sono quelli che fa il personaggio appena finisce l'attesa! quindi a questo punto viene da pensare o li acquisisce tutti o li acquisisce come? a forfait?

 

comunque, anche io ho fatto le mie prove e tante e a me NON funziona così. quindi ci dev essere dell'altro!!

metto un evento come hai fatto te, con trigger tasto azione, appare messaggio "dopo questo messaggio parte un attesa di tot", scompare messaggio parte attesa di "tot"

io nel mentre tocco muovo qua muovo la per un paio di secondi (non esagero a volte non mi scada il tempo e riprenda il controllo)

aspetto lo scadere e il mio PG non si muove.

quindi cè qualcosa di diverso a livello di eventi

puoi postare lo screen di come hai eventato?

 

@Guardian aspetta una cosa alla volta sennò è un casino poi capirsi

Edited November 24, 2016 by GabryHadoken

[arkady18]

Gimmy, non so cosa tu voglia fare esattamente, ma ho il sospetto che ti stia rovinando la vita per niente.

Immagino che per quel video Hrot abbia creato un processo parallelo in cui si faceva qualcosa come:

se premi giù

-switch g on

-switch s off

-switch d off

-switch s off

altrimenti

-se premi su

--switch g off

--switch s on

--switch d off

--switch s off

-altrimenti

--se premi destra

---switch g off

---switch s off

---switch d on

---switch s off

--altrimenti

---se premi sinistra

----switch g off

----switch s off

----switch d off

----switch s on

---altrimenti

-----switch g off

-----switch s off

-----switch d off

-----switch s off

 

E che i vari pulsanti cambino grafica in base allo switch on/off.

 

Ci sono vari modi per fare tutto ciò, ma probabilmente lavorare con i processi paralleli è la soluzione migliore.

Personalmente, abolirei completamente l'idea di usare il contatto evento o la pressione di un tasto, sia per attaccare che per subire danni, e lavorerei solo di processi paralleli.

Edited November 24, 2016 by arkady18

[GabryHadoken]

FUOCO!!!!!!!!!!!!!!!!!! hai centrato il punto e qui torniamo al discorso iniziale della domanda.

nel video di Hrot gli input sono in qualche modo acquisiti perchè cè un qualche processo PARALLELO di mezzo (legato presumibilmente all HUD che riproduce graficamente i tasti premuti) sul quale il comando attesa non ha effetto come altrove.

ma noi dobbiamo eviscerare la meccanica/dinamica del tool riguardo gli eventi quindi approfondiamo ancora, se io parto da zero piazzo un nemico sulla mappa e faccio il lavoro che ha fatto Hrot senza ulteriori accavallamenti di eventi gli input durante il comando attesa vengono sempre recepiti oppure NO?

[Guardian of Irael]

 

@Guardian aspetta una cosa alla volta sennò è un casino poi capirsi

Spiego meglio anche qui.

Non si tratta di altre cose diverse da quelle che si stavano discutendo.

 

HROT ha fatto un evento (il tizio) che azionato od a contatto fa partire un aspetta e ti fa vedere come altri eventi in processo parallelo (i pulsanti rossi) ricevano effettivamente l'input della pressione di un tasto anche durante l'evento attivato.

Il problema di Gabry era che lui aveva il codice nell'evento stesso a contatto o col tasto azione e quindi era lì che bisognava vedere se i pulsanti avevano effetto.

In fondo nessuno ha torto. HROT ha dimostrato che effettivamente anche durante un'attesa l'input viene registrato seppur non considerando il codice di quell'evento a contatto.

Gabry chiedeva di quell'evento a contatto.

Arkady ora ci dice che è sempre meglio un parallelo. E lo è!

Direi che la soluzione c'è per tutti.

Usiamo un evento parallelo per gestire l'input ed in base a quell'evento parallelo attiviamo o no una switch che poi sarà considerata nell'evento a collisione (se proprio si vuol lasciare a collisione), così lì ci sarà la condizione se che si basa sulla switch esterna attivata dall'evento parallelo!

^ ^

[GabryHadoken]

Direi che la soluzione c'è per tutti.

Usiamo un evento parallelo per gestire l'input ed in base a quell'evento parallelo attiviamo o no una switch che poi sarà considerata nell'evento a collisione (se proprio si vuol lasciare a collisione).

^ ^

bravo questo è il segreto del battlesystem a cui sono arrivato a furia di sperimenti quasi per caso diciamo, assegnare un tasto specifico per attaccare con un evento parallelo dedicato. questo da quella marcia in più, un non so che di prioritario nelle meccaniche del tool.

Edited November 24, 2016 by GabryHadoken

[Guardian of Irael]

 

il segreto, assegnare un tasto specifico per attaccare con un evento parallelo dedicato. questo da quella marcia in più, un non so che di prioritario nelle meccaniche del tool.

Detta così non è un segreto! XD Diciamo che a parte gli eventi ad azione per la pressione di un tasto serve per forza un processo parallello. La marcia in più sta nel dove attivare la switch o meglio il codice, cioè in un evento ovviamente esterno all'attesa. Insomma come gestire l'attesa ed il codice che fa partire attacchi di eroi e nemici.

^ ^

[HROT]

@Gabry

I pulsanti li ho messi solo per far vedere cosa stavo premendo (e si sono eventi paralleli) altrimenti avresti guardato un fermo immagine.. all'evento non frega nulla della pressione DURANTE l'attesa
Non perchè i tasti non vengano acquisiti dal programma ma solo perchè l'evento esegue UN ISTRUZIONE ALLA VOLTA

Quindi durante l'attesa, anche se il programma (non l'evento) è in grado di acquisire la pressione dei tasti, l'evento continua ad aspettare
..perchè sta già eseguendo l'istruzione di attesa!
quando questa finisce, fa la verifica sul tasto

 

la verifica sul tasto non implica che il tasto debba essere premuto al di fuori dell'attesa

la verifica sulla pressione controlla solo se in quel dato istante il pulsante è premuto

infatti COME AVEVO GIA' DETTO se durante un attesa molto lunga viene premuto E RILASCIATO il tasto al successivo controllo il tasto non risulterà premuto (perchè in quel dato momento in effetti non è premuto)

..più che "i miei screen" bisognerebbe vedere i tuoi (visto che sei tu ad avere il problema) ma soprattutto dovresti spiegare un pò meglio cosa vorresti fare

[arkady18]

 

nel video di Hrot gli input sono in qualche modo acquisiti perchè cè un qualche processo PARALLELO di mezzo (legato presumibilmente all HUD che riproduce graficamente i tasti premuti) sul quale il comando attesa non ha effetto come altrove.

Non so se ho capito bene il tuo dubbio, ma l'attesa si ripercuote UNICAMENTE sull'evento in cui la metti e su nient'altro. L'unica "eccezione" è che se l'evento si attiva tramite contatto o pressione del tasto invio, l'attesa è valida pure per l'eroe (che si blocca), ma questo è un effetto collaterale perché quando "parli" con un evento l'eroe si blocca a prescindere finché non finisce il codice dell'evento in questione.

 

In ogni caso, se metti l'attesa all'interno di un processo parallelo, il resto del mondo se ne fregherà altamente

[Guardian of Irael]

 

In ogni caso, se metti l'attesa all'interno di un processo parallelo, il resto del mondo se ne fregherà altamente

Però anche se metti l'attesa in un tasto azione od in una collisione il resto del mondo continua senza problemi, solo l'eroe viene bloccato. In pratica resta se scegliere di bloccare l'eroe e far fare attacchi per quei pochi istanti o comunque mettere un parallelo anche per i nemici e quindi fare tutto a coordinate per non bloccare mai nulla.

^ ^

[GabryHadoken]

@Gabry

I pulsanti li ho messi solo per far vedere cosa stavo premendo (e si sono eventi paralleli) altrimenti avresti guardato un fermo immagine.. all'evento non frega nulla della pressione DURANTE l'attesa

Non perchè i tasti non vengano acquisiti dal programma ma solo perchè l'evento esegue UN ISTRUZIONE ALLA VOLTA

 

Quindi durante l'attesa, anche se il programma (non l'evento) è in grado di acquisire la pressione dei tasti, l'evento continua ad aspettare

..perchè sta già eseguendo l'istruzione di attesa!

quando questa finisce, fa la verifica sul tasto

 

la verifica sul tasto non implica che il tasto debba essere premuto al di fuori dell'attesa

la verifica sulla pressione controlla solo se in quel dato istante il pulsante è premuto

 

infatti COME AVEVO GIA' DETTO se durante un attesa molto lunga viene premuto E RILASCIATO il tasto al successivo controllo il tasto non risulterà premuto (perchè in quel dato momento in effetti non è premuto)

 

..più che "i miei screen" bisognerebbe vedere i tuoi (visto che sei tu ad avere il problema) ma soprattutto dovresti spiegare un pò meglio cosa vorresti fare

 

 

NOSSE non tornano i conti (tra l'altro fonte di questi ragionamenti sui tempi istruzioni si può avere qualcosa di ufficiale?)

fa una cosa riprenditi in mano quello che hai provato del video, togli tutti gli eventi paralleli per far vedere cosa premi o non premi, tanto lo provi te e poi mi dirai se quel personaggio a fine attesa si muove oppure non fa una cippa

PS io non ho nulla da screenare perchè sto facendo la domanda! quello da screenare già l ho screenato, sei te che hai tirato fuori il video non io ^^

[HROT]

Hai detto che hai fatto le tue prove e che le cose non funzionano.. vediamole queste prove.. altrimenti di cosa stiamo parlando? hai fatto una domanda e la risposta l'hai già ricevuta, se vuoi metterla in dubbio dovresti portare delle argomentazioni

 

Comunque.. certo che alla fine dell'attesa il personaggio si muove.. il fatto che ci sia un altro evento parallelo non centra nulla

[GabryHadoken]

hai fatto la prova almeno? prima falla (ti costa sicuramente meno a te cancellare gli eventi paralleli e riprovare) che a me girare un video dal cellulare e caricarlo su youtube ^^

[HROT]

Sii ho fatto la prova

..Si muovono sia l'eroe sia l'evento

[GabryHadoken]

Adesso si muove anche l evento? Andiamo bene ^^

Prendi una mappa vuota posiziona il giocatore crea un evento fisso trigger azione, comandi mostramessaggio inizio attesa 10secondi, inserisci aspetta/attesa 600 frames

Provalo e dimmi se quando il PG riprende il controllo alla fine dell attesa fa le capriole oppure no

Edited November 24, 2016 by GabryHadoken

[HROT]

Nel video l'evento era fisso..

Quando hai parlato di "personaggio" senza specificare se fosse l'eroe o il personaggio dell'evento ho dato un movimento casuale anche all'evento (.. solo per scrupolo, tanto non cambia niente)

 

è già cosi l'evento.. l'unica differenza è che nel mio c'è 999 di attesa invece che 600

Cosa intendi con "fa le capriole"?

Quando il tempo di attesa finisce ti ridà il controllo del personaggio e basta.. perchè mai dovrebbe fare le capriole?

 

Comunque non mi pareva che fosse questo il punto considerando che la discussione era partita dal verificare se un attacco era andato in porto o meno

 

Tu esattamente cosa devi fare? cosa ti aspetti che faccia il personaggio durante e dopo l'attesa?

[GabryHadoken]

tagliamo corto perchè il topic vuole essere a scopo costruttivo e non confusionistico

la domanda iniziale voleva essere propedeutica (il discorso del BS è servito solo da pretesto) per portare a eviscerare la meccanica del tool circa il comando aspetta/attendi (che dir si voglia) e la gestione degli eventi, lasciamo perdere i battlesystem le capriole e gli esperimenti con eventi accavallati, torniamo all'abc, il tool e il suo funzionamento base in condizioni di default

http://i66.tinypic.com/2lceh3.png

la descrizione del comando qui che dice? o vogliamo ignorarla e dare retta a voci che non hanno fonte ufficiale di provenienza? perlomeno io te le ho chieste ma non me ne son state fornite manco di striscio! se poi uno parla perchè c'ha la bocca allora diventa una Babilonia ^^

https://www.youtube.com/watch?v=MqsMS3X11Hw

toh guarda il mio evento non fa le capriole e il mio eroe nemmeno si gratta.

ora cosa ho sbagliato? che dovevo muovere da prima o dovevo finire di muovere dopo? andiamo su... guarda che ho fatto anche quelle prove in tutte le salse.. anche cambiando i comandi eventi da primi a ultimi per vedere se c'era un qualche discorso di priorità in esecuzione..

PS mi scuso per la qualità del video ma da bandicam ovviamente non faceva perchè non potevo inquadrare mentre muovevo il controller

Edited November 24, 2016 by GabryHadoken

[arkady18]

 

Non so se ho capito bene il tuo dubbio, ma l'attesa si ripercuote UNICAMENTE sull'evento in cui la metti e su nient'altro. L'unica "eccezione" è che se l'evento si attiva tramite contatto o pressione del tasto invio, l'attesa è valida pure per l'eroe (che si blocca), ma questo è un effetto collaterale perché quando "parli" con un evento l'eroe si blocca a prescindere finché non finisce il codice dell'evento in questione.

 

In ogni caso, se metti l'attesa all'interno di un processo parallelo, il resto del mondo se ne fregherà altamente

Mi cito. Ed è esattamente quello che dice il programma.