giver

Scusa se ci ho messo tanto, ma mi sono ritrovato con altre faccende da sbrigare . . . In compenso, ti evito di elencarti tutte le modifiche da fare allo script Scene_Title, e te ne posto una versione già pronta all'uso. Al massimo devi metterci le mani per modificare la posizione della finestra o i "nomi" dei comandi che appaiono nella finestra . . . Script Window_Command modificato Script Scene_Title modificato Li puoi incollare al posto di quelli standard con lo stesso nome oppure li inserisci sopra lo script Main, come ti trovi meglio . . . La grandezza del testo per i comandi del title è già impostata al massimo concesso dalla Window_Selectable standard. Se vuoi scritte nel title ancora più grandi dovrai sostituire quello script con la versione modificata da SephirothSpawn, e, lo farò io, la Window_Command andrà ulteriormente modificata . . . Per portare la finestra più in alto o in basso, devi ridurre o incrementare il valore di questa istruzione (riga 37 dello Scene_Title che ho postato) @command_window.y = 384 Per portare la finestra dei comandi più a sinistra o a destra, devi ridurre o incrementare il valore (320) indicato in questa istruzione (riga 36, proprio sopra quella di prima) @command_window.x = 320 - @command_window.width / 2 Se hai bisogno di chiarimenti, non farti scrupoli . . .

Basta inserire questo codice sopra lo script main class Window_Command def refresh self.contents.clear for i in 0...@item_max colore = $scene.is_a?(Scene_Title) ? Color.new(255, 0, 0, 255) : normal_color draw_item(i, colore) end end end Se il rosso generato ti sembra troppo cupo, dovresti aumentare un po' in secondo ed il terzo parametro della Color.new, che sono inizialmente a zero e rappresentano rispettivamente la componente verde e blu del colore RGBA (RedGreenBlueAlpha). O ridurre il primo parametro se ti sembra troppo vivace. Se ti accontenti del fatto che non avrà il tunnelling/wrapping, più tardi ti posto la Window_Command, nativa dell'XP, modificata per disporre i comandi anche in orizzontale, e come modificare il codice che crea la finestra per ottenere quello che desideri . . .

Aggiornamento. Il BS adesso funziona senza generare errori, ed ho reso funzionante l'opzione Evoca nei comandi di battaglia. Non avendo le skill per chiamare gli AEons, quando l'ho usato non è apparsa ovviamente alcuna evocazione, ma la finestra per sceglierla si è aperta e richiusa senza problemi, premendo i tasti appropriati . . . Quindi, per vedere se funziona ancora dopo un'evocazione, sarebbe meglio che la testassi tu, nel tuo gioco, perchè sarebbe difficile per me ricreare le situazioni utili a scoprire se sono presenti determinati errori . . . Comunque non ti passo subito gli script corretti, perchè vorrei completare la mia parte, prima di dedicarmi ad altro, ossia realizzare il sistema che gestisce la fuga dei membri del party. Dovresti spiegarmi come vorresti che funzionasse. Ad esempio, quando viene scelto "Ritirata" dai comandi di battaglia, vuoi che tenti la fuga solo il personaggio di turno o l'intero party ? In caso di fuga separata per ciascun eroe, esce di scena solo il battler, con "annerimento" delle sue statistiche, o vuoi che vengano eliminati anche i suoi dati dalla finestra con gli status degli eroi ? E gli eroi fuggiti, in caso di vittoria del party, ricevono comunque tutti i punti esperienza o solo una parte ? N.B.: Mi ero sbagliato sulla Window_Message. L'AMS ne ha bisogno, quindi non l'ho cancellata . . .

Perchè non si veda la windowskin, basta inserire questa istruzione dopo quella che crea la finestrella con i comandi . . . @command_window = Window_Command.new(192, [s1, s2, s3]) # questa crea la finestra e c'è già @command_window.opacity = 0 # questa rende trasparente la windowskin Per la faccenda del disporli orizzontalmente, potresti usare una versione modificata della window_command che supporti appunto più colonne (quella che c'è di base in rpg maker xp è solo monocolonna). E purtroppo non funzionerebbe come quella che c'è nel VX, che consente anche il tunnelling (chiamato wrap nel VX), cioè, se sei ad un'estremità della finestra e muovi il cursore ancora in quella direzione, questo riappare all'estremità opposta. Per come è concepita la Window_Selectable dell'XP, il tunnelling non è possibile. Non so se si possano usare nell'XP entrambe questi script del VX senza modificarli, ma se si potesse fare, poi basterebbe aggiungere un paio di numeri all'istruzione che crea la finestra per avere i comandi in orizzontale e grandi quanto ti pare . . . Lo script di cui parli potrebbe essere lo Scene_Title di CCOA. Per realizzare un Title molto bello, "impaginabile" a piacere, con quello script non c'è bisogno di conoscere l'RGSS, ma solo essere bravi a disegnare ed avere un certo senso estetico . . .

Allora, la causa dell'errore è l'Aeon System (per adesso solo questo script), che sovrascrive alcune delle funzioni dello Scene_Battle dell'RTAB (Non fa parte di quello che ho modificato io, però). [vocina interiore]Questo dimostra che anche usando alias, i problemi di incompatibilità si presentano comunque . . .[/vocina interiore] Domani (er . . . oggi) pomeriggio vedo se riesco a fare qualcosa per renderli compatibili . . . P.S.: Hai troppi script che modificano le stesse funzioni, e credo che in queste condizioni di errori ne verranno fuori ancora . . . (E usare l'SDK diventa relativamente inutile) P.P.S.: Ho notato che usi l'AMS. Puoi anche eliminare la Window_Message che ti ho passato io, visto che quello script permette già di scegliere il font da usare nei messaggi, anche diverso dal resto del gioco . . .

E' stato facile realizzarlo . . . Incolla questo sopra main, come sempre. EDIT - Aggiunto il return nella funzione, come segnalato da Wakko. class Scene_Menu def transfer_player(new_map_id, new_map_x, new_map_y, player_facing = 2) $game_map.setup(new_map_id) $game_player.moveto(new_map_x, new_map_y) $game_player.refresh case player_facing when 2 # voltato giù $game_player.turn_down when 4 # voltato verso sinistra $game_player.turn_left when 6 # voltato verso destra $game_player.turn_right when 8 # voltato verso l'alto $game_player.turn_up end $game_player.straighten $game_map.autoplay $game_map.update $scene = Scene_Map.new return end end per effettuare un trasferimento, nello Scene_Menu bisogna usare la seguente istruzione self.transfer_player(id_mappa, coord_x, coord_y, direzione_eroe_facoltativa) Il quarto parametro deve avere uno dei seguenti valori: 2, se si vuole che sia voltato verso il basso 4, se si vuole che guardi verso sinistra 6, se deve guerdare verso destra 8, se dovrà essere voltato verso l'alto Se non viene indicato, l'eroe sarà voltato verso il basso. Es. Trasferirlo nella casella (10, 31) della mappa 2 self.transfer_player(2, 10, 31) L'eroe sarà voltato verso il basso. Es. Come sopra, ma voltato verso destra self.transfer_player(2, 10, 31, 6)

Certo che si può fare ad eventi, ma si dovrebbe scomporre l'immagine finale in tante picture (cosa che presenta comunque il vantaggio di fare frammenti di forme e dimensioni diverse tra loro - fattibile anche per la finestra chiamata dal menù, ma da spezzettare a mano pittosto che tramite codice), sarebbe meglio non attivarne la visualizzazione tramite menù ma da mappa, e si dovrebbero tenere liberi tanti livelli picture quanti sono i pezzi del puzzle, se non le si dedica una mappa apposta (o creare tante versioni della picture quanti sono i frammenti da trovare, ma consumare un solo livello picture) . . . Inoltre, se l'immagine è più grande di una schermata, dovrebbe bloccare l'eroe (o trasportarlo su una mappa "visualizzatore" per poi riportarlo dov'era quando è stato premuto il tasto per vederla) e permettere di sfruttare i tasti freccia per cambiare la visuale e poterne vedere tutti i dettagli . . .

Teoricamente sì, ma come hai ipotizzato tu, non è la scelta migliore tra quelle a disposizione . . . Per fare avventure grafiche, tra i tool che risulterebbero migliori di rpg maker xp (ma non solo), puoi prendere in considerazione soprattutto questi tre: Adventure Game Studio (AGS), che è il più usato per queste cose, anche se il suo linguaggio di scripting non è particolarmente intuitivo Wintermute Engine, che permette (anche) di usare personaggi in 3D con fondali 2D (stile The Longest Journey, non so se ce l'hai presente . . .) Game Maker, che è molto generico come tool di sviluppo, nel senso che non è specifico per alcun genere di giochi, a differenza dei due sopra che sono fatti apposta per sviluppare avventure grafiche, ma è potente e versatile, nonostante sia abbastanza semplice da usare. Al momento non posso fornirti i link ai siti principali di ciascuno di questi tool, ma dovrebbero essere facili da rintracciare anche tramite motori di ricerca.

L'avevo capito che non cercavi un minigame. Io parlavo di sfruttarne il meccanismo di scomposizione di un'immagine completa in pezzi più piccoli, perchè sarebbe più comodo che usare un'immagine separata per ogni pezzo del puzzle . . . (Anche se così i pezzi potrebbero essere di forma e dimensioni anche molto diverse tra loro . . . Lo script del mini-gioco infatti la ritaglia tramite codice solo in una serie di quadrati) Ed a questo punto riformulo la richiesta di caratteristiche che vuoi che abbia: L'immagine si vede tutta dentro una schermata (max 640x480) ? Va bene se tutti i pezzi hanno le stesse dimensioni e sono quadrati o rettangolari ? I pezzi vengono dati al giocatore in un ordine preciso (ossia, primo pezzo ottenuto è sempre il primo della prima riga, il secondo è sempre il quarto della terza riga, ecc) ? Le percentuali di sblocco sono stabilibili matematicamente (Es. un pezzo sbloccato ogni 5% di gioco completato) ? Il comando del menù per vedere l'immagine, quando il giocatore non ha raccolto alcun pezzo, deve apparire nel menù solo dopo che il giocatore ha conquistato almeno un pezzo o appare sin dall'inizio ma disabilitato ? Se fai uso di script modificati, li trovo nella demo che hai postato e non sono criptati ? Vuoi determinate caratteristiche di cui non ho parlato ?

E' uno script infido, te l'avevo detto. Comunque ti dà errore perchè devi copiare anche la seconda parte di Scene_Battle del progetto che ho corretto (Scene_Battle 2, mettilo direttamente sopra l'RTAB). Infatti pensavo che tutte le funzioni fossero nello script RTAB ed invece, cercando un determinato pezzo di codice, ho scoperto che si appoggia ad alcune funzioni degli script standard per gestire la battaglia: se fossero state cancellate le quattro parti dello script Scene_Battle che trovi di base nell'XP, ti avrebbe dato errori a raffica . . . Esistono diverse varianti del Minkoff, appena ho il tempo di controllare ti mando, via MP, il link al forum dove puoi trovare una decina di Demo che appunto hanno il Minkoff personalizzato ciascuna in modo differente, ed anche il manuale per usare lo script (E' tutto in inglese, però). Provale, e vedi se ne trovi una che ti piace di più di quella che usi adesso . . .

Tranquillo, adesso funziona tutto. Scarica versione corretta (2) progetto @ Mediafire P.S. : Per la questione dei comandi in battaglia, non ha importanza quanti siano . . . Il problema vero è farli funzionare correttamente quando vengono selezionati.

Si può fare anche senza eliminare difendi, aggiungendo un quinto comando di battaglia, anche mantenendo la finestra delle stesse dimensioni, se lo si desidera. La difficoltà principale è sviluppare un sistema che gestisca la fuga di singoli eroi invece che dell'intero party, soprattutto se vuoi inserire un'animazione del PG che fugge fuori dallo schermo . . . Adesso funziona. EDIT - Eliminato il link per via del bug presente. Più sotto c'è la versione completamente corretta. Purtroppo io non ho mai approfondito il minkoff, quindi in casi eccezionali potrebbe ancora dare errore . . . (Tra l'altro so che la versione RTAB è quella che dà più grane . . .)

Non so se esiste già uno script che faccia quello che ti serve. Relativo ai puzzle, so che esiste uno script per un minigioco in cui bisogna ricostruire un'immagine ritagliata in quadrati entro un limite di tempo, e lo si potrebbe usare come base per realizzare lo script che serve a te. Se ritrovo lo script di cui parlo, lo posto (Non ho ancora guardato nella sezione script di questo forum, magari c'è . . .). EDIT - Trovato nella sezione script xp del forum . . . Topic script mini-game puzzle Per farlo da zero invece, la difficoltà dipende da alcune scelte sul suo funzionamento: I pezzi sono tutti grandi uguali ? I pezzi hanno forma quadrata/rettangolare piena, e perciò posizionabili uno accanto all'altro direttamente, o bisogna "giocare" con le coordinate per "agganciarli" agli altri ? I pezzi vengono sbloccati secondo un ordine preciso, o viene scelto a caso tra quelli disponibili ? L'immagine è grande al massimo come una schermata, o di più ?

Per levare la finestrella del contapassi dal menù, basta eleminare nello script Scene_Menu, della demo che ho postato. le righe di codice dalla 113 alla 118, ossia queste # Make steps window @steps_window = Window_Steps.new # Rende semi-trasparente la finestra del contapassi @steps_window.opacity = 50 @steps_window.x = 0 @steps_window.y = 320 Ed in caso tu voglia abbassare la posizione della finestra col timer, devi aumentare il valore di questa istruzione (riga 112 nella demo) @playtime_window.y = 224 se le assegni valore 320 posizioni il timer dove prima c'era il contapassi . . . EDIT - Questo vale per il BS di base di rpg maker xp. Per altri BS potrebbe essere differente Devi fare tre piccole modifiche allo script Scene_Battle 1) Nella prima parte della Scene (Scene_Battle 1, nella lista degli script) devi eliminare le righe 313 e 314, ossia queste when 2 # party command phase update_phase2 Io ti consiglio di non eliminarle "fisicamente", ma di metterci semplicemente davanti il simbolo di commento, così # when 2 # party command phase # update_phase2 2) Nella seconda parte della Scene (Scene_Battle 2, nella lista degli script) alla linea 29, ossia questa start_phase2 devi mettere 3 al posto del 2, quindi deve diventare start_phase3 3) Nella quarta parte della Scene (Scene_Battle 4, nella lista degli script) alla riga 116, ossia questa start_phase2 devi, indovina un po' (XD), fare la stessa cosa del passo 2, ossia mettere 3 al posto del 2, così start_phase3 Guarda che così, però, non verrà mai chiesto al giocatore se vuole combattere o fuggire . . . Se vuoi che la richiesta non venga presentata solo all'inizio della battaglia, ed in tutti gli altri turni invece sì, allora devi mettere in pratica solo i primi due passi che ti ho indicato, senza fare la terza modifica . . .

Ok, lavoro completato Per scrivere le istruzioni ci ho messo dieci volte il tempo impiegato a realizzarlo . . . XD Ho cercato di essere il più chiaro possibile, ma in caso di problemi chiedi pure. Le istruzioni per usare le modifiche in altri script simili sono all'inizio di ogni script modificato, ma se non hai versioni personalizzate di quegli script, basta che li inserisci nel progetto che li deve usare, meglio se al posto di quelli base. La demo è stata realizzata con la versione 1.02a di Rpg Maker XP. Se hai una versione precedente, per farla funzionare devi creare un progetto vuoto, copiare il file cartina.JPG che si trova nella cartella Titles della demo in quella Titles del progetto vuoto, e copiare il file Scripts.rxdata che sta nella cartella Data della demo in quella Data del progetto vuoto. Scarica demo Menù Semplice con Status Party Esteso da Mediafire Buona creazione :happy: EDIT - Ho postato il link alla demo invece di mandarlo via MP perchè le informazioni inserite nei commenti degli script possono tornare utili anche a chi non ha un party esteso da mostrare . . .

Nel mio post precedente avevo detto che NON era la world map anche se lo sembrava . . . Per un progetto che sto sviluppando sto creando un sacco di cartine, e visto che lo sfondo del menù deve essere grande quanto le cartine che avevo a disposizione, ne ho usata una . . . Il fondale del menù va importato o copiato nella cartella Title del progetto, DEVE essere di 640 X 480 pixel, e per indicarlo nel codice dovrai inserire al posto di "cartina", in una delle prime istruzioni dello script Scene_Menu, il nome dell'immagine che vuoi usare. Mi raccomando che deve essere scritto tale e quale al nome del file, cioè se l'immagine si chiama "MiAimmaGine", non povrai scrivere semplicemente "miaimmagine", ma dovrai scrivere proprio "MiAimmaGine" . . . Poi, testando ulteriormente la versione di cui ho postato lo screen, ho trovato un altro difetto nella Window_Selectable (sono sicuro che è quello lo script colpevole, perchè anche i menù ITEM e SKILL presentano lo stesso difetto e non hanno subito modifiche). Se gli elementi sono dispari e ti trovi col cursore posizionato sul penultimo membro del party, nell'angolo in basso a destra, e provi a scendere, la finestra non si muove (!), e per arrivare all'ultimo componente del party da lì bisogna invece andare verso DESTRA . . . Io lo trovo piuttosto scomodo come funzionamento, quindi ho realizzato una variante che fa stare fino a 8 membri del party perfettamente visibili nella finastra con le mini-schede dei PG. Ecco uno screen: http://img372.imageshack.us/img372/8960/screen2demomenudsbx2.th.jpghttp://img372.imageshack.us/images/thpix.gif Comunque nella demo ti includo entrambe le versioni dello script. Tieni conto, per passare da uno all'altro, che il gioco usa quello più in basso nella lista degli script ed ignora quello sopra come se non ci fosse, se hanno gli stessi metodi (ed in questo caso è così) EDIT - Dimenticavo di segnalare che anche la seconda versione supporta lo scrolling, comunque, che si attiva, naturalmente, in caso di party composti da 9 o più elementi. Per la cosa dei comandi aggiuntivi, nessun problema: è una cavolata rendere scrollabile la Window_Command . . . (a meno che tu non voglia eliminare una delle finestrelle che stanno sotto la lista dei comandi, per mostrare tutti i comandi senza scrolling) Allora faccio quest'ultima modifica, evidenzio meglio le parti che ho cambiato, scrivo delle istruzioni per sfruttare le modifiche in caso che usi versioni non standard degli script che ho modificato, e ti posto la demo (Gli script modificati avranno il nome preceduto da un asterisco tra parentesi. I commenti in italiano negli script sono cose scritte da me, quelle in inglese c'erano già).

Allora, per fare tutto mi ci vorranno sì e no 10 minuti . . . Però mi sono dimenticato di chiederti quali valori vuoi mostrare nelle mini-schede dei pg. Magari se mi fai un piccolo schizzo di come vuoi che si presenti ogni mini-scheda è meglio . . . E tieni conto che avendo optato per le due colonne, le mini-schede saranno quasi quadrate, a meno di ridurre notevolmente la grandezza del testo. Inoltre, se usi uno script Window_MenuStatus personalizzato, che ad esempio mostra le barre sotto certe statistiche, invece che quello di default, avrei bisogno che me lo passassi, anche via MP. Per il resto, sono già al lavoro. EDIT: Uno screen del lavoro svolto per adesso. http://img60.imageshack.us/img60/9097/screendemomenudstj9.th.jpghttp://img60.imageshack.us/images/thpix.gif Note: 1) Lo sfondo non è uno scorcio della world map, ma è proprio un'immagine che non c'entra nulla. Solo che la prima cosa che mi è capitata sotto mano, delle dimensioni corrette, era quella cartina XD . . . 2) Nello screen si intravedono dettagli della windowskin, ma sono lasciati apposta perchè le finestrelle non erano molto belle a vedersi con solo quell'immagine di sfondo, Per renderle completamente trasparenti basta azzerare i vari "@nome_finestra.opacity" nello script Scene_Menu. 3) Gli status dei PG si vedono solo a metà, anche se ci sono 4 PG, per dimostrare che lo scrolling funziona, pur non avendo a disposizione uno script per party esteso. Ho usato un "trucco" per riuscirci: in condizioni normali, con solo 4 PG nel party, la finestra non scrolla. 4) Ho scoperto che con il layout multi-colonna, le Window_Selectable non fanno il "tunnelling", cioè arrivati in fondo ai contenuti, se si cerca di scendere ancora, non si ricomincia a scorrere i contenuti dall'inizio, mentre con una sola colonna lo fa, esattamente come avviene nelle liste di comandi. Non ho ancora studiato la Window_Selectable per cercare di farle fare comunque il tunneling, e non so neppure se ci riuscirò . . . Non appena mi dici quale aspetto vuoi che abbiano le mini-schede dei PG, modifico lo script e ti faccio avere la demo più le istruzioni per personalizzare le "nuove" caratteristiche del menù . . .

Dimensione della parte dove appaiono le scritte: 240x80 Coordinate, per una pic che fa solo da fondale alle scritte, come quella sopra: X = 160, Y = 200 Se la pic è più alta, perchè, ad esempio include la face del personaggio SOPRA la parte che contiene le scritte: X = 160, Y = 240 - (Altezza pic/2)

Giustissimo, mi ero dimenticato che l'aspetta un tasto è supportato di base solo dal Button Input Processing, ossia la quinta voce nel primo pannello (In linea teorica, si potrebbe usare un po' di ruby per fare il modo che il tasto debba essere "rilasciato" prima che la IF sia considerata di nuovo vera). Ma esiste anche il comando Aspetta/Wait che può essere usato per dilatare il controllo del tasto premuto se non si usa il controllo tasti, per gestire appunto armi a raffica senza dover gestire lo sparo con una tecnica differente rispetto a quelle a colpo singolo.

Sono tutte e tre relativamente semplici da fare, ma dovresti chiarire alcune cose: 1) Il font deve essere diverso da quello usato nei messaggi ed in altre parti del gioco? 2) Cosa vorresti usare come sfondo: un'immagine o lo scorcio di mappa presente al momento di chiamare il menù (o altro) ? 3) Vuoi che gli status di tutti i PG si vedano subito nella finestra o va bene se per vederli tutti si deve fare lo scrolling (cioè se ne vedono 4, o di più o di meno però non tutti, ma scendendo col cursore appaiono man mano anche gli altri) ? Ed in caso della visione completa, li vuoi su una o due colonne?

Penso che dovresti, oltre a rendere attiva la nuova finestrella, "disattivare" quella che la richiama . . . Gli elementi vengono disegnati nell'ordine in cui li generi, e quelli disegnati dopo, a "parità" di coordinate (se una parte di un elemento coincide con una parte dell'altro elemento) e "livello" z, sovrascrivono la grafica di quello che è stato disegnato prima. Puoi verificare se è successo questo generando il sottomenù dopo la Window_MenuStatus invece che prima, oppure assegnando al sottomenù un valore di asse z, dal 3 in sù (metti 10 o 20, per sicurezza . . .), ossia @duel_window.z = 20, o, meglio ancora, entrambe le cose . . .

Scusa Parbus, ma come mai, nel primo screen, gli edifici ed i cavalli non hanno le ombre come i personaggi ? (Molto marcate, tra l'altro . . .)

Bellissima la demo . . . X°°D L'autore è Selwyn (selwyn@rmxp.ch), comunque . . . (il BS era di Mr.Mo, invece)

Il link giusto è questo . . . http://www.mediafire.com/?5jmj2ffuw4y

Ci sono, ma alcune cose l'XP le gestisce in modo differente ed un po' nascosto rispetto alle precedenti. Nell'XP, il modo più comune per controllare i tasti è usare la penultima opzione nel quarto pannello delle IF/Conditional Branch ("Button <tasto> is Pressed", o qualcosa del genere) Attento che i button non corrispondono necessariamente alle lettere della tastiera, dato che l'XP supporta anche il gamepad di default. Per sapere a quale tasto-lettera corrisponde ogni button, devi avviare il gioco, anche in modalità test, passare la schermata del titolo, ed una volta sulla mappa premere F1, quello che di solito attiva la guida in linea dei programmi. Ti appare questo pannellino http://img128.imageshack.us/img128/6691/pannelloconfigurazioneyh0.th.jpghttp://img128.imageshack.us/images/thpix.gif Come vedi puoi anche cambiare le associazioni (e può farlo anche il giocatore, se lo avverti) XP controllerà solo i button di cui inserisci la IF, come se avessi messo il segno di spunta per quei button nelle versioni precedenti . . .