giver

Non c'è bisogno di uno script, lo puoi già impostare (attivare/disattivare) nella pagina evento, con una delle opzioni sotto il riquadro con la gtafica usata per l'evento) o come passo nell'opzione Segui Percorso, e/o attraverso un passo del comando-evento Muovi Evento (quest'ultima, quindi, funziona anche per l'eroe/player) . . . EDIT - Tecnicamente, se non ricordo male, si può fare anche usando la Muovi Evento e non abilitare l'opzione ignora se bloccato . . .

Potrebbe essere un'alternativa agli event balloons di Sleeping Leonhart . . .

Diciamo che per ovviare, basta andare nel codice di Window_BattleResult, e, all'interno del def initialize, subito dopo l'istruzione super o prima dell'istruzione refresh, scrivere self.z = 9998 Mi sono inoltre accorto che c'è un altro bug nella parte di codice fatta da valentino, che genera errore se il mostro non ha drop aggiuntivi, quindi ecco un'altra revisione del suo script

Strano, nè la BattleResult nè start_phase5 cambiano la z della finestra, quindi è un problema che già doveva esistere prima della mia revisione dello script . . . Comunque, ecco lo script modificaro per mettere la finestra dei drop in primo piano . . . EDIT2 - Eliminata anche questa revisione in quanto ho notato un altro bug nell'originale, corretto nella versione più sotto . . . EDIT - @Cloud_93: Potresti provare a vedere se senza questo script il problema si presenta comunque ?

Boh. Non posso testarlo. Vedi se questa variante funziona . . . EDIT - Versione rimossa in quanto ripubblicata più in basso, con un'aggiunta divenuta "necessaria" . . .

*AHAHAHAHAHAH !!!!!!!11111111111111111!UNO!!111!* 1) Ho guardato meglio lo script di Valentino, e, se lo hai postato completo, non aggiunge gli oggetti del multi-drop nell'inventario del party . . . 2) Non mi hai ancora detto che errore ti dà . . . Quindi, ri-chiedo, Che errore dà ? 3) Sono un rompi, lo so, ma mi potresti postare anche il def start_phase5 del CTB ? 4) Charlie ha rilasciato la 3.2 del suo BS. Stai usando quella ? Perchè da ciò che hai postato sembra tu stia usando la 3.1 . . .

Che errore ti dà ? Magari, potresti postare anche il codice della class Window_BattleResult del CTB di charlie ?

Perchè impensabile ? Non è che servono 1000 IF, ne bastano una trentina per un valore intorno a mille, usando 3 (layer) picture e non una sola (è vero che col VX ce ne sono solo 20, ma nell'ace mi pare siano 100 . . .) Se poi usi il call script per fare il mostra picture, puoi evitare tutte le IF e fare solo i calcoli necessari a ricavare ogni cifra . . . ( call script mostra picture per XP ) Come si ricava una cifra da un valore ? Semplice, si fa in modo che la cifra diventi quella delle unità, dopodichè si fa modulo 10 sul numero "aggiustato" con la cifra da ricavare . . . Ad esempio, se dobbiamo ricavare la cifra delle centinaia, si divide il valore per 100, poi si fa modulo 10 del risultato . . . Un esempio, per XP, perchè non conosco l'rgss necessario a mostrare picture nell'ACE . . . Diciamo che il valore da mostrare è nella variabile 1, ed usiamo la variabile 2 per i calcoli necessari . . . Fatto. Questo codice mostra un valore di tre cifre usando altrettante picture. I valori del mostra picture sono stati messi secondo logica, ma scelti in maniera puramente esemplificativa . . .

E' il normale comportamento dello script, che non mostra la ricompensa finchè non completi la quest . . .

Ecco, prova un po' se funziona . . . Quello di prima è un metodo per newbies dello scripting che amano arrangiarsi da soli . . .

Scusa, non mi ero accorto di questa discussione . . . Vediamo se ho capito: vuoi che le Quest abbiano le caratteristiche indicate da una serie di valori numerici invece che basate solo sull'ID . . . Es.: Adesso è come se si indicasse Quest.add(1, 1, 1, 1, 1), ossia tutti i parametri indicati per il case uguale all'ID, mentre tu vuoi che sia possibile indicare una cosa del tipo Quest.add(1, 1, 2, 8, 5) . . . Oppure vuoi semplicemente separarle per livello di difficoltà ? Appena mi chiarisci questo punto, avendo perso una scommessa, ti modifico lo script come appropriato . . . Ti avverto che al momento non sono nella possibilità di testarlo . . . EDIT - Nel secondo caso potresti rimediare da solo, riscrivendo il metodo (def) qdifficoltà

Infatti, come dice kingartur2, sia l'hud che il ciclo giorno-notte lo puoi fare ad eventi, con maggior controllo rispetto ad uno script . . . Anche visto l'effetto collaterale del metodo on_change, che viene eseguito pure agendo dagli altri script . . .

Ma lo hai fatto nello script ? Quando si usa uno script di ciclo giorno-notte nella maggior parte dei casi non è più possibile impostare lo screen tone tramite eventi . . . Da un'occhiata superficiale, sembra essere così anche per questo script . . . Se mi posti la versione che usi, magari rendo disattivabile l'impostazione automatica dello screen tone basata sulla fase del giorno . . . Dovrebbe bastare l'aggiunta di un altro switch . . .

Io lo chiamerei più "ripartire da un salvataggio precedente alla modifica del DataBase" . . . Quel personaggio, essendo entrato in gioco, e già stato aggiunto a $game_actors, quindi non viene reinizializzato con i nuovi dati a meno di toglierlo dal party e riaggiungerlo spuntando l'opzione inizializza . . .

Dipende anche dal rapporto che hai col portale . . . Non tutti hanno le stesse policies a riguardo . . . Con alcuni percepisci molto in termini di percentuale, ma conti come ditta esterna, quindi sobbarcandoti tutte le spese di gestione della stessa, con altri percepisci "poco" (circa il 28% al netto di tutti i costi e tasse), ma conti come dipendente interno del portale, e con le tasse pagate da loro (o incassi il 40% e le normali tasse da lavoro dipendente sono a tuo carico) . . .

Tasse che comunque dipendono dal totale incamerato: ci sono soglie minime per cui le tasse non le devi pagare o sono in percentuale trascurabile . . . Dipende anche dai portali a cui ti appoggi, che in alcuni casi ti sottraggono già le tasse, perchè più comodo per loro stessi e per gli esattori (che non devono stare a rintracciare tutti coloro che hanno venduto presso tali portali per vedere di incassarle) . . . Poi, niente bollino SIAE . . . A chi vuole intraprendere questa strada, consiglierei di consultare anche qualche fonte sullo sviluppo dei Casual Games, che aiuta per cose come quella dei salvataggi da citata da Holy87. . .

L'App Store si tiene il 30 %, e tu intaschi perciò il 70 % . . . ossia 70 centesimi per ogni $/€ del prezzo di vendita . . . E' anche vero, però, che i costi per una produzione seria, se non si riesce ad arrangiarsi, vanno da 10000 a 500000 $/€ per ogni "giochino" . . .

Il flash character, se non ricordo male, era un "passo" del Muovi Evento, non era tra i comandi-evento come Mostra Messaggio e simili . . . Hai già guardato se c'è lì ?

Le variabili, comunque, possono essere le stesse per tutti gli oggetti da spostare, se ne puoi spostare solo uno alla volta, e lo switch legato all'oggetto in posizione, se non lo blocchi una volta raggiunto il punto corretto dove deve stare, va messo OFF se mosso fuori dalle coordinate corrette . . . EDIT - E controlla se tutti gli oggetti sono in posizione solo quando viene messo ON uno switch, ossia solo dopo che l'oggetto spostato risulta in posizione corretta . . . Ah, e fai muovere l'eroe forzatamente (Muovi Evento) affinchè segua l'oggetto che sta spingendo . . .

Il maledetto tasto F12 Comunque, indica l'esistenza dell'istanza del game.exe lanciato . . .

Eventualmente, per tagliare i costi ed evitare iscrizioni e licenze a pagamento, puoi pensare di sviluppare per lo sfruttamento online del gioco: come esiste il Flash Player, esiste anche il Webplayer di Unity, che permette di giocare nel browser con Windows e Mac . . . Un esempio di produzione Unity di questo tipo è il browser game Battlestar Galactica . . .

HTML5 è stato pensato per soppiantare Flash, ed Apple è quella che più ne ha supportato lo sviluppo, anche perchè inizialmente (poi s'è dovuta arrendere) non voleva includere il supporto a Flash nei propri prodotti . . . Permette di creare "web" app (anche offline, con Adobe AIR/Flex SDK) molto complesse, ed è utilizzato molto nello sviluppo per dispositivi mobile di ogni genere, come pure Flash stesso . . . EDIT - @Pech: Se ti accontenti di non sfruttare certe possibilità, come il multi-touch in real-time, i touch screen sono sempre stati programmabili sfruttando il codice per il mouse, quindi con qualunque "strumento" che supporti la programmazione dell'uso del mouse . . . Unity, ha una "espansione" dedicata apposta, ma costa intorno ai 400 $, se non ricordo male . . .

Ma, lol, mi sono dimenticato di averlo scritto sbagliato in due punti invece che solo alla linea 25 . . . class Game_Party < Game_Unit # Mettere gli ID degli actors che causano gameover morendo, separati da virgole GAMEOVER_ACTORS = [1] # end class Scene_Battle < Scene_Base # alias giver_remded_scnbtl_btlend battle_end unless $@ # def battle_end(result) unless (result == 2 and !$game_troop.can_lose) for battler in $game_party.members if !battler.exist? $game_party.remove_actor(battler.id) end end end giver_remded_scnbtl_btlend(result) end end class Game_Party < Game_Unit # alias giver_goverpg_gpart_allded all_dead? unless $@ # def all_dead? for battler in members if ( GAMEOVER_ACTORS.include?(battler.id) and !battler.exist? ) $game_troop.can_lose = false return true end end giver_goverpg_gpart_allded end end Adesso possono sorgere solo altri errori, non lo stesso di prima . . .

Beh, il procedimento si può dire che è lo stesso per realizzare un menù custom su mappa usando solo picture, ma usando ruby invece di comandy-evento . . . Oserei dire che complessivamente è più semplice da programmare in ruby, scrivendo molta meno roba . . . Magari, più tardi, "converto" a titolo esemplificativo il codice della command ad immagini del menù per aiutarti a capire quali differenze ci siano nella programmazione . . .

Mah, restando nell'artigianale non dovrebbe essere difficile farlo, usando i nomi degli oggetti, più suffisso, invece di indicarne la lista in un array, e suddividendo in pagine la lista o imbarcarsi in una problematica gestione dello scrolling della lista degli oggetti, qualora diventassero di più di quelli che possono stare nello spazio della finestra . . . Il codice andrebbe messo dentro le relative finestre invece che nella scena ovviamente . . .