-
Posts
112 -
Joined
-
Last visited
Content Type
Profiles
Forums
Calendar
Everything posted by JackX
-
[RM2000]DestinyDLL - Patch Multi-Funzione + Linguaggio Scripting
JackX replied to JackX's question in Supporto 2K/2K3
Neanche a farlo apposta, come avrai visto ogni volta sceglievo l'opzione casuale e quindi i valori venivano impostati di conseguenza :F No, non è legge assoluta. Semplicemente volevo utilizzare solo i caratteri maiuscoli per questo esempio( come puoi vedere dall'immagine che ho utilizzato ), e per praticità la stringa passata viene trasformata, col comando apposito di DestinyDLL, ponendo tutti i caratteri maiuscoli. La pipetta invece secondo me è un tocco di classe xD ( tieni conto che gli unici comandi di DestinyDLL per disegnare sono il cambio di colore di un singolo pixel, i rettangoli e le linee rette ). Chiaramente lì appaiono due difetti evidenti sulla pipetta: 1) non segue esattamente il box messaggi se questo viene mosso velocemente; 2) essendo separato dal box messaggi e avendo anche se ha la stessa trasparenza, trovandosi sovrapposti, si nota quel sgradevole effetto appunto di sovrapposizione di due parti distinte trasparenti; Tolti questi due casi, secondo me è la pipetta ci sta bene. Comunque è la prima cosa che faccio con DestinyDLL, quindi l'ho scritto tutto di fila in modo disordinato, ora probabilmente se lo dovessi rifare lo farei in modo da non presentare quei due difetti( che stanno vero la base del metodo utilizzato ). PS: ispiratomi da solo dalla riuscita della pipetta, è probabile che tenterò ad ottenere qualche solido 3D semplice xD EDIT: tra l'altro, la variabile per il testo casuale, ho imposto che assuma ogni volta un valore casuale tra 0 e 4 (compresi gli estremi), infatti nel video una volta capita il valore 0, una volta il valore 4 e un'altra volta il valore 2, e per 0 e 4 segnala che il testo non è stato trovato ( infatti come si può vedere dal txt, ci sono solo i testi numero 1,2 e 3 ). -
[RM2000]DestinyDLL - Patch Multi-Funzione + Linguaggio Scripting
JackX replied to JackX's question in Supporto 2K/2K3
Breve video per una piccola tech demo con le seguenti features: ° Lettura di una stringa di testo direttamente da un file di testo particolarmente formattato( in questo caso contenuto nella cartella che ho chiamato "Testi", all'interno della cartella del progetto ), infatti basta impostare una variabile per ottenere una determinata parte di testo; il file di testo è formattato nel seguente modo: Il contenuto del testo utilizzato è esattamente il seguente: ° Box Messaggi completamente dinamico[ dimensioni, posizione, colore sfondo, spessore bordo, colore bordo, colore testo, distanza fra le lettere, distanza fra le righe, velocità scorrimento testo, trasparenza generale ]; inoltre per chiudersi aspetta la pressione del tasto Invio( mostrando una semplice iconcina lampeggiante in basso al centro ); infine, il testo che comparirebbe al di fuori del box messaggi, non viene proprio stampato; ° Il testo in questione, può essere preso ad esempio tramite il primo metodo. La particolarità è che vengono riconosciuti i caratteri di una data stringa, convertiti in formato ASCII(prima però vengono resi tutti maiuscoli) e stampati a video tramite questa immagine(l'ho presa dal sito dafont.com e adattata allo scopo): http://ultrasonic.altervista.org/_altervista_ht/destinydll/bitmapfordestiny.png (la seconda serie di caratteri alfabetici non viene utilizzata nella tech demo); inoltre riconosce il carattere speciale LF(linefeed) per andare a capo; infine, i caratteri che non conosce( cioé che non ho inserito nel codice ), vengono saltati; ° Puntatore del mouse tramite picture(che ho preso dal progetto d'esempio di destinydll)[ pulsante sinistro: sposta box messaggi(se gli è sopra); pulsante centrale: disegna 1 pixel rosso ]; ° Se l'Eroe si trova sopra o sotto rispetto al box messaggi, comparirà la "pipetta"(credo si chiami così xD) del box messaggi stesso, che punterà dritto verso la posizione in cui si trova l'Eroe; Alla fine del video viene mostrato questo carattere(3 volte): http://ultrasonic.altervista.org/_altervista_ht/destinydll/specialcharfordestiny.png al quale viene cambiato il colore del bordo a rotazione, scorrendo l'intera palette dell'immagine stessa. VIDEO: http://www.youtube.com/watch?v=1wkylyD8mWI PS: è superfluo dire che l'ho realizzato tutto utilizzando DestinyDll, vero? xD -
Agli utenti servirebbe proprio provarlo xD ( è sempre il modo migliore per capire e se non hanno il tempo per provarlo, allora di certo non lo hanno neanche per inserire centinaia di righe su rpg maker e quindi questo programma gli servirebbe a maggior ragione ). Comunque ho inserito nel primo post del topic quello che avevo scritto nel mio post precedente.
-
Sì, è come dice Flame. Un esempio al volo( tralasciando il fatto che possa essere assurdo o no xD ): Hai 50 mostri nel tuo bestiario( ordinati in un certo modo, chessò, il primo è quello che l'eroe ha incontrato per primo e così via ) e vuoi registrare gli HP ed MP di ognuno nelle variabili di RPG Maker, per cui diciamo che userai dalla prima alla centesima variabile di RPG Maker. Facciamo che l'ordine sia var1 = HP mostro1, var2 = MP mostro1, var3 = HP mostro2, etc etc. Quindi su RPG Maker scrivi due "Cambia Variabile" dove imposti la variabile 1 al valore degli HP del primo mostro, e la variabile 2 al valore degli MP del primo mostro. Ora per semplicità, facciamo che gli HP e gli MP di ogni mostro successivo sono il triplo rispetto a quelli del mostro precedente, tenendo conto che il primo mostro ha rispettivamente 8 HP e 5 MP. Poi seleziona entrambe le righe, premi il pulsante destro del mouse e clicca su "Copia". A questo punto utilizzi il programma e premi sul tasto "Read event data from clipboard" e apparirà nello spazio apposito in basso, ciò che avevi copiato da RPG Maker. Nella parte centrale, ci sono i valori da rimpiazzare con delle formule. Per cui metteremo i valori "1" e "2" da rimpiazzare con le formule "1+i*2" e "2+i*2" e i valori "8" e "5" da rimpiazzare con le formule "8*(3^i)" e "5*(3^i)".*** In basso a sinistra, sotto General, c'è il counter(contatore), in cui imposteremo il valore di partenza a 0 e il valore finale a 49. ### Quando poi farai partire la creazione del codice, lui scorrerà il contatore(è una cosa pressocché istantanea, anche se il tempo può dipendere dalla richiesta e dall'hardware ) da 0 a 49, e ogni volta aggiungerà due righe in più, in cui i valori "1" e "2" e "8" e "5" del codice di base, saranno rimpiazzati dalle rispettive formule soprascritte, con "i" che assume ogni volta il valore del contatore. Il risultato a questo punto dovrebbe essere chiaro... la creazione di algoritmi è decisamente più stimolante del ripetitivo inserimento di codice di RPG Maker( almeno secondo me ). Comunque l'ultimo passaggio consiste nel premere in basso a destra su "Copy to clipboard", tornare su RPG Maker, e premere sul pulsante destro del mouse e successivamente su Incolla. ***( i valori da rimpiazzare sono "1" e "2" perché sono l'indice delle variabili che abbiamo copiato da RPG Maker e le formule, se non sono ancora chiare lo saranno dopo; idem per gli altri due valori ) ###( da [1+0*2=1] a [1+49*2=99]; da [2+0*2=2] a [2+49*2=100]; idem per quelle degli hp ed mp) PS: scusami se per caso non sono stato chiaro, ma ho un po' di fretta :E EDIT: probabilmente sei stato ingannato dall'immagine, ma quello era solo un esempio in cui vengono utilizzate delle formule un po' più avanzate, visto che fa appello a delle specifiche funzioni matematiche messe a disposizione dal programma. Lì poi ci sarebbe da discutere sul fatto che il programma stesso utilizzerà una certa precisione di calcolo, per cui poi basterà moltiplicare per 10^n ( scelto n in base appunto a tale precisione di calcolo ), proprio come si vede là nello screen.
-
Permette di risparmiare decisamente un sacco di tempo ( e preservare anche la vista xD ) se si impara ad usarlo ( è abbastanza semplice dopotutto ). Una possibilità molto interessante è quella di prendere dei valori da file CSV, che puoi gestire anche da excel, col quale si sa, si possono creare formule dinamiche di una certa complessità e riempire moltissime righe/colonne in base a quelle.
-
Per chi già non lo conoscesse, volevo porre l'attenzione sul programma creato da Cherry( nel cui sito ci sono anche altri programmi ): RMEventFactory - http://cherrytree.at/cms/download/11 http://cherrytree.at/cms/wp-content/uploads/eventfactory_screen.png Esempio( per cosa possa essere utilizzato ): Nota di Cherry: [!!!]Per ottenere il massimo da questo programma è vivamente consigliato leggersi il manuale d'utilizzo incluso( è in inglese, forse un giorno verrà tradotto in italiano ).
-
[RM2003]Tutorial Percentuale Esperienza(dal Database)
JackX replied to JackX's topic in Guide alla Programmazione
E così sia! ( non ero sicuro volessi essere citato in causa xD ) (ho aggiornato) -
Qualche mese fa MasterSion( senza il quale ora il tutorial non esisterebbe!! xD ) mi chiese in chat come fare ad ottenere la percentuale di ESPERIENZA per arrivare al livello successivo. Però non da una semplice variabile, bensì dall'ESPERIENZA che mette a disposizione il database di RPG Maker 2003( con relativo andamento ): http://ultrasonic.altervista.org/_altervista_ht/tutorial/ce1.png http://ultrasonic.altervista.org/_altervista_ht/tutorial/ce2.png RPG Maker non permette di base di ottenere valori come "esperienza rimanente al livello successivo", "esperienza di livello" etc etc. Per cui dovremo impostare alcune variabile a seconda di come abbiamo sistemato dei particolari valori nel database: 1) Modello 2) Aggiunta 3) Correzione 4) Livello Massimo( o "Max. Livello" insomma ) 5) Livello Attuale 6) Esperienza Attuale Le prime 4 saranno da impostare manualmente( in base all'eroe di cui vogliamo conoscere la percentuale ), le ultime due invece saranno più semplici perché basterà solo scegliere il nome dell'Eroe ( se non fosse chiaro ora, lo sarà molto di più nella seguente demo commentata ). Non ho di proposito commentato la parte dell'"algoritmo" perché di fatto non a tutti potrebbe interessare, per cui spiego qui più o meno come funziona la curva d'esperienza di RPG Maker( che oltretutto è molto semplice ): DEMO: Tutorial Percentuale Esperienza
-
[RM2000]DestinyDLL - Patch Multi-Funzione + Linguaggio Scripting
JackX replied to JackX's question in Supporto 2K/2K3
In effetti anche solo provare la demo richiede le RTP inglesi... a breve rifaccio l'upload con tutte le risorse necessarie o al più aggiungo un link per il download delle RTP inglesi( o più semplicemente aggiungo alla demo solo le risorse che le altre RTP non hanno ). Dovrebbe valere lo stesso discorso fatto per la Value. -
Starry in questo periodo è estremamente occupato, per cui appena potrà si farà vivo! Complimenti a tutti per il contest( da chi lo ha ideato a chi vi ha partecipato ) e complimenti a Flame per le targhette, così animate rendono molto bene!
-
[RM2000]DestinyDLL - Patch Multi-Funzione + Linguaggio Scripting
JackX replied to JackX's question in Supporto 2K/2K3
Non sono iscritto alla newsletter, però da come si può vedere qua: http://www.bananen-joe.de/DestinyDLL/?Page...&Language=1 l'ultimo aggiornamento risale al 2 Novembre 2010, e come si può sempre vedere, si è organizzato il lavoro per bene. Altro non saprei visto che a parte per la richiesta di permesso per la traduzione della patch, non siamo rimasti in contatto. Anch'io ho la versione Value e non dovrebbero esserci problemi perché comunque DestinyPatcher non crea un file RPG_RT.exe da zero, bensì va a modificare quello che tu gli indichi in alcune sue parti(se poi l'unica modifica che applichi è quella di utilizzare DestinyDLL, allora le probabilità di errori futuri da essa causata sono proprio poche, a meno che non si tratti di bug gravi che a quel punto lui stesso immagino risolverebbe subito ). Alcune modifiche che White Dragon ha apportato a RPG Maker per fare la versione Value, è possibile replicarle subito sugli exe puliti tramite resource hacker e editor esadecimale, agendo quindi sia sul programma che sul file RPG_RT.exe ( ad esempio, voglio aumentare il numero massimo dell'indice delle picture, allora apro rpg maker con resource hacker, trovo la finestra apposita e modifico; se non dovesse risultare completamente funzionante, vuol dire che c'è qualcosa da modificare anche sul file RPG_RT.exe ). -
[RM2000]DestinyDLL - Patch Multi-Funzione + Linguaggio Scripting
JackX replied to JackX's question in Supporto 2K/2K3
Le due ottime guide( una per il programma con cui applichi le modifiche al tuo RPG_RT.exe e l'altra proprio per il linguaggio di scripting ) sono assolutamente esaurienti( mi pare che l'autore abbia sudato più per fare le guide che per creare la patch xD ) per cui, a parte cose che richiedono maggiori conoscenze, come il sistema server/client( ma è solo leggermente complesso perché composto da una serie di fasi invece che da un singolo comando che fa tutto ), il resto è molto semplice e immediato. Un esempio al volo: Questa riga( il simbolo $ permette di riconoscere ciò che segue come uno script e non un normale Commento ) memorizza nella variabile numero 1 di RPG Maker proprio( perché poi ci sono pure le variabili proprie di DestinyDLL ) un valore particolare in base allo stato di pressione del tasto "Freccia Giù" ( del tipo, è uguale a 0 se non è premuto, assume il valore 1 se viene premuto ). Quindi poi ti basta mettere una condizione IF di RPG Maker per controllare il valore della variabile. In questo caso appunto c'è VK_DOWN( Freccia Giù appunto ), ma come si può vedere dalla lista all'interno della guida, c'è praticamente l'intera tastiera xD E quella riga l'ho proprio copia-incollata dalla guida stessa, visto che per ogni comando fa subito un esempio. Poi ovviamente la demo all'interno saprà decisamente stupirvi Di base è pensato solo per RPG Maker 2000. Bisognerebbe fare delle prove per vedere quanto può essere compatibile con RPG Maker 2003( tempo fa stavo iniziando, poi non ho più avuto occasione >_> ). Io pensavo di passare a RPG Maker 2003 per alcuni vantaggi come la possibilità di avere più tasti e altre cosettine, però questa patch mi ha fatto ripensare xD ( ne ho provate una decina prima di questa, e devo dire che è quella in cui mi sono trovato assolutamente meglio e che presenta il maggior numero di funzionalità aggiuntive ). Sarò sincero comunque, non ho avuto modo di provarla a fondo, ma le potenzialità sono incredibili e l'autore è davvero molto serio e continua a lavorarci tutt'ora per migliorarlo. In compenso, per il tempo che l'ho provato, non ho avuto nessuna sorpresa negativa, anzi... PS: ho corretto il link, grazie( dovrò comunque rifarlo da capo quel post, è un casino da leggere così xD ) EDIT: @domyssj: probabilmente alcune le ha aggiunte solo per completezza... di fatto poi, molti che creano giochi con rpg maker non credo sappiano cosa sia il seno iperbolico e molto probabilmente non gli servirà saperlo in questo caso... però come si suol dire: "melius abundare quam deficere", anche se non lo usi( sì insomma, sono d'accordo con te xD ) -
[RM2000]DestinyDLL - Patch Multi-Funzione + Linguaggio Scripting
JackX replied to JackX's question in Supporto 2K/2K3
POST RISERVATO PER FUTURI AGGIORNAMENTI/GUIDE GUIDA: come aumentare le dimensioni della finestra per l'inserimento dei commenti. TECH DEMO 1: -
[RM2000]DestinyDLL - Patch Multi-Funzione + Linguaggio Scripting
JackX posted a question in Supporto 2K/2K3
Come da titolo, si tratta di una Patch abbastanza particolare, poiché si articola in due particolari operazioni: 1) Applicare( tramite programma apposito ) svariate modifiche( dal salto della schermata iniziale alla configurazione dei singoli tasti, etc etc ) al file RPG_RT.exe del vostro progetto; 2) Se nel punto precedente, tra le varie possibilità di modifica, è stata scelta anche quella di abilitare l'uso della dll "Destiny", allora si potranno usufruire di molte funzioni prima di adesso impossibili( calcoli in virgola mobile, tagliare parti di immagini, ottenere informazioni da un sito php, etc etc ) inserendo opportune parti di testo all'interno dei Commenti di RPG Maker ( vi è insomma proprio un linguaggio di scripting accessibile tramite i Commenti, con tanto di visualizzatore di errori nel caso ce ne fossero durante il gioco ). E' tutto estremamente semplice e intuitivo il processo di attivazione delle modifiche, un po' meno il linguaggio di scripting( ma solo per chi non ha mai avuto niente a che fare coi linguaggi di programmazione; comunque la guida è realizzata così minuziosamente da fugare quasi, se non tutti, i dubbi relativamente al linguaggio di scripting di DestinyDLL ). Per cui, non mi dilungo oltre e vi lascio ad un pacchetto che ho realizzato con la parte di traduzione che ho fatto( anche se molto in fretta e ancora incompleta riguardo il file help per il linguaggio di scripting, appena avrò tempo sarà conclusa e rivisionata a dovere ), dove è presente anche l'ultimo aggiornamento della DLL. Comunque ho tenuto in una cartella a parte, anche tutti i file originali che vengono installati con l'Installer presente nel sito dell'autore tedesco(presumo), Bananen-Joe(dal quale ho ricevuto l'autorizzazione per la traduzione), a cui va riconosciuto il grandissimo merito di aver creato questa incredibile patch: http://www.bananen-joe.de/DestinyDLL/ Inoltre là potrete vedere i vari aggiornamenti e anche un altro progetto d'esempio. Download Pacchetto: DestinyDLL TRADUZIONE ( contiene il progetto d'esempio tradotto, la guida all'utilizzo della patch e il programma stesso tradotti e metà traduzione della guida al codice di programmazione di DestinyDLL ) VIDEO DIMOSTRATIVO DI UNA CONNESSIONE CLIENT/SERVER(in locale poiché l'ho fatto da solo): http://ultrasonic.altervista.org/_altervis...ient-server.zip (occupa molto perché non sono stati utilizzati codec per la compressione, appena posso lo carico per bene su youtube ) PS: appena posso sistemo meglio pure questo post >_> -
Beh, oltre a quelle già stanno nel primo post del topic( Vita, Mana, Potere, Difesa, Demone ), ci sarebbero la scissione di Potere in Attacco Fisico e Attacco Magico, così come la Difesa in Difesa Fisica e Difesa Magica. Ci sono anche Attacco Elementale e Difesa Elementale ( queste però sono caratteristiche che dipendono dall'equipaggiamento ). Precisione, Evasione e Fortuna sono tra le ultime entrate( ovviamente ne ho omessa qualcuna xD ). Così sembra quasi un ragionamento "commerciale" xD Infatti nel loro caso lo scopo è quello di creare quanta più attenzione e apprezzamento possibile attorno il loro gioco, la cui data di uscita la maggior parte delle volte è abbastanza chiara ( almeno come periodo, infatti non è che possono tirarla molto per le lunghe... a parte qualche caso recente che è a dir poco assurdo ). Giustamente, devono guadagnarsi da vivere, per cui ci vuole una buona pubblicità e un certo rigore nel rispettare le consegne. Per noi che lo facciamo senza scopo di lucro, è diverso... è un po' come dire: loro creano videogiochi per vivere, noi viviamo per creare videogiochi. Io creo un videogioco perché mi piace farlo, per pura soddisfazione personale. Per me il fatto che poi è destinato ad un pubblico diverso da me stesso, è un motivo in più, non quello principale. Percentuale di caricamento? Oddio... non saprei proprio... è difficile da dire perché non è che ogni mappa si fa tutto ( dialoghi, eventi interattivi, bs, etc etc ); molte cose vengono fatte per livelli e altre in contemporanea separatamente, per unire il tutto dopo( in questo modo entrambi possiamo continuare la nostra parte senza intralciarci ). Ma soprattutto, da non molto sono finite le fasi di "sperimentazione" e si è passati ad una serie di scelte più decise ( un po' come accadde per la Trama, che non venne scritta subito e nonostante ciò si continuava a lavorare; ma una volta scritta tutta, anche se in parte a grandi linee, molte cose che frullavano disordinatamente nella testa di Starry sono state meglio definite, permettendo così di avanzare più rapidamente e coerentemente seguendo uno schema già stabilito ). In sostanza, se ci si dedica fermamente nella fase di progettazione, il resto viene fuori meglio e più velocemente. Concludo ripetendo che non so quindi dare una percentuale, anche perché avrebbe poco senso visto che uno può impiegare tanto in un primo 50% e poco in un secondo 50%.
-
Grazie, e contraccambio subito perché a quanto passione e serietà penso che tu non sia da meno ^^ ( sarà la volta buona che esce un gioco di Dragon Ball sufficientemente completo a livello di storia e con tante modalità di gioco differenti e non standard? senza considerare poi che con l'impegno che ci metti riuscirai a migliorarti di continuo ) Da sempre l'idea è quella di rilasciare solo ed esclusivamente il gioco completo e non penso proprio ci saranno rimpensamenti in proposito( se c'era qualcosa comunque, sarebbe stato postato nel primo post, non costringerei mai nessuno a doversi leggere tutto sto topic per trovare un'informazione così importante xD ). Uno dei motivi principali è che non ha tanto senso rilasciare una demo quando poi un mese dopo, quella demo, con tutta probabilità sarebbe obsoleta( giusto per farti un esempio, nel primo post le caratteristiche dei personaggi sono 5: Vita, Mana, Potere, Difesa, Demone... ora sono 15 e c'è voluto meno di un mese per farlo triplicare xD ).
-
Ah ok, così è diverso, ed è una delle varianti dell'usare proprio le Picture come grafica ( o ti fai tutti i comandi manualmente, o tieni dietro l'Eroe in trasparenza ), altrimenti diventava come il secondo topic che ho segnalato nel mio post precedente... Già, la soluzione migliore è sempre in base alle necessità: °se tengo l'Eroe visibile e un pezzo lo faccio a Picture, ho il vantaggio che la parte dell'Eroe può essere nascosta normalmente da altri Eventi che si trovano davanti a lui( senza dover fare anche questi a Picture ) ma bisogna lavorarci su per ottenere una animazione sincrona; °se tengo l'Eroe inivisibile e uso la Picture per rappresentarlo completamente, allora non ho problemi di animazione asincrona ma poi devo necessariamente mettere delle Picture per tutti gli oggetti che stanno davanti all'Eroe e bisognerebbe poi farle sparire quando è l'Eroe a trovarsi davanti ( e quindi qualche controllo anche qui ci vuole ); Volendo se ne trovano pure altri di vantaggi/svantaggi :E Quindi bisogna decidere cosa si può sacrificare e cosa no, in base al gameplay etc. Sicuramente, prima bisogna essersi fatti le ossa con tanta altra roba.
-
La prossima volta prova a cercare qualcosa sul forum prima ^^ http://www.rpg2s.net/forum/index.php?showtopic=9382 http://www.rpg2s.net/forum/index.php?showtopic=10838 ( questa era proprio in cima nella sezione dove hai postato tu xD ) Comunque ti conviene rinunciare in questo senso e fare come ti è già stato detto, altrimenti dovresti crearti un sistema dove utilizzi Picture + Evento( o ancora meglio solo Picture, come già accennato da Impaled Janus, che comunque risulta molto più facile e con risultati migliori rispetto a Picture + Evento, ma poi devi ricrearti una serie di funzioni come per il caso Evento + Evento ) per poter fare ciò che chiedi. La soluzione Evento + Evento non è delle migliori, basta provare per vedere che il risultato è praticamente il peggiore ( in particolare se vuoi mantenere l'utilizzo dell'Eroe, altrimenti se vuoi controllare un altro Evento tramite rilevamento della pressione dei tasti, il discorso dovrebbe cambiare, però poi dovrai sostituire diverse funzioni già presenti di base per l'Eroe ). VAL non usa più charset( sempre che tu intenda più Eventi con grafica Charset ), non fare disinformazione ù__u ( xD ) ( non avrebbe tale risultato, infatti lui continua ad usare l'Eroe, e non una coppia di Eventi, tantomeno Eroe+Evento perché altrimenti, come già detto, si vedrebbe malissimo ).
-
Chara a picture, problema visualizzazione frame
JackX replied to Darkel's question in Supporto 2K/2K3
Anticipo che, data l'ora, potrei scrivere assurdità varie e risultare incompresibile( più del solito sì :°D ). Quindi se serve qualche chiarimento perché ho scritto come un cane dimmelo pure xD Lo so che è stato postato più di un mese fa, ma mi sembrava interessante comunque scriverci qualcosina sopra :E Diciamo che il Muovi Picture puoi pure scordaterlo xD Hai bisogno di un controllo molto maggiore sulla posizione dell'immagine e il Muovi Picture non fa al tuo caso. Quando il giocatore muove l'Eroe entro un determinato spazio della Mappa, questo risulta essere sempre al centro della "telecamera"( la porzione di Mappa visualizzabile all'interno della finestra ). Se volessimo piazzare un'Immagine nella stessa casella del giocatore, memorizzeremmo in due variabili le rispettive coordinate [ Mappa X, Mappa Y ] dell'Eroe ( altrimenti otterremmo il numero della casella ). Mettiamo di essere in una mappa grande e lontano dai bordi, così facendo l'Immagine verrebbe piazzata SEMPRE alle coordinate [152,128]( il centro della telecamera appunto ): le coordinate che assegnamo ad una Immagine sono sempre relative ai bordi ( sinistro e superiore ) della telecamera e non alla casella della Mappa ( altrimenti sarebbero assolute ). Quando l'Eroe si trova agli estremi della Mappa, allora la telecamera è costretta a fermarsi ad un certo punto, e l'Eroe si sposterà dal suo centro, variando le sue coordinate da [0,0] ( sinistra-su ) a [312,240] ( destra-giù ). Proprio nei casi in cui l'Eroe non si trova più al centro della Mappa le coordinate restituite [ Mappa X, Mappa Y ] della posizione dell'Eroe, andranno aggiustate di 1 pixel( sono 4 casi, più o meno di 152 e più o meno di 128 ). Dunque, utilizzando un Processo Parallelo, si memorizzano le coordinate [ Mappa X, Mappa Y ] dell'Eroe così da utilizzarle per il "Mostra Figura". In questo modo l'Immagine si troverà sempre nella casella dell'Eroe( prima del "Mostra Figura" bisognerà un attimo aggiustare i valori delle due variabili o altrimenti modificare correttamente l'Immagine, visto che il suo centro si troverà ai piedi dell'Eroe ). Questa è la base, poi se ci aggiungiamo delle condizioni controllando i valori delle coordinate [ Mappa X, Mappa Y ] dell'Eroe ( per capire se si trova o no al centro della telecamera ) potremo fare gli ultimi aggiustamenti. Una volta verificato che in questo modo l'Immagine sia sempre nello stesso punto rispetto alla posizione dell'Eroe ci si può preoccupare del problema finale. La grafica durante la camminata varia, e può variare anche la parte che interessava centrare con l'Immagine. Per cui bisognerebbe applicare un "Mostra Figura" ( modificando opportunamente le variabili che gli vengono passate ) ogni volta che cambia la grafica. Per ora valutiamo solo la camminata verso una direzione e poniamo per ipotesi che l'Eroe si alza di 1 pixel durante i 2 frame sinistro/destro ( rispetto a quello centrale ). Nel Processo Parallelo vanno messi quindi due "Mostra Figura", le cui variabili passate differiranno di 1 pixel ( per l'ipotesi fatta prima ). Più concretamente: 1) creiamo un Processo Parallelo per verificare la pressione dei tasti direzionali e se ciò avviene, si pone ON uno switch particolare ( chiamiamola "Ciclo Camminata" ). 2) creiamo un altro Processo Parallelo e all'interno iniziamo mettendo una condizione IF la quale è verificata se lo switch "Ciclo Camminata" è ON ( va messo fra le istruzioni e non selezionando a sinistra come condizione di attivazione che la switch sia ON, in tal modo le istruzioni all'interno della condizione IF vengono eseguite fino alla fine anche nel caso in cui nel mentre sia stata posta ad OFF tale switch ). All'interno della condizione IF: °Bisognerà mettere le 2 variabili in cui memorizzare le coordinate [ Mappa X, Mappa Y ] dell'Eroe ( chiamiamole Eroe_Pics-X e Eroe_Pics-Y ) °Subito dopo bisognerà modificarne i valori per aggiustarle in base a dove si deve trovare quando l'Eroe ha come grafica il frame sinistro( ricordo che la camminata inizia col frame sinistro, durante il quale l'Eroe sta compiendo un passo in avanti; arrivato circa a metà della casella designata, ritorna al frame centrale; se si prosegue con la camminata, allora questa volta durante il passo successivo ci sarà il frame destro e circa a metà quello centrale, per poi ripartire col frame sinistro ). °Ora ci vuole il "Mostra Figura" ( mettiamo che sia la Figura n°1 con coordinate, ovviamente, le due variabili Eroe_Pics-X e Eroe_Pics-Y ). °Successivamente bisogna mettere un "Aspetta" perché passano dei decimi di secondo tra uno dei due frame( sinistra o destra ) e quello centrale. Ma quanti esattamente? Beh, questo dato è ricavabile solamente sperimentando valori crescenti ( partendo da un singolo Aspetta 0.0 Sec). L'amara sorpresa sarà di non poter trovare un valore perfetto in questi termini, perché non c'è combinazione di "Aspetta" che possa esprimere precisamente il lasso di tempo tra un frame e l'altro, soprattutto tenendo conto che tutte queste esecuzioni verranno eseguite con qualche ritardo perché deve essere attivata uno switch tramite controllo tasti, e anche questo non è precisissimo in termini di tempistiche. °Se per assurdo trovassimo una combinazione di "Aspetta" in grado di esprimere perfettamente( dal punto di vista visivo ) quel lasso di tempo, allora possiamo andare avanti reimpostando le variabili Eroe_Pics-X e Eroe_Pics-Y ( visto che le abbiamo dovute modificare per il primo "Mostra Figura" ) e dopo le dovute modifiche per fare in modo che l'Immagine si trovi dove vogliamo quando c'è il frame centrale( visto che ora siamo a metà casella circa, dal frame sinistro siamo passati a quello centrale ), mettiamo il secondo "Mostra Figura" ( sempre Figura n°1 e coordinate Eroe_Pics-X e Eroe_Pics-Y ). °E' necessario nuovamente sperimentare con gli "Aspetta" per capire il lasso di tempo fra il frame centrale e quello successivo quando si ripartirà per una nuova casella una volta raggiunta questa. Come già detto prima, non lo si troverà e l'Immagine sarà sempre fuori tempo rispetto al resto della grafica dell'Eroe. Peccato perché il sistema funzionerebbe benissimo per una camminata in cui la parte desiderata non cambia posizione ( ad esempio se il personaggio che vogliamo è troppo alto e la testa non va su e giù durante la camminata ma fosse sempre alla stessa altezza, si potrebbe tranquillamente usare un'Immagine per il restante pezzo della testa senza il problema degli "Aspetta", bastarebbe solo un "Mostra Figura" per sempre ). Ma vogliamo comunque andare oltre! E allora invece che usare degli "Aspetta", usiamo dei "Cicli" al cui interno mettiamo 2 cose: °una variabile ( che chiamerò "Valore Ciclo" ) che aumenta di 1 ad ogni ciclo; °una condizione che è verificata quando "Valore Ciclo" è uguale ad un valore particolare; all'interno della condizione poniamo "Valore Ciclo" uguale a 0 e mettiamo l'istruzione "Interrompi Ciclo". Ebbene sì, il Ciclo si ripete molte volte in più rispetto ad un semplice Processo Parallelo e ci permette quindi ( oltre ad poter occupare una piccola parte nell'intero Processo Parallelo, poiché è un'istruzione ) di controllare in quale istante riprendere la normale esecuzione delle istruzioni, con una precisione molto più elevata. Anche in questo caso però il valore esatto in cui interrompere il Ciclo ( il suo numero di ripetizioni quindi ) è da trovare sperimentalmente. Una volta fatto per il tempo fra uno dei 2 frame e quello centrale, dobbiamo anche farlo per quello tra il frame centrale e uno dei 2 frame ( cioé dopo il secondo "Mostra Figura" ). Bene, arrivati fin qui, sorgerà il nuovo problema: se si è riusciti a trovare un valore abbastanza accettabile( ora non ricordo se a questo punto si poteva trovare un valore quasi perfetto, visto che rimane il problema della velocità del rilevamento della pressione dei tasti, che si traduce in un ritardo nell'iniziare il ciclo di "Mostra Figura" rendendo quasi inutile l'aver trovato l'effettivo lasso di tempo fra i vari frame ), ci si accorgerà ben presto che il sistema della pressione dei tasti così com'è ora non va bene perché quando si collide qualcosa, ci si ferma ma il ciclo di "Mostra Figura" continua se si tiene premuto il tasto... Allora bisogna decidere se far cambiare sempre la grafica all'Eroe, anche quando non si sta muovendo( durante collisione e pressione continua del tasto ) oppure se controllare la posizione dell'Eroe e in base a quella capire quando si sta muovendo così da poter avviare il ciclo di "Mostra Figura"( si potrebbe sostituire alla pressione dei tasti, oppure farne un controllo incrociato perché comunque è più rapido il rilevamento dei tasti che il rilevamento di cambio di posizione ). Io ti propongo un esempio non tanto riuscito ( non ho avuto tempo >_< ) dove vengono applicate alcune delle nozioni qui descritte: ho evitato che l'Eroe potesse andare vicino ai bordi della mappa( per non dover aggiustare i pixel lì ); ho utilizzato un sistema di rilevamento della posizione per poter mantere così certe possibilità come i Muovi Evento e non dovermi preoccupare delle collisioni( inoltre non è dentro un ciclo, come lo sarebbe il rilevamento della pressione dei tasti ); ho utilizzato il charset di VAL ( spero non me ne voglia, i crediti son sempre là xD ); visto le premesse, la camminata risulta comunque asincrona e anche troppo rapidi i movimenti ( faccio cambiare la grafica all'eroe per cercare di sincronizzarlo meglio, ma non è servito a molto ). Perché postarlo allora? Semplice, questa è solo una prova che richieda poche risorse hardware, infatti un ottimo risultato l'ho ottenuto proprio incrociando un sistema di rilevamento tasti con uno che rileva la posizione ( più un altro processo parallelo con ciclo che si preoccupava da solo di scandire il tempo per il cambio della posizione dell'Immagine ). Nel mio computer girava anche bene, ma provato in un altro scattava da fare schifo... peccato, perché si vedeva benissimo. Dunque un modo c'è per fare tutto ciò, ci vuole un po' di pazienza ( e tempo >_< ) e penso si possa riuscire a trovare una soluzione migliore di questa e che comunque richieda poche risorse hardware. http://ultrasonic.altervista.org/Giuoco.zip -
Per un video più o meno completo sulle varie features( ho interpretato così quel tuo "piccola anteprima di tutte queste aggiunte" xD ), ci vorrà ancora molto mi sa, visto che in pratica buona parte del BS la sto rifacendo, compreso il menù del BS stesso che non sarà più così a disposizione circolare, ma sarà un po' differente per dare spazio alle molteplici aggiunte. Non ti preoccupare per il sonoro, la grande novità risolve pure quello xD
-
Mille grazie per la segnalazione fanton95 ^^ ( non sapevo manco che esistessero comunità di rpg maker con così tanti utenti xD ) Se trovo il tempo adeguato cercherò di ringraziarli ( in inglese :E ) per l'interessamento( ho letto che pensano sia l'introduzione del gioco... mi sa che dovrò cominciare a scrivere la descrizione anche in inglese per non generare incomprensioni del genere ). Sempre a caccia di news eh ù_u ( c'hai pure ragione... l'ultima risale a giugno e non è manco una news >_< )Avevo scritto tempo fa che saremo passati a RPG Maker 2003 per poter usufruire di un maggior numero di tasti e di altre piccole comodità( anche se non indispensabili ). Ma già qualche giorno prima di quel messaggio, è spuntata fuori una novità che mi ha fatto pensare che invece convenga rimanere sul 2000, una grossa novità direi, grossissima °° Appena possibile sarà svelato tutto su un topic a parte xD In questo periodo non ci sono stati i progressi voluti ( c'è stato un problema di organizzazione coi tempi che ha portato me a dover preparare due esami per settembre e Starry a stare via di casa proprio nel periodo in cui non li stavo preparando >_< ). Ma riprenderemo al più presto... anche perché in media, per ogni feature realizzata ne spuntano fuori 4 nuove da voler inserire xD [ dico solo che ci sarà sicuramente la possibilità di selezionare il livello di difficoltà all'inizio e forse anche durante il gioco, che influenzerà solo le statistiche numeriche dei combattimenti, visto che si sta puntando a pochi mostri( saranno tipo massimo 6 Nemici su mappa contro i 3 Eroi, anche se ci saranno ondate successive e rigenerazioni speciali che non sto qui a spiegare, il tutto per poter girare anche su PC meno performanti ) ma con una solida IA e sempre una strategia d'Attacco/Difesa diversa da dover adottare per quasi ogni mostro, combinando attacchi coi propri alleati, e non saranno i soli a poterlo fare ]. PS: francamente il video "Inseguimento" lo reputo solo un esperimento riuscito discretamente, ci sono un paio di parti da aggiustare ancora che non mi convincono e il suono... RPG Maker lo gestisce da schifo... ho provato a ricreare un effetto particolare per cui le navicelle all'inizio si sentono solo nel canale destro sfumando verso quello sinistro( così come in altre parti del video ) ma il risultato non è dei migliori... penso che dovrò proprio montare un file audio a parte di quasi l'intera durata della scena. Come avevo già scritto poi, è stato fatto con una serie di funzioni costruite per l'occasione e quindi potrebbe esserci la possibilità di farla diventare una scena interattiva dove schivare ostacoli o attacchi nemici etc etc.
-
Ciò che dovrebbe "correggere" la patch è proprio quello che da te non succede, ovvero sbloccare l'immagine in quelle situazioni... Prova così: 1) una volta inserite le varie istruzioni, salvi il progetto; 2) applica la patch al file RPG_RT.exe( assicurati di aver estratto il file unlockspics.exe dalla cartella compressa zip o rar che sia, non dovrebbe influenzare il processo in questo caso, è solo per scrupolo ). Così dovrebbe funzionare( potrebbe succedere che se salvi il progetto dopo aver applicato la patch, nel caso di particolari modifiche apportate al progetto, venga vanificata la patch stessa e quindi sia da rifare ). PS: mi scuso con lo staff per l'OT >_<
-
Sì, immaginavo da come avevi scritto il tuo messaggio precedente, e per quello che l'ho fatto io, così da non lasciare questo topic con un problema del genere irrisolto ^^Alla fine meglio così per te, sei riuscito a cavartela con le tue forze Io ho la versione 1.0.9.1 di White Dragon, e mi son posto la stessa domanda. Allora ho creato un nuovo progetto al volo, ho messo un evento in processo parallelo con dentro un paio di istruzioni per muovere a destra e poi a sinistra una picture ciclicamente. A questo punto ho fatto partire un messaggio e l'immagine si bloccava dopo aver finito un movimento ( o a destra o a sinistra ). Allora poi ho applicato la patch al file RPG_RT.exe e verificato positivamente che la patch funziona su questa versione. Ecco, potresti fare lo stesso... faresti prima che aspettare una risposta xD
-
mmm... forse tutto ciò avresti dovuto scriverlo nel tuo primo messaggio, eh? 1)Pressione di un tasto da parte del giocatore con conseguente movimento dell'Eroe durante la visualizzazione di un messaggio; 2)Spostamento "istantaneo" da un punto a un altro della mappa; 1)Bisogna creare un evento in Processo Parallelo attivabile tramite switch( o nella modalità che vuoi ) che controlli l'input della tastiera ( quindi l'istruzione "Inserisci Comando Tasti" ) e di conseguenza faccia muovere l'Eroe nella direzione apposita ( quindi con l'istruzione "Muovi Evento" ). Infatti l'Eroe si può MUOVERE con il comando "Muovi Evento" e l'opzione per i messaggi "Fai muovere gli eventi" attiva ( da come hai scritto tu nel primo messaggio sembrava appunto che ci avessi provato ma senza successo e quindi l'avevo sbatamente già escluso ). Dunque decidi tramite Condizione IF quale tasto deve essere premuto per eseguire lo spostamento di due caselle. 2)Per l'"istantaneo", se è solo di due caselle, basta che prima dello spostamento aumenti al massimo la velocità di spostamento dell'Eroe( se proprio non lo si vuole vedere o se si tratta di più di due caselle, si rende invisibile l'Eroe prima dell'inizio dello spostamento e si rende nuovamente visibile a spostamento finito ). Anche perché non credo che tu volessi usare "Punto di Trasporto" per spostare l'eroe, vero? xD Potevo anche non rispondere, ma l'ho fatto comunque perché sapessi che bisogna essere sempre specifici quando si pone un problema, altrimenti il numero di soluzioni possibili potrebbe essere esagerato e alcune di esse non esattamente soddisfacenti. Inoltre non avevi descritto la tua soluzione, la quale sarebbe potuta essere utile ad altre persone che un giorno si sarebbero trovate con un problema simile( se non identico ). EDIT: ora il precedente link Esempio è stato aggiornato con quest'ultima parte ( ho creato una nuova mappa, quindi la precedente c'è ancora ).
-
Qualcuno propone per caso una Battle Animation( Database > Filmati Attacchi )? No perché in tal modo non ci sarebbe nemmeno bisogno di una patch: 1) funzionano normalmente se avviate prima del Mostra Messaggio e anche durante il Messaggio stesso; 2) come le pictures, vengono mostrate sotto il Messaggio; 3) l'unico vero svantaggio di queste è il solito: vengono visualizzate sopra qualsiasi Picture. Ma prima ancora di pensare a Picture e Battle Animation( e rompersi decisamente troppo per una cosa del genere, visto che bisogna prima creare le varie grafiche, e poi usarle correttamente con la massima precisione dei pixel ), esistono gli Eventi: °fai in modo che, durante il messaggio, l'Eroe e un altro Evento( non visibile inzialmente ) si trovino nello stesso punto per poter così rendere invisibile l'Eroe cambiandogli grafica e rendendo invece visibile l'Evento che sostituirà l'Eroe( con la sua stessa grafica ); °fai muovere quindi l'Evento che sostituisce l'Eroe nel modo che vuoi ( ovviamente devi aver abilitato quell'opzione particolare dei messaggi ); °alla fine, fai tornare l'Evento nella posizione dell'Eroe ( farai in modo che rimanga invariata ) e fai il processo inverso: rendi invisibile l'Evento e visibile l'Eroe. Siccome non ho tempo per spiegartelo meglio, ti lascio direttamente l'esempio che ho appena fatto ( sì, ci vuole meno a farlo che a spiegarlo in modo esaustivo >__< ): Esempio Il codice sta tutto in quei due eventi lì sulla mappa( ed è davvero solo un esempio, puoi trovare tranquillamente altre varianti sulla stessa filosofia ). Ti serviranno le RTP di RPG Maker 2000 ( lo scrivo perché in questo topic non specifichi se usi la versione 2000 o la 2003 ). PS: secondo me la patch segnalata da Soul Eater è un must per chi possiede RPG Maker, può sempre essere utile ( e non dovrebbe mancare nel portale di questa comunità :[ ).
