giver

Probabilmente gli dice che non esiste il metodo actor_id . . . Ho fatto confusione perchè la proprietà interna si chiama appunto @actor_id, mentre il metodo per leggerla si chiama semplicemente id . . . Ho corretto il codice sopra, e quell'errore dovrebbe svanire . . .

Ma, lol, credevo che le immagini fossero parte della Window_Command, invece si tratta di un sistema "artigianale" . . . Allora basta che la sposti fuori schermo, con @command_window.x = -200 (per dove scriverlo, guarda il codice simile usato per le altre finestre del menù)

Se la visibilità dei comandi non è legata a quella della finestra, potresti vedere se risolvi usando l'istruzione @command_window.visible = false (dopo averla creata, ovviamente), perchè non so se renderla invisibile le fa perdere lo status active, che aggiorna la selezione quando si premono i tasti . . . EDIT - Potresti provare a cercare in rete la demo Win Layout Experiment di Alex_Rowe, che includeva la possibilità di avere comandi grafici, anche con più stati (abilitato, disabilitato, selezionato, ecc) . . . Ma l'aveva postata su Makerando nel 2006, quindi le probabilità di trovarla non sono molte . . . Magari ce l'ho in un vecchio backup . . . Provo a controllare non appena ho un po' di tempo da sprecare . . . EDIT 2 - Solo per segnalare che Alex_Rowe si era ribattezzato Vincent Law, quindi, negli archivi Internet potrebbe apparire con quel nick invece di quello originale . . .

Ehm . . . Mi dovresti anche dire però come ti aspetti che debba apparire la versione "giusta" . . . Va più che bene un mockap o uno schizzo del risultato che vuoi ottenere . . . @Guardian, credo che intenda azzerare l'opacità delle finestre perchè altrimenti coprono i comandi. Anche se qualche post di quella discussione col tutorial indica come rimediare, ossia agire sui valori z degli elementi coinvolti . . .

Per il title ad immagini c'è lo script di CCOA, piuttosto vecchio ma fa comunque la sua figura .. . . Non ho presente il tutorial di Tio, anche se ho vaghe memorie di averlci dato un'occhiata in passato . . . Ti è possibile linkarlo ? E non ho ben capito la questione degli oggetti, quindi vorrei che postassi uno screen a riguardo, magari . ..

Mi son dimenticato di chiedere se usi uno script per party esteso . . . Comunque, ho realizzato al volo questo snippet, che va configurato elencando gli id degli actors che causano gameover alla morte (di base è indicato quello con id 1 nel DataBase . . . Come al solito, va messo almeno sotto gli script di BS e gestione particolare del party, e NON è testato . . . EDIT- Lo snippet è stato eliminato da questo post in quanto presentava un bug, per evitare confusione, poichè ne è stata postata la versione corretta più sotto . . .

Non dovrebbe essere particolarmente difficile . . . Che Battle System usi, che non ce l'ho presente ?

C'è listruzione per rimuovere l'actor . . . La trasformazione non può essere fatta in battaglia . . . L'actor non deve avere un ID indicato nella lista restricted (se non l'hai cambiato, c'è quello con ID 1) . . . L'oggetto che trasforma deve avere la notetag <snapdragon> . . . L'oggetto ottenuto dalla trasformazione non va aggiunto tramite l'evento comune di quello che trasforma . . . Lo script sta al di sotto di quelli del BS, suppongo . . .

Hai configurato per bene lo script ? C'è una parte in cui devi associare ogni actor ad un oggetto (che può essere anche una skill o un evento comune), il quale va definito per tipo ed ID . . . N.B.: Non ho controllato se manca il codice per levare l'actor, ma nelle istruzioni c'è scritto di sì . . .

Se switch della categoria è ON spegni questi effetti, altrimenti accendili, scorrendo l'intera lista di effetti . . . E per vedere quali effetti vanno accesi o spenti, next se effect.type è in elenco appropriato, ossia i controlli fatti da me, solo separati tra le categorie, quindi altre 4 if, contro la mia singola . . . Ed ho segnalato altri modi per rendere il codice ancora più efficace . . . Quel codice l'ho creato al volo, modificando alla buona quello otiginale, anche perchè mi sembra inutile perderci troppo tempo per soluzioni più efficaci ma lunghe da ri-scrivere, visto che, come hai detto tu, si è scelta un'altra strada . . .

@Guardian: Certamente . . . Eliminare quel pezzo e sostituirlo con questo . . . def update_light_effects ################################################################################ swc_fire = !$game_switches[FIRE] swc_light = !$game_switches[LIGHT] swc_ground = !$game_switches[GROUND] scw_torch = !$game_switches[TORCH] for effect in @light_effects effect.light.visible = (effect.type == "FIRE" && swc_fire) or (swc_light && (effect.type == "LIGHT" or effect.type == "LIGHT2" or effect.type == "LIGHT3")) or (scw_ground && (effect.type == "GROUND" or effect.type == "GROUND2" or effect.type == "GROUND3" or effect.type == "GROUND4" or effect.type == "GROUND5")) or (swc_torch && (effect.type == "TORCH" or effect.type == "TORCH2" or effect.type == "TORCH3")) end Naturalmente sarebbe meglio ancora creare dei filtri specifici per categoria, mantenendo gli switch, o uno solo aggiornabile tramite (call) script, ed eliminare gli switch . . . @clyde: Li ho letti, ma è più forte di me . . . Comunque lo è sì "migliore", in quanto basta vedere che il mio esegue un solo ciclo, mentre l'originale scorre la lista degli effetti per ogni categoria di effetto, quindi ben 4 volte, passando da altrettanti if-else . . . EDIT - Avevo lasciato un != al posto di un ==, EDIT2 - ed un end di troppo, mi sa . . .

Scusate, centra poco col problema di Izel, ma . . . Questo pezzo dell'Edison sembra altamente inefficiente, vengono eseguiti update degli effects per ogni switch di categoria . . . Credo che sarebbe meglio sostituirlo con un solo ciclo di tutti gli effetti con next per ogni accoppiata "switch & effect" . . . EDIT - Rewrite del Thomas Edison VX - Non Testata - Ma se funziona, le prestazioni miglioreranno di parecchio . . .

R: Non c'è bisogno di accedere al vero menù, basta che fai uno o più screenshot dello stesso e tramite Mostra Picture, quindi su Mappa, simuli la sua navigazione ed inserisci dei normali "dialoghi" quando vuoi spiegare qualcosa per iscritto . . .

Disegna l'icona ingrandita perchè nell'item non c'è una notetag che indica un'immagine da utilizzare in alternativa, da mettere nella cartella delle Pictures . . . Non ho idea di come debba essere scritta tale notetag, comunque, non usando l'ACE o gli script di Yanfly . . . Almeno questo è ciò che ho capito dalla lettura del codice . . .

I tasti Funzione potrebbero andare ?

Lo so, ma bisogna ricordarsi di non usare tali variabili col Cambia Variabile . . . Puoi per di più aggiungere metodi nuovi ad una classe che venga già salvata invece di usare alias per Scene_File e nuove globali, ad esempio in Game_Variables stessa, volendo . . . Inoltre, bisogna comunque insegnare come "popolare" l'Array o l'Hash e gestirsi la cosa . . .

Sì, ok, non mi piace come cosa (io creerei una classe apposta per memorizzare tali informazioni, improprie per Game_Variables, pensata per contenere delle Intere), ma si potrebbe fare così . . . Ovviamente, non nominando la variabile $game_variables visto che così va a sostituire quella del programma . . .

R: Allora, è lunghetto ma estremamente semplice . . . Bisogna creare una variabile-evento per ogni oggetto che il giocatore può raccogliere prima di essere arrestato Quando viene arrestato si esegue un evento che: a) Mette in ciascuna variabile, tramite il comando Cambia Variabile, la quantità dell'oggetto associato. b) Usando il comando Cambia Oggetto (o Cambia Armi o Cambia Armatura), togli dall'inventario ciascun Oggetto (o Arma o Armatura) indicando la quantità da sottrarre tramite le Variabili impostate prima . . . Quando raggiunge dove è conservato l'inventario tolto, riutilizzi il comando Cambia Oggetto per aggiungere all'inventario ciascun oggetto, sempre usando la quantità indicata nelle Variabili di prima . . .

Io ho sempre usato The Gimp, in versione portable per Windows, soprattutto di recente che sul mio PC sono "costretto" a usare, causa HDD "rotto" (inutilizzabile per Windows, a volte sì a volte no con Linux), una Distro di Linux, visto che è un software nativo di questo OS . . . EDIT - Per quello che riguarda Pixia, per gestire la tolleranza cromatica in modo "semplice", magari puoi selezionare con la bacchetta magica prima di usare la gomma (e se il programma è buono come dicono, dovrebbe permetterti di scegliere il pennello con cui cancellare) . . .

Pixia è molto popolare in Giappone, e per quel poco che ne so è abbastanza potente come programma di fotoritocco, tenendo conto che è gratuito . . . Comunque, se ti "accontenti" di un fatto-da-te in tempi brevi, potresti provare a modificarlo così: Lo apri con Pixia Crei un nuovo Layer Copi l'immagine originale e l'incolli nel Layer appena creato Elimini con la Gomma, nella copia, la parte che NON vuoi modificare . . . Crei un nuovo Layer, e ci copi-e-incolli la versione "bucata" dell'immagine . . . Nascondi l'ultimo Layer creato Usi un singolo colore, senza preoccuparti delle ombre, per ricolorare cappuccio e un altro per il bordo Fai ricomparire il Layer nascosto precedentemente e lo "transparentizzi" parzialmente, ossia lo rendi semi-trasparente, magari, opzionalmente, dopo averlo reso in scala di grigi, per recuperare l'ombreggiatura senza doverla ridisegnare . . . Fondi assieme i Layers e Salvi con Nome . . . EDIT - Invece di Crea Layer + Copia-e-incolla Contenuti, si può ovviamente usare Duplica Layer, se il programma supporta tale funzione . . .

A leggere le istruzioni, che comunque sembrano molto semplici, ho capito così: In MOUSE_ICON si crea una lista "parola chiave" => "nome icona usata dal mouse" Per fare in modo che il mouse assuma una certa icona, bisogna mettere nel "codice" dell'evento-mappa interessato un Comment con la parola chiave, priva di virgolette, a cui è stata associata la grafica che si vuole appaia come puntatore . . . (Quindi la parola chiave "NPC" va scritta NPC nel Comment, e su tale evento il mouse avrà la grafica "Arrow-Event" . . .) Le icone devono essere di 24x24 pixels, nella cartella Graphics/Icons, come quelle degli items e delle skills . . .

Attenzione, però, che se più aree si sovrappongono, viene usata quella di ID più basso per stabilire il fondale . . . EDIT- Quindi, per ogni mappa, andrebbero definite le aree in quest'ordine: Aree Battaglie Chiamata da Evento -> Aree Battaglie Casuali Aree -> Area Battaglie Mappa . . . In più, tutte le aree non indicate nell'Hash di configurazione useranno il fondale indicato per l'area 1 . . .

Anche tu quasi solo (call) script + scripts, "cricetino" ?

Potresti mettere nell'avento comune di attacca un controllo se l'arma equipaggiata prevede munizioni e se il "party" ne possiede: però sarebbe necessario che tali armi non avessero alcun effetto di base, e venisse implementato tutto l'effetto nell'evento comune di attacca se si dispone di munizioni, sottraendone quindi una . . . Ma non so quanto gli eventi dell'ACE consentano di emulare gli effetti previsti per le armi . . . Tra l'altro, roba lunghetta da progtammare, seppur non difficile . . . Probabilmente, meglio usare direttamente lo script di Yanfly . . .

D: Pura curiosità. Chiedo a chi lo usa, visto che la trial mi è scaduta e 'sta cosa mi è venuta in mente solo adesso. L'evento Cambia Variabile dell'ACE prevede un'opzione per mettere un valore indicato da "script" (tipo quello delle IF) ?