giver

EDIT - @ Guardian qua sotto . . . - Voleva essere solo un OT scherzoso "al traino" della tua battuta, comunque . . .

Non cambia il modo di funzionare del programma, ma devi usare appunto la variabile indicata, che puoi scegliere tu, modificando l'81 . . . Per chiamare una picture oltre la venti devi appunto usare un Cambia Variabile, a cui assegni il numero del "layer", maggiore di 20, che vuoi far avere a quella picture, quindi usare subito di seguito un qualunque comando picture, e lo script applicherà quel comando alla picture indicata appena prima nella variabile invece che in quella indicata dal comando . . . Per poter utilizzare il pannellino dei comandi normalmente, per le prime 20 picture, basta assegnare alla variabile un valore minore di 21 prima di sfruttare un qualunque comando picture . . .

Ho dato un'occhiata molto superficiale alle immagini che hai postato . . . Nel VX l'opzione delle IF si avvera quando il tasto viene tenuto premuto per un periodo più o meno "lungo", non registra il classico "tap istantaneo" . . . Forse è quello il problema. Comunque, ti consiglio di spostare la chiamata al menù in caso di tasto premuto in un evento comune, che oltre ad essere più ricettivo vale per tutte le mappe e non solo in quella dove hai messo l'evento mappa che intercetta l'input . . . Poi, prova ad usare la IF sfruttando l'opzione script (nell'XP è nel 4° pannellino della IF, nel VX non lo so), e scrivere nel campo di testo Input.trigger?(Input::B) E la disattivazione del Menù normale basta farla una volta ad inizio gioco . . .

Per gli MP potrebbe usare una skill a cosro 0 MP che nell'evento comune associato, tramite comandi evento, sottrae HP per "convertirli" (aggiungere) MP . . .

Credo che sia più una cosa da risolvere tramite motore particellare che non con una maschera . . . Anche perchè da una discussione di tre anni fa circa, per il tool sarebbe troppo pesante gestire in real time una maschera per ogni elemento che può smuovere la nebbia . . . Magari qualche weather/climate system di quelli già esistenti prevede qualcosa del genere . . .

Dal codice sembra che vada avanti finchè non viene premuto Invio o la Barra Spaziatrice, e dopo dovrebbe passare al Title . . .

Se fai uso del sistema dei drop, per resettare il conteggio basta, ad inizio missione, mettere in una variabile "Già Posseduti", il numero del tipo di drop in inventario che ha che fare con la missione, ed aggiungerlo al target della missione . . . Quindi l'obbiettivo diventerebbe 13, ad esempio, se la missione ne prevede 10 ed il giocatore ne possiede già 3 . . .

C'è il fatto che i drop non vengono assegnati in caso di fuga, ma mi sembra migliore perchè è giusto che ti vengano conteggiate solo le uccisioni che puoi dimostrare . . . E, comunque, se ho capito cosa ha fatto tidus, non dovrebbe funzionare per l'ultima uccisione di ogni battaglia, a meno che non abbia una patch particolare per lo script di battaglia . . . Se la battaglia include 3 mostri e la vince, incrementando le uccisioni tramite le pagine evento nel DataBase, gliene verranno conteggiate solo due . . .

Il sistema basato sui drop l'avrei proposto anch'io, come ho fatto per un altro utente nella sezione VX*, ma non l'ho fatto per via del limite di un drop per mostro dell'XP, contro i due per mostro del VX . . . * AP random ad eventi per RmVX @ RPG2S Comunque l'idea originale di questo sistema era di Alex_Rowe, diversi anni fa . . .

Snippet che dovrebbe permetterti di usare il metodo di Tidus26 anche con le battaglie casuali . . . Va messo SOTTO gli script legati alla battaglia, nello Script Editor . . . Non è stato testato . . . #========================================================== # * POST-BATTLE EVENT CALL # Chiama un evento comune dopo ogni battaglia, di cui registra # il risultato tramite alcuni switch # # by giver - datecode 20111210.99 #========================================================== # class Scene_Battle # # ID della variabile dove viene conservato l'ID nel DataBase # dell'ultimo Gruppo di Mostri combattuto TROOP_VARID = 100 # ID degli switch che registrano Vittoria, "Fuga" e Sconfitta WIN_SWCID = 100 ABORT_SWCID = 101 LOSE_SWCID = 102 # CANLOSE_SWCID = 104 # ID dell'evento comune chiamato a fine battaglia CEID_CALL = 20 # (alias giver_pbec_scbttl_main main) unless $@ # # Registra l'ID della battaglia nella variabile configurata # e resetta gli switch vittoria-fuga-sconfitta def main $game_variables[TROOP_VARID] = $game_temp.battle_troop_id $game_switches[LOSE_SWCID] = false $game_switches[ABORT_SWCID] = false $game_switches[WIN_SWCID] = false giver_pbec_scbttl_main if $scene.is_a?(Scene_Gameover) and $game_switches[CANLOSE_SWCID] and $game_temp.battle_proc == nil $scene = Scene_Map.new $game_switches[LOSE_SWCID] = true end end # (alias giver_pbec_scbttl_bttlend battle_end) unless $@ # # Prepara la chiamata all'evento comune # ed imposta gli switch win-abort-lose def battle_end(result) $game_switches[LOSE_SWCID] = (result == 2) $game_switches[ABORT_SWCID] = (result == 1) $game_switches[WIN_SWCID] = (result == 0) $game_temp.common_event_id = CEID_CALL giver_pbec_scbttl_bttlend(result) end # end EDIT - Avevo invertito i result di vittoria e sconfitta, ed ho aggiunto la possibilità di perdere senza gameover una battaglia casuale, cosa che mi sono accorto non possibile di default . . . Continua a non essere testato . . . E' sfruttabile anche per cose differenti da questa . . .

Mi sembra che in ProgettOne, il negozio funzionasse proprio così . . . Non sono sicuro, ma credo che lo script relativo faccia parte della KGC Script Library . . .

Premetto che ho solo leggiucchiato alcuni degli ultimi post . . . Sai per caso se sfruttano la generazione di Bytecode introdotta dalla 1.9.x ? Poi, vorrei sapere se supporta sonoro multi-canale e/o si possono gestire i canali separatamente come avveniva con gli rm2kX . . . Ringrazio anticipatamente chiunque voglia rispondere . . .

Potresti postare (un'immagine con) il codice dell'evento comune ?

Visto che hanno modificato anche il ruby, direi c/c++, assieme, opinione diffusa, alla libreria GDI+ . . . Ma si tratta di una scelta filosofica, più che di una necessità, dato che lo potresti fare anche con HTML, CSS e JS, volendo . . .

Di solito vengono infatti usati i FACE dei personaggi invece di battlers, anche se mi pare che di alcuni, ufficiosamente, siano stati proprio realizzati "omini" da usare nella versione frontale con party visibile . . .

Per farlo, si può fare, ed è pure relativamente semplice, ma dipende un po' anche dal BS usato . . . Che Battle System usi ? Dove posso trovare la versione dello script che usi ? EDIT - Mi sono accorto ora che hai detto di usare il BS starndard frontale del VX . . . Se hai un minimo di pazienza te lo modifico io . . .

Non essendo un problema che mi è capitato spesso, non mi ricordo bene come si rimedia . . . Mi pare che per certi CHM sia necesario cliccare col destro del mouse sul file e scegliere l'opzione SBLOCCA . . .

E' fattibile ad eventi tranne ovviamente la parte del menù, a meno di fare ad eventi anche quello . . . Non so se il VX abbia lo stesso difetto dell'XP per gli eventi di battaglia legati all'ultima uccisione, che non scattano, altrimenti per assegnare gli AP si potrebbe usare un evento di battaglia che scatta con l'uccisione di uno specifico nemico, e mostra un normale messaggio con gli AP ottenuti per quell'uccisione . . . In caso abbia lo stesso difetto dell'XP, invece, la via più semplice è sacrificare uno dei drop del mostro (esistono script che li portano a più dei due di base), creando oggetti "a-b AP", che apparirebbero perciò nell'elenco delle ricompense di fine battaglia . . . Tali oggetti non dovrebbero essere mai utilizzabili dal giocatore, ma vanno consumati da un evento comune in processo parallelo, che verifica se tali oggetti sono posseduti dopo la battaglia e genera gli AP attravero un normale Cambia Variabile . . . E' probabile che all'inizio di ogni battaglia sia necessario inserire un evento che mette ON uno Switch, quello che eventualmente fa partire il processo parallelo degli AP, e che l'evento comune, finito il proprio lavoro lo rimetta OFF . . . La creazione di quella finestra per il menù non dovrebbe portare via più di qualche minuto . . . Per dirti come fare il tutto solo tramite script, dovrei comunque riguardarmi la documentazione del VX, ed al momento non ne ho il tempo . . .

E' stato spiegato molto tempo fa, in gran dettaglio, per un sistema di Opzioni in cui a seconda degli switch risultavano appunto ON o OFF . . . Provo a riassumere, ma approfondire cercando quella spiegazione certo non guasterà . . . Per verificare se uno switch è ON if $game_switches[ID_SWITCH_SENZA_ZERI] # Oppure if $game_switches[ID_SWITCH_SENZA_ZERI] == true Un esempio in cui mettiamo il nome del primo comando della lista a seconda se lo switch 10 è ON o OFF if $game_switches[10] # Se lo switch 10 è ON s1 = "A1" else # se invece è OFF s1 = "A2" end Però, così, cambia solo il nome del comando a seconda dello switch, non la sua funzione, quindi dobbiamo andare a modificare anche il codice delle funzioni attivate quando viene scelto quel comando . . . Continuando con l'esempio precedente, andiamo a cercare il blocco di codice che gestisce le funzioni del comando, che dovrebbe cominciare, di solito, con case @command_window.index . . . All'interno del when legato al comando, ossia quello che ha valore pari a posizione del comando nella lista meno 1, che in questo caso è 0, trattandosi del primo comando, inseriamo un blocco simile a quello per il nome nella lista case @command_window.index when 0 if $game_switches[10] # Se lo switch 10 è ON # Istruzioni per quando s1 è "A1" else # se invece è OFF # Istruzioni per quando s1 è "A2" end when 1 Dovrebbe essere tutto. Non è difficile . . .

R: E' dovuto al fatto che il primo chip del livello alto non è del colore di trasparenza come dovrebbe essere l'ultimo del livello basso . . . In altre parole, quando importi devi scegliere l'ultimo chi di livello basso per indicare il colore di trasparenza ed il primo chip del livello alto va riempito completamente con tale colore . . .

Il DataBase è composto da files con specifiche definite dalla Enterbrain, al cui interno sono memorizzati degli Hash (modificati ?) ruby i cui valori sono istanze di oggetti ruby . . . Gli oggetti ruby sono delle Struct C, comunque, basta vedere i sorgenti del linguaggio per capirlo . . .

I pannelli del DataBase in realtà hanno la key 0, che di base dovrebbe valere nil, ma per qualche ragione che non conosco quelle del tuo DataBase tirano fuori quel 4 . . .

@JackX: Per il mio stile di programmazione, pur senza esagerare, è preferibile mantenere l'incapsulamento delle funzioni di una classe . . . @Holy87, riguardo l'assenza del metodo serup è normale, ma non ha senso resettare un PG che non è mai entrato in gioco, o no ? Comunque, per "risolverla", basta mettere un unless in coda all'istruzione che fa il reset . . . class Game_Actors def reset_actor(actor_id) @data[actor_id].setup(actor_id) unless @data[actor_id].nil? end end O, in alternativa, puoi provare a modificare il metodo aggiuntivo, così class Game_Actors def reset_actor(actor_id) @data[actor_id] = Game_Actor.new(actor_id) end end

Mi sembra invece, se non ricordo male, aggiungere un def reset a Game_Actors, più o meno su questa falsariga . . . class Game_Actors def reset_actor(actor_id) @data[actor_id].setup(actor_id) end end e richiamarlo tramite call script . . . $game_actors.reset_actor(ID_ACTOR_DA_RESETTARE) Anche se così facendo dovrebbe tornare equipaggiato come indicato nel DataBase . . . EDIT - Per il call script avevo scritto solo reset invece di reset_actor . . .

Le classi nascoste non sono in rgss, ma in misto ruby+c . . . Per vedere come è fatta realmente dovresti decompilare la DLL di rpg maker . . . anche se sono stati spiegati trucchi per ricavare informazioni su tali classi . . . Esistono delle rewrite di alcune delle classi nascoste scritte completamente in ruby/rgss, inclusa Tilemap, ma si capisce che sono state scritte sulla base di ipotesi di uso dei parametri passati più che sull'effettiva conoscenza del codice interno originale visti certi bug che risultano dal loro utilizzo . . . Personalmente di consiglio di guardare la rewrite fatta per il Pokemon Starter Kit, se non vuoi imbarcarti nello studio della versione originale compilata . . .