[Pokémon Essentials] Modifiche pesanti al sistema delle megaevoluzioni

[MegaTorterra]

Ciao a tutti, stamattina stavo giocando su pokemon showdown in modalità mix and mega e mi sono fatto una domanda: sarebbe possibile implementare questo sistema in pokemon essentials?
Vi spiego in breve come funziona:

Quando un pokemon megaevolve, subisce una modifica alle statistiche, all'abilità e, a volte, anche al typing.
La categoria mix and mega è un particolare metagame nel quale non c'è limite al numero di megaevoluzioni nel corso della partita ed ogni pokemon può megaevolvere.
Come?
In pratica vengono calcolati i boost che il pokemon subisce quando megaevolve e vengono applicati a qualsiasi pokemon usi quella stessa megapietra per megaevolvere.

Esempio: 

Spoiler (Clicca per visualizzare)

I problemi di aggiungere questa meccanica sarebbero i seguenti:

1. Rimuovere il limite di 1 megaevoluzione per partita
   
2. Stilare una lista dei boost dati da ogni singola megapietra
   
3. Far sì che la megaevoluzioni boosti le statistiche anziché cambiare forma
   
4. Far sì che se un pokemon dotato di megaevoluzione megaevolva, assuma l'aspetto megaevoluto anche se non usa la sua megapietra
   

Ora, I primi due non penso siano particolarmente difficili, ma per gli altri due non ho proprio idea di quale sia la fattibilità.
Qualcuno ha qualche idea o è una cosa irrealizzabile?

Aggiungo il link al thread di smogon che ne parla.

Mini edit: Aggiunto il link al thread di smogon con la descrizione del metagame. Inoltre, lì c'è una lista dei boost dati dalle megapietre.

[Artes]

Premetto che non soo sicuro di aver ben capito la meccanica da replicare, tuttavia ardisco di esporre qualche considerazione:
1) Basta modificare la funzione pbCanMegaEvolve?, eliminando il controllo su @megaEvolution[side][owner]!=-1 (o qualcosa di simile a seconda della versione di Essentials).
2) Si può fare in un PBS, ma è molto meno semplice di quanto appaia, in quanto occorre poi "spiegare" ad Essentials come leggere detto file. Non è difficile, ma occorre farlo.
3) Basta modificare la funzione pbMegaEvolve. Dato, però, che non si vuole una forma diversa (che andrebbe a finire nel pokédex, probabilmente), io procederei rinunciando alle vecchie funzioni sulla megaevoluzione e aggiungendo una variabile nella classe PokeBattle_Pokemon che registri se il pokémon sia megaevoluto o meno, la quale variabile sia poi richiamata dalla funzione calcStats in modo da aggiungere il miglioramento alla statistiche di base a seconda del tipo di megaevoluzione usato (tipo che sarà da inserirsi come argomento della variabile, ad esempio direttamente come stringa dei miglioramenti - la stringa [0,0,0,0,0,0] sarebbe quindi il default). Le funzioni, le classi e il resto possono variare a seconda della versione di Essentials.
4) Basta modificare i controlli nella funzione pbCanMegaEvolve?
Ad ogni modo, non mi è chiaro in quale modo i punti 3 e 4 siano compatibili fra loro.

[MegaTorterra]

Dunque, intanto grazie per le risposte.

La compatibilità tra il punto 3 ed il 4 sarebbe la seguente: Se un pokemon ha una megaevoluzione, megaevolvendo cambia forma.
Questi cambi di forma però non alterano le stats (basta cancellarle dal pbs).
Le stats vengono invece alterate dallo script da creare che hai suggerito al punto 3).
In pratica separo il cambio di forma e di stats.
Questo perchè ci sono 48 megaevoluzioni, 47 se non si conta Rayquaza. Codificare 47 forme aggiuntive per ogni pokemon, ipotizzando di fermarsi anche solo alla settima gen, l'ultima attualmente disponibile in essentials se non sbaglio, implica 37976 nuove forme (non sono certo del calcolo al 100%, ma sono comunque minimo 35k).
Passare poi all'ottava o alla nona gen o aggiungere ulteriori megapietre custom fa rapidamente giungere il tutto a numeri che rasentano l'assurdo. Per questo l'idea di separare cambio forma e cambio stats.
In caso non fosse fattibile si può tranquillamente droppare il punto 4, che è il meno importante dei tre.

Per quanto riguarda creare il PBS con le megapietre come funzionerebbe?
Prendo l'array dei miglioramenti e gli faccio leggere l'input da file? Come faccio a fargli interpretare i valori del pbs in Ruby? In C ho un'idea vaga ma non so quanto sia diverso questo linguaggio.

Invece riguardo alla stringa dei miglioramenti come funzionerebbe? Prendo l'array delle stats e gli "sommo" l'array dei miglioramenti quando megaevolvo?

[MegaTorterra]

Altra domanda, per rimuovere il limite sto guardando le stringhe disponibili e l'originale è il seguente:

Codice:

def pbCanMegaEvolve?(idxBattler)
    return false if $game_switches[Settings::NO_MEGA_EVOLUTION]
    return false if !@battlers[idxBattler].hasMega?
    return false if @battlers[idxBattler].wild?
    return true if $DEBUG && Input.press?(Input::CTRL)
    return false if @battlers[idxBattler].effects[PBEffects::SkyDrop] >= 0
    return false if !pbHasMegaRing?(idxBattler)
    side  = @battlers[idxBattler].idxOwnSide
    owner = pbGetOwnerIndexFromBattlerIndex(idxBattler)
    return @megaEvolution[side][owner] == -1
  end

L'ho modificato e penso che invece debba essere così:

Codice:

def pbCanMegaEvolve?(idxBattler)
    return false if $game_switches[Settings::NO_MEGA_EVOLUTION]
    return false if @battlers[idxBattler].wild?
    return true if $DEBUG && Input.press?(Input::CTRL)
    return false if @battlers[idxBattler].effects[PBEffects::SkyDrop] >= 0
    return false if !pbHasMegaRing?(idxBattler)
    side  = @battlers[idxBattler].idxOwnSide
    owner = pbGetOwnerIndexFromBattlerIndex(idxBattler)
    return @megaEvolution[side][owner] == -1
  end

Però non capisco cosa sia idxBattler e quindi non so che modifiche vadano fatte a side, owner e @megaEvolution. In questo caso a quanto ho capito suggerivi di eliminare completamente la parte dopo return? Che cosa controlla quel -1?
Also, come faccio sì che un pokemon megaevoluto non megaevolva di nuovo?

[Flygon]

Piuttosto che separare cambio forma e cambio stat, non puoi semplicemente creare uno sprite della forma mega che è uguale alla forma standard?

[MegaTorterra]

Piuttosto che separare cambio forma e cambio stat, non puoi semplicemente creare uno sprite della forma mega che è uguale alla forma standard?

Il problema è che questo implicherebbe creare 46-47 nuove forme nel pbs pokemonforms per ogni pokemon. Anche riciclando gli sprite è un sacco di lavoro, per questo pensavo fosse più facile gestire separatamente l'aumento di stats

[Artes]

Per quanto riguarda creare il PBS con le megapietre come funzionerebbe?
Prendo l'array dei miglioramenti e gli faccio leggere l'input da file? Come faccio a fargli interpretare i valori del pbs in Ruby? In C ho un'idea vaga ma non so quanto sia diverso questo linguaggio.

Io creerei un file PBS inserendo delle righe del tipo:
<indice della riga>, <identificatore della megapietra>, <miglioramento PS>, <miglioramento attacco>, <difesa>, <velocità>, <attacco speciale>, <difesa speciale>
Ad esempio,
1, :CHARIZARDITEX, 0, 46, 0, 33, 21, 0
immaginando che la Charizardite X dia le stesse variazioni delle statistiche che dà a Charizard.

Poi bisogna impostare una funzione per leggere il file PBS (.txt) e convertirlo in un file .dat (ti puoi ispirare alla funzione pbCompileItems, ipotizzando che utilizzi la versione 17.2 di essentials - NB: nelle ultime versioni di Essentials hanno cambiato molti identificatori, per cui quanto scrivo potrebbe non essere compatibile con tali versioni). Quindi, si legge il file .dat (confesso che non mi è molto chiaro il motivo di questo passaggio; suppongo che per il programma sia più facile leggere un file .dat, e che quindi cerchi di minimizzare l'apertura di file .txt).

A questo punto, invece di modificare la funzione CalcStats, forse è più conveniente modificare la funzione baseStats di PokeBattle_Pokemon. Nota, tuttavia, che tale funzione non ha argomenti, per cui occorre inserire una variabile (e.g., "mega") come attr_accessor (o anche attr_reader, se ti vuoi complicare la vita) nella classe PokeBattle_Pokemon, in modo da far sapere alla funzione CalcStats quali siano i miglioramenti da applicare. Quindi, ipotizzando che la variabile mega contenga la stringa [0,46,33,21,0,0] di sopra, si modificherebbe la funzione

Codice:

  def baseStats
    dexdata=pbOpenDexData
    pbDexDataOffset(dexdata,self.fSpecies,10)
    ret=[
       dexdata.fgetb, # HP
       dexdata.fgetb, # Attack
       dexdata.fgetb, # Defense
       dexdata.fgetb, # Speed
       dexdata.fgetb, # Special Attack
       dexdata.fgetb  # Special Defense
    ]
    dexdata.close
    return ret
  end

nella funzione

Codice:

  def baseStats
    dexdata=pbOpenDexData
    pbDexDataOffset(dexdata,self.fSpecies,10)
    ret=[
       dexdata.fgetb, # HP
       dexdata.fgetb, # Attack
       dexdata.fgetb, # Defense
       dexdata.fgetb, # Speed
       dexdata.fgetb, # Special Attack
       dexdata.fgetb  # Special Defense
    ]
    dexdata.close
    return ret + @mega
  end

Ovviamente la variabile mega va inizializzata a [0,0,0,0,0,0]. Puoi controllare se un pokémon è megaevoluto controllando, quindi, se mega è [0,0,0,0,0,0] o no: in questo modo puoi controllare di non far megaevolvere ulteriormente un pokémon, aggiungendo un controllo sulla funzione pbCanMegaEvolve? del tipo

Codice:

return false if @battlers[idxBattler].pokemon.mega != [0,0,0,0,0,0]

Per quanto riguarda idxbattler, è semplicemente l'indice del pokémon nella squadra ("idx" sta per "index"), quindi @battlers[idxBattler] è semplicemente il pokemon a cui ci si riferisce (attenzione, però: non è il pokémon "base" della classe PokeBattle_Pokemon, ma quello da usare il battaglia, della classe PokeBattle_Battler, per cui le varie funzioni della classe PokeBattle_Pokemon vanno applicate a @battlers[idxBattler].pokemon, che è il pokemon "base").

Per quanto riguarda il cambio di forma, non mi sembra che sia complicato: basta effettuare un controllo: se il pokémon ha una forma megaevoluta corrispondente a quella megapietra (e suppongo che dipenda dalla megapietra, altrimenti pokémon come Charizard e Mewtwo sarebbero intrattabili), allora effettua un cambio di forma (tuttavia, per evitare noje, conviene togliere i cambi delle statistiche alla nuova forma e applicarlo manualmente - in caso contrario, sarebbe difficile gestire la variabile mega) e un cambio delle statistiche di base, altrimenti effettua solo un cambio delle statistiche di base.
Quindi bisogna cambiare una montagna di funzioni (tipo isMega?, makeMega, etc.). Oppure, meglio, occorre creare dei doppioni (sì, appesantisce il codice, ma andare a scorporare tutto quello che si riferisce al vecchio sistema delle megaevoluzioni è molto più complicato). Se non sbaglio, occorre alla fine della battaglia resettare eventuali megaevoluzioni, in modo da evitare che i pokémon restino megaevoluti anche dopo la battaglia (?).

Per quanto riguarda il controllo @megaEvolution[side][owner]!=-1, a giudicare da come viene usato, posso dire: "side" è 0 se il pokemon appartiene al giocatore (o a un suo alleato), 1 altrimenti; "owner" indica l'allenatore a cui appartiene il pokémon da megaevolvere (è inserito per via delle battaglie in doppio, in cui ciascun allenatore, anche dalla stessa parte, può megaevolvere un pokémon); -1 è il valore che indica che non è stata effettuata alcuna megaevoluzione (diventa -2 se viene effettuata e poi eliminata una megaevoluzione, e diventa l'indice del pokémon megaevoluto se tale pokémon è megaevoluto, fin tanto che è megaevoluto). Il tutto condito da una serie di controlli relativi all'uso e alla presenza di strumenti, allo scambio di pokémon, etc.

[MegaTorterra]

Dunque, qualche domanda preliminare, poi mi metto ad implementarlo e vedo se ho problemi.
Nel pbs aggiungerò anche le abilità ed eventuali cambi di typing.
Suppongo che per effettuare queste variazioni io debba andare nella sezione dove definisce abilità e tipo e fare modifiche simili a quelle di base stats?
La @ indica che sta richiamando una variabile definita altrove?
Per aggiungere anche le forme primal mi basta andare a modificare la parte che chiede se può archeorisvegliare e poi usare le stesse funzioni della mega?

[MegaTorterra]

Un esempio di stringa potrebbe essere questo?
1,Beedrillite,60,0,-30,0,70,Adaptability,,11
in ordine:
indice,nome,atk,def,spa,spd,spe,abilità,secondotipo,peso

In caso posso droppare il peso che serve a poco.

Ah, ecco, forse devo mettere speed prima di special attack perché essentials è una bestia di satana e mette prima quella

[Artes]

La @ indica che sta richiamando una variabile definita altrove?

La @ indica che stai usando una variabile interna alla classe. Ad esempio, nella classe PokeBattle_Pokemon c'è una variabile attr_reader(:totalhp). attr_reader vuol dire che è di sola lettura, totalhp è il nome. Se stai lavorando dentro una classe, ad esempio all'interno di una funzione della classe PokeBattle_Pokemon, la variabile totalhp va richiamata con @totalhp. Se, invece, hai l'istanza di una classe (diciamo "pkmn"), allora la variabile si richiama con pkmn.totalhp. Ovviamente, questa variabile è in sola lettura, per cui il comando "pkmn.totalhp = 0" restituisce errore, mentre il comando @totalhp = 0 non restituisce errore (se compare all'interno della classe PokeBattle_Pokemon, altrimenti restituisce errore).

Suppongo che per effettuare queste variazioni io debba andare nella sezione dove definisce abilità e tipo e fare modifiche simili a quelle di base stats?

Sempre all'interno della classe PokeBattle_Pokemon. Però in questo caso la faccenda è più delicata, in quanto occorre memorizzare l'abilità precedente. Per il tipo questo non sarebbe strettamente necessario, ma si rischia di fare pasticci con pokémon con forme diverse (e.g. Rotom). Lo stesso per il peso.

Per aggiungere anche le forme primal mi basta andare a modificare la parte che chiede se può archeorisvegliare e poi usare le stesse funzioni della mega?

Cioè, in sostanza vuoi ammettere una forma primal per tutti i pokémon? Sarebbe interessante immaginare un Surskit con la forma primal di Groudon (molto difficile da usare, per via dell'abilità). O un Magcargo con la forma primal di Kyogre. Francamente, se vuoi fare un pot-pourri con tutti i vari potenziamenti, tanto vale che butti via quello che è stato fatto prima e parti "da zero" creando una "nuova" meccanica. Non mi sembra che abbia molto senso distinguere una forma mega da una forma primal se non si escludono a vicenda e se ne possono avere quante se ne vuole.

Un esempio di stringa potrebbe essere questo?
1,Beedrillite,60,0,-30,0,70,Adaptability,,11
in ordine:
indice,nome,atk,def,spa,spd,spe,abilità,secondotipo,peso

Noto che manca la statistica ps/hp. Ad ogni modo, conviene rispettare l'ordine (assurdo, concordo) usato da Essentials e scrivere (hp,) atk, def, spe, spa, spd. Tuttavia, scriverei :BEEDRILLITE e :ADAPTABILITY (se usi la versione 17.2, in quanto sono i nomi usati dal programma; per le nuove versioni la faccenda è diversa, perché hanno deciso di cambiar nome a tutto)

Concludo con una visiona alternativa del problema.
Al contrario di quanto asserito prima, si può mantenere la vecchia impalcatura, semplicemente eliminando ogni riferimento al problema della molteplicità delle megaevoluzioni/forme primal e chiedendo al compilatore di usare lo sprite normale per la forma mega/primal se questo non esiste, o non è associato alla corretta megapietra. Tuttavia, bisogna comunque ristrutturare un po' di cosette.

P.S.: devo segnalare un errore di interpretazione sul significato di @megaEvolution[side][owner]: esso è -1 se non sono state effettuate megaevoluzioni, può diventare (temporaneamente) l'indice del pokémon candidato ad effettuare la megaevoluzione, ed è -2 se è stata effettuata una megaevoluzione (per cui non è possibile effettuarne altre).