Rpg˛S Forum uses cookies. Read the Privacy Policy for more info. To remove this message, please click the button to the right:    I accept the use of cookies

Vai al contenuto

Rpg˛S Forum uses cookies. Read the Privacy Policy for more info. To remove this message, please click the button to the right:    I accept the use of cookies


  • Si prega di effettuare il log in prima di rispondere
[eventing utility] Simple Last Battle Events FIX, v 3.0, by giver - - - - -

    giver
  • Alex (Rm2k)

  • Utenti
  • Rens: 121
  • 0
  • StellettaStellettaStellettaStellettaStelletta
  • 1291 messaggi
  • Sesso:Maschio
  • Provenienza:The Creept - Room for Strangeness
  • Abilitā:Esperto

#1 Inviato 05 March 2018 - 12:39 PM

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

Spoiler




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://afantasymachi...ntsFix_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.
Spoiler

 

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://afantasymachi...ntsFix_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.
 


Modificato da giver, 16 March 2018 - 17:22 PM.

Spoiler

    Guardian of Irael
  • Coniglietto Rosso

  • Rpg˛S Admin
  • Rens: 173
  • 12
  • StellettaStellettaStellettaStellettaStellettaStelletta
  • 56952 messaggi
  • Sesso:Maschio
  • Provenienza:Bagnaia (Viterbo)
  • Abilitā:Apprendista


#2 Inviato 05 March 2018 - 15:52 PM

Dettagliatissimo come topic, ma soprattutto utilissimo e comodo per evitare i soliti giri di eventi sulla condizione di morte! Grandissimo lavoro! :3


(\_/)
(^ ^) <----coniglietto rosso, me!     
(> <)

 
Il mio Tumblr dove seguire i miei progetti, i progetti della Reverie : : Project ^ ^
 
KdUDtQt.png disponibile su Google Play, qui i dettagli! ^ ^
 
FwnGMI3.png completo! Giocabile online, qui i dettagli! ^ ^  
 
REVERIE : : RENDEZVOUS (In allenamento per apprendere le buone arti prima di cominciarlo per bene ^ ^) Trovate i dettagli qui insieme alla mia intervista (non utilizzerò più rpgmaker) ^ ^

Spoiler




  • Feed RSS