Search the Community

Simple Last Battle Events Fix v 3.0 Descrizione Consente di eseguire eventi di battaglia legati all'eliminazione dell'ultimo avversario o membro del party, cosa non possibile con il codice di default sulle condizioni di vittoria. L'esempio più classico in cui può servire è un kill count gestito ad eventi senza ricorrere a workarounds come il sacrificare la possibilità di drop di tesori o a script dedicati. Altri esempi sono la chiamata ad un evento comune PRIMA di uscire dalla Battaglia, o far sbucare dai loro nascondigli degli alleati della fazione perdente, o modificare l'inventario del party, aggiungendo o togliendo oggetti a seconda di come si sta concludendo lo scontro. Serve, insomma, ad aprire nuove possibilità agli eventers per le questioni legate all'epilogo delle battaglie od al rimandarlo. SCREENSHOTS Autore Snippet sviluppato da giver, di RPG2S. EDIT (2018-03-16) - DEMO progettata da Vincent Law. Allegati Non necessita di elementi esterni al codice. E' disponibile una piccolissima demo. Lanciare il Battle Test della prima battaglia, Ghost*2, nel DataBase. Da notare che gli eventi di esempio fanno uso di (call) script, di diversi codici messaggio e di variabili con IDs vicini al massimo (5000), quindi, anche perchè svolti in modalità di test, dovrebbero risultare meno reattivi rispetto a quelli di una battaglia ingame in un normale progetto. EDIT (2018-03-16) - Sostituita la demo con una versione estesa, dove ci sono eventi legati alla morte dei membri del party, e pertanto alla loro sconfitta. Poichè gli avversari sono comunque deboli, è preferibile testarla con solo 1 o 2 personaggi di primo livello e dando il tempo ai fantasmi di uccidere l'intero party, inclusi eventuali rinforzi (caldamente consigliato di esaminare gli eventi di battaglia). DEMO http://afantasymachine.altervista.org/_altervista_ht/forums/SimpleLastBattleEventsFix_DEMO.zip Istruzioni per l'uso Al solito, creare uno spazio nello script editor, al di sotto di quello Scene_Debug o del Battle System non di default, se utilizzato, ed al di sopra dello script Main. Vedere Bugs e Conflitti Noti e Altri Dettagli per come adattarlo quando il Battle System usa un metodo (def) judge con condizioni differenti da quelle di default. Script EDIT (2018-03-16) - Dopo un anno che lo snippet era stato completato con successo, ho avventatamente aggiunto una riga di codice che fa congelare la battaglia in caso di sconfitta del party. Nell'estendere la demo, me ne sono accorto, e tale riga è stata rimossa. Chiedo scusa per il disguido. Qui trovate la versione testo semplice, con estensione .rb, dello snippet. Come sempre, per evitare che l'anti-leeching di altervista ne impedisca il download, è necessario visitare la pagina e salvarla dopo averla visualizzata. http://afantasymachine.altervista.org/CodiceRGSS/vintage/rgss_SimpleLastBattleEventsFix_rpg2s.rb Bugs e Conflitti Noti Lo script 'sovrascrive(rebbe)' il metodo (def) judge di Scene_Battle, ma lo 'mantiene' rinominandolo default_judge, trascritto apposta come parte di questo script per evitare agli utilizzatori di dover toccare il codice e per facilitare il confronto tra le due versioni del metodo in caso si debba adattare ad esigenze diverse da quelle di default. Il nuovo judge mente sul raggiungimento delle condizioni di vittoria da parte delle due fazioni finchè esistono eventi di battaglia che sono attivati dall'eliminazione dell'ultimo combattente di una delle due fazioni, per poi chiamare in causa lo judge originale affinchè chiuda la battaglia se sono ancora valide le condizioni per farlo. Non dovrebbe interferire con alcun Battle System basato su Scene_Battle, che gestisca Vittoria e Sconfitta del party allo stesso modo di quello di default, ossia la battaglia termina quando non ci sono più combattenti "abili" in una delle due fazioni, in quanto tali Battle Systems modificano le modalità di svolgimento dello scontro, ma non le condizioni per determinare quando termina. Non è detto, inoltre, che un Battle System diverso da quello di default ne abbia bisogno. Se non si è ancora provato a creare le condizioni per eventi speciali di fine battaglia, è possibile, prima di inserire questo script, usare la battaglia inclusa nella demo inserendola nel proprio progetto ed attivare il Battle Test: qualora appaia solo uno dei due rantoli dei fantasmi, vuol dire che questo script può tornare utile, altrimenti è già tutto a posto. Nella sezione più sotto viene accennato come 'creare' una variante che funzioni con uno judge dalle caratteristiche differenti rispetto a quello di default. Altri dettagli Dovrebbero esistere fix a questo problema fatti da altri scripters. Se il mio non viene trovato soddisfacente, è possibile provare a cercarli. E smettere di leggere questo post, in quanto la parte successiva riguarda solo coloro che lo vogliono usare ma il Battle System inserito nel loro progetto ha delle condizioni di vittoria differenti od estese. Purtroppo io non posso stare ad adattarlo ad ogni Battle System disponibile. Se viene usato un Battle System diverso da quello di default, bisogna andare a controllare se al suo interno c'è un metodo def judge nella sua classe Scene_Battle. Trovarlo può significare che è stato esteso, avendo un alias nelle vicinanze includente la parola judge, o sostituito, ossia c'è solo def judge senza alias. In entrambe i casi questo fix va modificato opportunamente per supportare le cambiate possibilità di gestione d'epilogo dello scontro. Osservando attentamente il codice del mio mini-script è facile notare che il nuovo metodo ha diverse cose in comune con quello originale, in quanto deve comunque verificare se lo scontro sarebbe da considerare concluso, ma ritornare false e controllare che non ci siano eventi di battaglia da eseguire prima di chiamare quello originale. Purtroppo non ho la possibilità di creare un vero e proprio tutorial a riguardo, perciò in questa sede darò solo qualche suggerimento sul come fare in modo che il fix funzioni anche con judge relativamente diversi da quello di default. E' più facile a dirsi che a farsi, comunque, e le probabilità che si debba procedere in tal senso dovrebbero essere poche. A) Se il metodo viene completamente sovrascritto, ossia non vi è il relativo alias, la cosa è abbastanza intuitiva. ​Si comincia col fare un copia ed incolla dello judge non standard subito sotto lo stesso. Si rinomina la versione sopra, quella originale, come default_judge. Si modifica la copia sotto, che si chiama ancora judge, facendo riferimento agli judge presenti nel mio fix. EDIT (2018-03-16) - Ovvero: Eliminare tutti i settaggi e chiamate a metodo che non c'entrano con la verifica delle condizioni di vittoria.Inserire una riga prima di ciascun return true, con scritto @bend = true.Sostituire tutti i return true con dei return false (ma NON viceversa!).Inserire il codice così modificato al posto di quello dello snippet, tra unless @bend ed il relativo else. B) Se è presente un alias al metodo judge, ossia l'autore del Battle System ha aggiunto condizioni di vittoria senza sostituirle a quelle di default, c'è meno da dover modificare, ma bisogna agire con maggiore cautela. - Ovviamente, per prima cosa, è necessario incollare questo mini-script subito sopra quello del Battle System dove compare lo judge non standard.Si procede poi col copiare il metodo judge non standard inclusa la sua dichiarazione di alias, ed incollarlo subito sotto quello originale del Battle System custom.Si rinomina lo judge non standard che sta sopra come default_judge.Ritornare all'alias originale, quello che si trova sopra il nuovo default_judge, e cambiare il nome di entrambe i parametri, il cui secondo deve essere, 'ovviamente', default_judge, invece che semplicemente judge, mentre il primo può essere cambiato a piacimento. Tale primo parametro andrà sostituito anche dove compare all'interno dell'ora metodo default_judge.Modificare il nuovo judge, ossia quello sotto, facendo riferimento ai due judge presenti nel mio fix.In entrambe le occasioni, non è il caso di scoraggiarsi se bisogna fare più tentativi per ottenere il risultato desiderato. Buono Scripting! CHANGELOG della Versione 3.0 di questo snippet: Non c'è perchè si tratta della prima versione rilasciata in pubblico.

Creare un Menu ad Eventi Informazioni Tool usato: RPG Maker Ace (in inglese) Autore: Morshudiego Premessa Anni orsono c'erano gli alexiani (Così chiamo chi usa RPG Maker 2000/2003) che criticavano di brutto i ralphiani (chi usa il VX) per il fatto che utilizzavano script invece di farsi il mazzo con gli eventi, cosa che ha portato a pensare che i ralphiani fossero dei nabbi completi. Se da un lato penso che gli script siano una manna dal cielo che permette di gestire ogni singolo aspetto del gioco, da un lato sono daccordo con gli alexiani: gli script hanno favorito di molto la scarsità di impegno degli utenti, promuovendo il copia-incolla di script e limitando così la varietà dei progetti. Ho deciso di scrivere questa guida principalmente per dimostrare che l'eventing su Ace non è morto ed è tuttora valido per realizzare progetti molto personali e originali. Secondariamente può essere utile a qualcuno che vuole realizzare il proprio menù ma non sa da che parte girarsi (e non ha dimestichezza con gli script). Ci tengo a specificare che in questo menu si useranno comunque gli script call per poter semplificare notevolmente il lavoro soprattutto con l'uso delle immagini. È vero che sarà un menu ad eventi, ma è anche vero che se esiste un modo più efficiente e veloce di realizzare una cosa, è giusto impararla. L'idea è stata rimandata a quando completerò il menu. Indice Parte 1: Le grandi basi Parte 1bis: Costruisciti da solo il tuo Input trigger! Parte 2: Toh, un menu! Parte 3: La borsa infinita (COMING SOON) Parte 4: Questioni di abilità (COMING SOON) Parte 5: Cosa mi metto oggi? (COMING SOON) Parte 6: Curriculum Vitae (COMING SOON) <altre parti verranno aggiunte in futuro> Parte 1: Le grandi basi Partiamo subito col puntualizzare una cosa. http://i.imgur.com/2XbTa6M.png Questo NON E' un menu. Questo è un mostra scelta che si spaccia per menu. Brutto da vedere, estremamente limitato, scarsamente personalizzabile. E' l'ultima cosa che voi vorreste avere sul vostro progetto. Per realizzare un buon menu bisogna utilizzare queste componenti: - Variabili - Switch - Eventi Comuni - Cicli - Condizioni SE (Conditional Branches in inglese) - Immagini Non starò a spiegare cosa sono tutti questi, ci sono altri ottimi tutorial al riguardo. Per le immagini vi assicuro che non bisogna essere un artista per realizzare qualcosa di decente. Un buon programma che vi consiglio per realizzare le immagini è GraphicsGale: Gratuito, semplice e con funzioni molto utili. Punto 1: Lo scheletro del menu Quando creano un menu ad eventi, molti principianti tendono a mettere tutto il codice in un solo evento comune. E funziona eh, per carità. Ma poi quando devono apportare delle modifiche a distanza di tempo... E chi ci capisce più? Ecco perché è molto meglio dividere il menu in vari eventi comuni, ognuno con il suo codice da gestire. Sarà più semplice da capire e da fare delle modifiche. Creiamo quindi 4 eventi comuni: Uno per chiamare il menù, uno per aprire il menu, uno per quando siamo dentro il menu e uno per chiudere il menu. [001: Pulsante Menu] [Trigger: Parallel Process] [Condition Switch: 0001:Pulsante Menu Premuto] [002: Apri Menu] [Trigger: None] [003: Dentro Menu] [Trigger: None] [004: Chiudi Menu] [Trigger: None] Concentriamoci sul primo evento: Il richiamo del menu, che sarà l'unico evento parallelo del nostro menu. *: "Ma come!? Vuoi dire che non devo utilizzare 400 eventi in parallelo per far funzionare tutto alla perfezione!?!?" Utilizzando i cicli al posto degli eventi paralleli possiamo ottimizzare grandemente il nostro menu, facendo risparmiare cpu al giocatore e permettendo di usare i processi paralleli per altre cose. Tornando al nostro evento, settiamo il trigger in "Parallel Process" e come switch scegliamo la switch numero 1, chiamandola "Pulsante Menu Premuto". il codice al suo interno sarà molto semplice: Se il tasto B (Esc sulla tastiera) viene premuto, il secondo evento comune (Apri Menu) verrà attivato. [001: Pulsante Menu] [Trigger: Parallel Process] [Condition Switch: 0001:Pulsante Menu Premuto] @>Conditional Branch: The B Button is Being Pressed @>Call Common Event: [Apri Menu] @> : Branch End @> Ora che il nostro evento di richiamo è bello che pronto, possiamo concentrarci sugli altri eventi comuni (che d'ora in avanti chiamerò CE) Il secondo ed il quarto CE (Apri menu e Chiudi menu) per il momento sono abbastanza semplici. Apri menu attiverà una switch (la numero 2, che chiameremo "Menu aperto") e chiamerà l'evento comune Dentro Menu. Chiudi Menu invece spegnerà la switch per informare il gioco che il menu è stato chiuso. [002: Apri Menu] [Trigger: None] @>Control Switches: [0002: Menu Aperto] = ON @>Call Common Event: [Dentro Menu] @> [004: Chiudi Menu] [Trigger: None] @>Control Switches: [0002: Menu Aperto] = OFF @> Ora manca solo l'evento comune Dentro Menu. Qui dentro ci sarà tutto il fulcro del nostro menu. Dato che non sarà un processo parallelo dobbiamo "bloccare" il gioco dentro il CE. Per fare questo utilizziamo un ciclo, così che il codice contenuto all'interno continuerà a ripetersi finché non verrà fermato in qualche modo. Dentro questo ciclo bloccheremo il personaggio del giocatore col comando "Set Move Route" senza nessun tic e come movimenti "wait 1 frame". Dopodiché anche qui useremo una condizione SE "se il tasto B è premuto" per poter rompere il ciclo infinito e poter uscire dal menu. Per non far buggare il ciclo è necessario inserire, dopo tutti i vari comandi del ciclo, un "wait 1 frame" così che il gioco non si blocchi. Infine, al di fuori del ciclo richiameremo il CE Chiudi Menu per poter finalmente chiudere il menu e tornare alla mappa. [003: Dentro Menu] [Trigger: None] @>Loop @>Set Move Route: Player : $>Wait: 1 frame(s) @>Conditional Branch: The B Button is Being Pressed @>Break Loop @> : Branch End @> Wait 1 frame(s) @> : Repeat Above @>Call Common Event: [Chiudi Menu] @> Ora lo scheletro del menu è completato! Non dimenticate di attivare la switch 1 per poter utilizzare il nuovo menu! Punto 2: "Cambio della guard... ehm... del menu!" Usando un menu alternativo al menu principale, questi due andranno in conflitto quando si premerà il pulsante Esc. Per risolvere il problema bisogna disabilitare il menu di base con il comando "Change Menu Access". Nella prossima parte purtroppo in questa parte di menu c'è veramente nulla, essendo solo la parte introduttiva. Nella prossima parte vedremo come gestire le immagini in modo da dare una parte grafica al menu. Alla prossima!