IT | Several small improvements
This commit is contained in:
Zughy
parent
62e2d0f835
commit
704c3d84cf
@ -11,7 +11,7 @@ redirect_from:
|
||||
|
||||
## Introduzione <!-- omit in toc -->
|
||||
|
||||
Capire la struttura base della cartella di una mod è un requisito essenziale per creare mod.
|
||||
Capire la struttura base della cartella di una mod è un requisito essenziale per creare qualsivoglia contenuto.
|
||||
|
||||
- [Cosa sono i giochi e le mod?](#cosa-sono-i-giochi-e-le-mod)
|
||||
- [Dove vengono salvate le mod?](#dove-vengono-salvate-le-mod)
|
||||
@ -29,24 +29,18 @@ Capire la struttura base della cartella di una mod è un requisito essenziale pe
|
||||
|
||||
## Cosa sono i giochi e le mod?
|
||||
|
||||
Il punto forte di Minetest è l'abilità di sviluppare facilmente giochi senza il bisogno
|
||||
di crearti da zero il motore grafico, gli algoritmi voxel o tutta la parte network.
|
||||
Il punto forte di Minetest è l'abilità di sviluppare facilmente giochi senza il bisogno di crearsi da zero il motore grafico, gli algoritmi voxel o tutta la parte network.
|
||||
|
||||
In Minetest, un gioco è una collezione di moduli che lavorano insieme per fornire il contenuto
|
||||
e il comportamento di un gioco.
|
||||
Un modulo, solitamente conosciuto come "mod" (femminile), è una collezione di script e risorse.
|
||||
È possibile creare un gioco usando semplicemente una mod, ma questo non accade spesso perché
|
||||
riduce la comodità di poter sostituire o calibrare alcune parti del gioco in maniera indipendente
|
||||
dalle altre.
|
||||
In Minetest, un gioco è una collezione di moduli che lavorano insieme per fornire il contenuto e il comportamento di un gioco.
|
||||
Un modulo, solitamente conosciuto come "mod", è una collezione di script e risorse, e in teoria ne potrebbe bastare uno per creare un intero gioco.
|
||||
Tuttavia, questo non accade spesso, perché riduce la comodità di poter sostituire o calibrare alcune parti di quest'ultimo in maniera indipendente dalle altre.
|
||||
|
||||
È anche possibile distribuire le mod al di fuori di un gioco, nel qual caso sono sempre mod
|
||||
nel senso più tradizionale del termine: modifiche. Queste mod calibrano o espandono le proprietà
|
||||
di un gioco.
|
||||
È poi anche possibile distribuire le mod come a sé stanti, nel qual caso sono sempre mod nel senso più tradizionale del termine: modifiche.
|
||||
Esse calibrano o espandono le proprietà di un gioco.
|
||||
|
||||
Sia le mod presenti in un gioco che quelle a sé stanti usano la stessa API.
|
||||
Indipendentemente da come le si voglia usare (specifiche per un gioco o come estensioni generiche) usano la stessa API.
|
||||
|
||||
Questo libro coprirà le parti principali della API di Minetest,
|
||||
ed è applicabile sia per gli sviluppatori che per i creatori di mod.
|
||||
Questo libro coprirà le parti principali della API di Minetest, ed è pensato sia per gli sviluppatori del motore di gioco (Minetest, in C++) che per i creatori di mod.
|
||||
|
||||
|
||||
## Dove vengono salvate le mod?
|
||||
@ -54,37 +48,30 @@ ed è applicabile sia per gli sviluppatori che per i creatori di mod.
|
||||
<a name="mod-locations"></a>
|
||||
|
||||
Ogni mod ha la sua cartella personale dove viene messo il suo codice in Lua, le sue texture,
|
||||
i suoi modelli e i suoi file audio. Minetest fa un check in più punti per le mod. Questi punti
|
||||
sono generalmente chiamati *percorsi di caricamento mod* (in inglese *mod load paths*).
|
||||
i suoi modelli e i suoi file audio. Minetest fa un check in più punti e questi punti sono generalmente chiamati *percorsi di caricamento mod* (*mod load paths*).
|
||||
|
||||
Per un dato mondo/salvataggio, vengono controllati tre punti.
|
||||
Essi sono, in ordine:
|
||||
|
||||
1. Mod di gioco. Queste sono le mod che compongono il gioco che il mondo sta eseguendo.
|
||||
Es: `minetest/games/minetest_game/mods/`, `/usr/share/minetest/games/minetest/`
|
||||
2. Mod globali. Il luogo dove le mod vengono quasi sempre installate. Se si è in dubbio,
|
||||
le si metta qui.
|
||||
2. Mod globali. Il luogo dove le mod vengono quasi sempre installate. Se si è in dubbio, le si metta qui.
|
||||
Es: `minetest/mods/`
|
||||
3. Mod del mondo. Il luogo dove mettere le mod che sono specifiche di un dato mondo.
|
||||
Es: `minetest/worlds/world/worldmods/`
|
||||
|
||||
Minetest controllerà questi punti nell'ordine sopraelencato. Se incontra una mod con lo
|
||||
stesso nome di una incontrata in precedenza, l'ultima verrà caricata al posto della prima.
|
||||
Questo significa che si può sovrascrivere le mod di gioco piazzando una mod con lo stesso
|
||||
nome nella cartella delle mod globali.
|
||||
Minetest controllerà questi punti nell'ordine sopraelencato.
|
||||
Se incontra una mod con lo stesso nome di una incontrata in precedenza, l'ultima verrà caricata al posto della prima.
|
||||
Questo significa, per esempio, che è possibile sovrascriverne una di gioco se ve n'è una omonima nelle globali.
|
||||
|
||||
La posizione di ogni percorso di caricamento mod dipende da quale sistema operativo si sta
|
||||
usando, e come è stato installato Minetest.
|
||||
La posizione di ogni percorso dipende da quale sistema operativo si sta usando, e da come è stato installato Minetest.
|
||||
|
||||
* **Windows:**
|
||||
* Per le build portatili, per esempio da un file .zip, vai dove hai estratto lo zip e
|
||||
cerca le cartelle `games`, `mods` e `worlds`.
|
||||
* Per le build installate, per esempio da un setup.exe,
|
||||
guarda in C:\\\\Minetest o C:\\\\Games\\Minetest.
|
||||
* Per le build portatili, per esempio da un file .zip, vai dove hai estratto lo zip e cerca le cartelle `games`, `mods` e `worlds`.
|
||||
* Per le build installate, per esempio da un setup.exe, guarda in C:\\\\Minetest o C:\\\\Games\\Minetest.
|
||||
* **GNU/Linux:**
|
||||
* Per le installazioni di sistema, guarda in `~/.minetest`.
|
||||
Attenzione che `~` equivale alla cartella home dell'utente, e che i file e le cartelle
|
||||
che iniziano con un punto (`.`) sono nascosti di default.
|
||||
Attenzione che `~` equivale alla cartella home dell'utente, e che i file e le cartelle che iniziano con un punto (`.`) sono nascosti di default.
|
||||
* Per le installazioni portatili, guarda nella cartella di build.
|
||||
* Per installazioni Flatpak, guarda in `~/.var/app/net.minetest.Minetest/.minetest/mods/`.
|
||||
* **MacOS**
|
||||
@ -95,11 +82,9 @@ usando, e come è stato installato Minetest.
|
||||
|
||||
|
||||
|
||||
Il *nome mod* è usato per riferirsi a una mod. Ogni mod dovrebbe avere un nome unico.
|
||||
I nomi mod possono includere lettere, numeri e trattini bassi. Un buon nome dovrebbe
|
||||
descrivere cosa fa la mod, e la cartella che contiene i componenti di una mod deve avere
|
||||
lo stesso nome del nome mod.
|
||||
Per scoprire se un nome mod è disponibile, prova a cercarlo su
|
||||
Il *nome mod* è usato per riferirsi a una mod e ognuna di esse dovrebbe averne uno unico.
|
||||
Questi possono includere lettere, numeri e trattini bassi, e un buon nome dovrebbe descrivere brevemente cosa fa la mod (è anche consigliato nominare la cartella della mod allo stesso modo).
|
||||
Per scoprire se un nome è disponibile, prova a cercarlo su
|
||||
[content.minetest.net](https://content.minetest.net).
|
||||
|
||||
|
||||
@ -114,27 +99,24 @@ Per scoprire se un nome mod è disponibile, prova a cercarlo su
|
||||
|
||||
Solo il file init.lua è necessario in una mod per eseguirla al lanciare un gioco;
|
||||
tuttavia, mod.conf è consigliato e altri componenti potrebbero essere richiesti a
|
||||
seconda della funzione della mod.
|
||||
seconda di quello che si vuole fare.
|
||||
|
||||
## Dipendenze
|
||||
|
||||
Una dipendenza avviene quando una mod richiede che un'altra mod sia avviata prima di essa.
|
||||
Una dipendenza avviene quando una mod ne richiede un'altra da avviare prima di essa.
|
||||
Una mod potrebbe infatti richiedere il codice di quest'ultima, i suoi oggetti o altre risorse.
|
||||
|
||||
Ci sono due tipi di dipendenze: forti e opzionali.
|
||||
Entrambe richiedono che la mod richiesta venga caricata prima, con la differenza che se la
|
||||
dipendenza è forte e la mod non viene trovata, l'altra fallirà nel caricare, mentre se è opzionale,
|
||||
verranno semplicemente caricate meno feature.
|
||||
Entrambe richiedono che la mod richiesta venga caricata prima, con la differenza che se la dipendenza è forte e la mod non viene trovata, l'altra fallirà nel caricare, mentre se è opzionale, verranno semplicemente caricate meno feature.
|
||||
|
||||
Una dipendenza opzionale è utile se si vuole integrare opzionalmente un'altra mod; può abilitare
|
||||
contenuti extra se l'utente desidera usare entrambe le mod in contemporanea.
|
||||
Una dipendenza opzionale è utile se si vuole integrare opzionalmente un'altra mod; può abilitare contenuti extra se l'utente desidera usare entrambe le mod in contemporanea.
|
||||
|
||||
Le dipendenze vanno elencate in mod.conf.
|
||||
|
||||
### mod.conf
|
||||
|
||||
Questo file è utilizzato per i metadati della mod, che includono il suo nome, la descrizione e
|
||||
altre informazioni. Per esempio:
|
||||
Questo file è utilizzato per i metadati della mod, che includono il suo nome, la descrizione e altre informazioni.
|
||||
Per esempio:
|
||||
|
||||
name = lamiamod
|
||||
description = Aggiunge X, Y, e Z.
|
||||
@ -143,22 +125,18 @@ altre informazioni. Per esempio:
|
||||
|
||||
### depends.txt
|
||||
|
||||
Per questioni di compatibilità con le versioni 0.4.x di Minetest, al posto di specificare le
|
||||
dipendenze solamente in mod.conf, c'è bisogno di fornire un file depends.txt nel quale vanno
|
||||
elencate tutte le dipendenze:
|
||||
Per questioni di compatibilità con le versioni 0.4.x di Minetest, al posto di specificare le dipendenze solamente in mod.conf, c'è bisogno di fornire un file depends.txt nel quale vanno elencate tutte le dipendenze:
|
||||
|
||||
mod1
|
||||
mod2
|
||||
mod3?
|
||||
|
||||
Ogni nome mod occupa una riga, e i nomi mod seguiti da un punto di domanda indicano una dipendenza
|
||||
opzionale.
|
||||
Ogni nome mod occupa una riga, e quelli seguiti da un punto di domanda indicano una dipendenza opzionale.
|
||||
|
||||
## Pacchetti mod (mod pack)
|
||||
|
||||
Le mod possono essere raggruppate in pacchetti che permettono a più mod di essere confezionate
|
||||
e spostate insieme. Sono comodi se si vogliono fornire più mod al giocatore, ma non si vuole al
|
||||
tempo stesso fargliele scaricare una per una.
|
||||
Le mod possono essere raggruppate in pacchetti che permettono di confezionarne e spostarne più alla volta.
|
||||
Sono comodi se si vogliono fornire più mod al giocatore, ma non si vuole al tempo stesso fargliele scaricare una per una.
|
||||
|
||||
pacchettomod1
|
||||
├── modpack.lua (necessario) - segnala che è un pacchetto mod
|
||||
@ -167,8 +145,7 @@ tempo stesso fargliele scaricare una per una.
|
||||
└── mymod (opzionale)
|
||||
└── ... file mod
|
||||
|
||||
Attenzione che un pacchetto mod non equivale a un *gioco*.
|
||||
I giochi hanno una propria struttura organizzativa che verrà spiegata nel loro apposito capitolo.
|
||||
Attenzione che un pacchetto mod non equivale a un *gioco*. I giochi hanno una propria struttura organizzativa che verrà spiegata nel loro apposito capitolo.
|
||||
|
||||
## Esempio
|
||||
|
||||
@ -201,7 +178,7 @@ minetest.register_node("lamiamod:nodo", {
|
||||
descriptions = Aggiunge un nodo
|
||||
depends = default
|
||||
|
||||
Questa mod ha il nome "lamiamod". Ha tre file di testo: init.lua, mod.conf e depends.txt.\\
|
||||
Questa mod ha come nome "lamiamod". Ha tre file di testo: init.lua, mod.conf e depends.txt.\\
|
||||
Lo script stampa un messaggio e poi registra un nodo – che sarà spiegato nel prossimo capitolo.\\
|
||||
C'è una sola dipendenza, la [mod default](https://content.minetest.net/metapackages/default/), che
|
||||
si trova solitamente nel Minetest Game.\\
|
||||
|
||||
@ -9,8 +9,7 @@ redirect_from: /it/chapters/lua.html
|
||||
|
||||
## Introduzione <!-- omit in toc -->
|
||||
|
||||
In questo capitolo parleremo della programmazione in Lua, degli strumenti necessari,
|
||||
e tratteremo alcune tecniche che troverai probabilmente utili.
|
||||
In questo capitolo parleremo della programmazione in Lua, degli strumenti necessari, e tratteremo alcune tecniche che troverai probabilmente utili.
|
||||
|
||||
- [Editor di codice](#editor-di-codice)
|
||||
- [Programmare in Lua](#programmare-in-lua)
|
||||
@ -27,8 +26,7 @@ e tratteremo alcune tecniche che troverai probabilmente utili.
|
||||
## Editor di codice
|
||||
|
||||
Un editor di codice con evidenziamento delle parole chiave è sufficiente per scrivere script in Lua.
|
||||
L'evidenziamento assegna colori diversi a parole e caratteri diversi a seconda del loro significato.
|
||||
Questo ti permette di individuare più facilmente eventuali errori.
|
||||
L'evidenziamento assegna colori diversi a parole e caratteri diversi a seconda del loro significato, permettendo di individuare più facilmente eventuali errori.
|
||||
|
||||
```lua
|
||||
function ctf.post(team,msg)
|
||||
@ -47,7 +45,7 @@ end
|
||||
```
|
||||
|
||||
Per esempio, parole chiave come if, then, end e return sono evidenziate nel passaggio qui sopra.
|
||||
table.insert è invece una funzione base che deriva direttamente da Lua.
|
||||
Lo stesso vale per le funzioni interne di Lua come table.insert.
|
||||
|
||||
Segue una lista di editor noti che si prestano bene per programmare in Lua.
|
||||
Non sono, ovviamente, gli unici esisteneti.
|
||||
@ -62,13 +60,12 @@ Non sono, ovviamente, gli unici esisteneti.
|
||||
|
||||
I programmi sono una serie di comandi che vengono eseguiti uno dopo l'altro.
|
||||
Chiamiamo questi comandi "istruzioni".
|
||||
Il flusso del programma è il come queste istruzioni vengono eseguite.
|
||||
Differenti tipi di flusso ti permettono di saltare o meno serie di comandi.
|
||||
Ci sono tre tipi di flusso:
|
||||
Il flusso del programma è il come queste istruzioni vengono eseguite, e a differenti tipi di flusso corrispondono comportamenti diversi.
|
||||
Essi possono essere:
|
||||
|
||||
* Sequenziale: esegue un'istruzione dopo l'altra, senza salti.
|
||||
* Selettivo: salta alcune sequenze a seconda delle condizioni.
|
||||
* Iterante: ripete ciclicamente. Continua a eseguire le stesse istruzioni
|
||||
* Sequenziali: eseguono un'istruzione dopo l'altra, senza salti.
|
||||
* Selettivi: saltano alcune sequenze a seconda delle condizioni.
|
||||
* Iteranti: ripetono ciclicamente. Continuano a eseguire le stesse istruzioni
|
||||
finché una condizione non è soddisfatta.
|
||||
|
||||
Quindi, come vengono rappresentate le istruzioni in Lua?
|
||||
@ -83,21 +80,16 @@ print("La somma è ".. risultato)
|
||||
|
||||
Whoa, cos'è appena successo?
|
||||
|
||||
a, b, e risultato sono *variabili*. Le variabili locali si dichiarano
|
||||
tramite l'uso della parola chiave local, e assegnando loro un valore iniziale.
|
||||
Local sarà discussa in un attimo, in quanto parte di un concetto molto importante
|
||||
chiamato *portata*.
|
||||
a, b, e risultato sono *variabili*. Le variabili locali si dichiarano tramite l'uso della parola chiave local (che vedremo tra poco), e assegnando eventualmente loro un valore iniziale.
|
||||
|
||||
Il simbolo `=` significa *assegnazione*, quindi `risultato = a + b` significa impostare "risultato" ad a + b.
|
||||
I nomi delle variabili possono essere più lunghi di un carattere, al contrario che in matematica, come
|
||||
visto nella variabile "risultato".
|
||||
Vale anche la pena notare che Lua è *case-sensitive* (differenzia maiscuole da minuscole);
|
||||
Per quanto riguarda i nomi delle variabili, essi possono essere più lunghi di un carattere - al contrario che in matematica - come visto in "risultato", e vale anche la pena notare che Lua è *case-sensitive* (differenzia maiuscole da minuscole);
|
||||
A è una variabile diversa da a.
|
||||
|
||||
### Tipi di variabili
|
||||
|
||||
Una variabile può equivalere solo a uno dei seguenti tipi e può cambiare tipo dopo l'assegnazione.
|
||||
È buona pratica assicurarsi che una variabile sia sempre solo o nil o diversa da nil.
|
||||
È buona pratica assicurarsi che sia sempre solo o nil o diversa da nil.
|
||||
|
||||
| Tipo | Descrizione | Esempio |
|
||||
|----------|---------------------------------|----------------|
|
||||
@ -123,7 +115,8 @@ Lista non esaustiva, ce ne sono altri
|
||||
|
||||
### Selezione
|
||||
|
||||
La selezione più basica è il costrutto if. Si presenta così:
|
||||
La selezione più basica è il costrutto if.
|
||||
Si presenta così:
|
||||
|
||||
```lua
|
||||
local random_number = math.random(1, 100) -- Tra 1 e 100.
|
||||
@ -134,9 +127,9 @@ else
|
||||
end
|
||||
```
|
||||
|
||||
Questo esempio genera un numero casuale tra 1 e 100. Stampa poi
|
||||
"Woohoo!" se il numero è superiore a 50, altrimenti stampa "No!".
|
||||
Cos'altro puoi usare oltre a '>'?
|
||||
Questo esempio genera un numero casuale tra 1 e 100.
|
||||
Stampa poi "Woohoo!" se il numero è superiore a 50, altrimenti stampa "No!".
|
||||
Cos'altro si può usare oltre a '>'?
|
||||
|
||||
### Operatori logici
|
||||
|
||||
@ -152,7 +145,7 @@ Cos'altro puoi usare oltre a '>'?
|
||||
| A or B | O (almeno uno dei due vero) | (2 > 1) or (1 == 2) (true), (2 > 4) or (1 == 3) (false) |
|
||||
| not A | non vero | not (1 == 2) (true), not (1 == 1) (false) |
|
||||
|
||||
La lista non è esaustiva, e puoi inoltre combinare gli operatori in questo modo:
|
||||
La lista non è esaustiva, e gli operatori possono essere combinati, come da esempio:
|
||||
|
||||
```lua
|
||||
if not A and B then
|
||||
@ -162,8 +155,7 @@ end
|
||||
|
||||
Che stampa "Yay!" se A è falso e B vero.
|
||||
|
||||
Gli operatori logici e matematici funzionano esattamente allo stesso modo;
|
||||
entrambi accettano input e ritornano un valore che può essere immagazzinato.
|
||||
Gli operatori logici e matematici funzionano esattamente allo stesso modo; entrambi accettano input e ritornano un valore che può essere immagazzinato.
|
||||
|
||||
```lua
|
||||
local A = 5
|
||||
@ -175,16 +167,12 @@ end
|
||||
|
||||
## Programmare
|
||||
|
||||
Programmare è l'azione di prendere un problema, come ordinare una lista di oggetti,
|
||||
e tramutarlo in dei passaggi che il computer può comprendere.
|
||||
Programmare è l'azione di prendere un problema, come ordinare una lista di oggetti, e tramutarlo in dei passaggi che il computer può comprendere.
|
||||
|
||||
Insegnarti i processi logici della programmazione non rientra nell'ambito di questo libro;
|
||||
tuttavia, i seguenti siti sono alquanto utili per approfondire l'argomento:
|
||||
Insegnarti i processi logici della programmazione non rientra nell'ambito di questo libro; tuttavia, i seguenti siti sono alquanto utili per approfondire l'argomento:
|
||||
|
||||
* [Codecademy](http://www.codecademy.com/) è una delle migliori risorse per
|
||||
imparare a 'programmare'; offre un'esperienza guidata interattiva.
|
||||
* [Scratch](https://scratch.mit.edu) è una buona risorsa quando si comincia
|
||||
dalle basi assolute, imparando le tecniche di problem solving necessarie per programmare.\\
|
||||
* [Codecademy](http://www.codecademy.com/) è una delle migliori risorse per imparare come scrivere codice; offre un'esperienza guidata interattiva.
|
||||
* [Scratch](https://scratch.mit.edu) è una buona risorsa quando si comincia dalle basi assolute, imparando le tecniche di problem solving necessarie per la programmazione.\\
|
||||
Scratch è **ideato per insegnare ai bambini** e non è un linguaggio serio di programmazione.
|
||||
|
||||
## Portata locale e globale
|
||||
@ -240,11 +228,10 @@ one()
|
||||
two()
|
||||
```
|
||||
|
||||
dump() è una funzione che può trasformare qualsiasi variabile in una stringa, cosicché
|
||||
il programmatore possa vedere cosa rappresenta. La variabile foo sarà stampata come
|
||||
"bar", virgolette incluse (che dimostrano che è una stringa).
|
||||
dump() è una funzione che può trasformare qualsiasi variabile in una stringa, cosicché il programmatore possa vedere cosa rappresenta.
|
||||
In questo caso `foo` sarà stampata come "bar", virgolette incluse (che dimostrano che è una stringa).
|
||||
|
||||
L'esempio precedente non è buona programmazione e Minetest, infatti, avviserà di ciò:
|
||||
L'esempio precedente non è tuttavia buona norma e Minetest, infatti, ci avviserà di ciò:
|
||||
|
||||
Assignment to undeclared global 'foo' inside function at init.lua:2
|
||||
|
||||
@ -264,12 +251,10 @@ two()
|
||||
```
|
||||
|
||||
Ricorda che nil significa **non inizializzato**.
|
||||
Ovvero la variabile non è stata ancora assegnata a un valore,
|
||||
non esiste o è stata deinizializzata (cioè impostata a nil)
|
||||
Ovvero la variabile non è stata ancora assegnata a un valore, non esiste o è stata deinizializzata (cioè impostata a nil)
|
||||
|
||||
La stessa cosa vale per le funzioni. Le funzioni sono variabili di tipo speciale,
|
||||
e dovrebbero essere dichiarate locali, in quanto altre mod potrebbero sennò avere funzioni
|
||||
con lo stesso nome.
|
||||
La stessa cosa vale per le funzioni.
|
||||
Le funzioni sono variabili di tipo speciale, e dovrebbero essere dichiarate locali, in quanto altre mod potrebbero sennò avere funzioni con lo stesso nome.
|
||||
|
||||
```lua
|
||||
local function foo(bar)
|
||||
@ -310,5 +295,4 @@ print(ret) -- Hello world!
|
||||
```
|
||||
|
||||
Nei capitoli seguenti si parlerà nel dettaglio di come suddividere il codice di una mod.
|
||||
Tuttavia, per ora l'approccio semplicistico è di avere file differenti per diversi tipi di cose
|
||||
— nodi.lua, craft.lua, oggetti.lua ecc.
|
||||
Tuttavia, per ora l'approccio semplicistico è di avere file differenti per diversi tipi di cose — nodi.lua, craft.lua, oggetti.lua ecc.
|
||||
|
||||
@ -9,13 +9,10 @@ redirect_from: /it/chapters/creating_textures.html
|
||||
|
||||
## Introduzione <!-- omit in toc -->
|
||||
|
||||
Essere in grado di creare e ottimizare le texture è un'abilità alquanto utile quando si sviluppa
|
||||
per Minetest.
|
||||
Ci sono molti approcci sul come creare texture in pixel art, e capire questi approcci
|
||||
migliorerà nettamente la qualità dei tuoi lavori.
|
||||
Essere in grado di creare e ottimizare le texture è un'abilità alquanto utile quando si sviluppa per Minetest.
|
||||
Ci sono molti approcci sul come creare texture in pixel art, e capire questi approcci migliorerà nettamente la qualità dei tuoi lavori.
|
||||
|
||||
Fornire spiegazioni dettagliate non rientra tuttavia nell'ambito di questo libro:
|
||||
verranno quindi trattate solo le tecniche più semplici.
|
||||
Fornire spiegazioni dettagliate non rientra tuttavia nell'ambito di questo libro: verranno quindi trattate solo le tecniche più semplici.
|
||||
Se si vuole approfondire, ci sono comunque molti [buoni tutorial online](http://www.photonstorm.com/art/tutorials-art/16x16-pixel-art-tutorial) disponibili, che si occupano di pixel art in modo molto più dettagliato.
|
||||
|
||||
- [Tecniche](#tecniche)
|
||||
@ -31,17 +28,14 @@ Se si vuole approfondire, ci sono comunque molti [buoni tutorial online](http://
|
||||
### Usare la matita
|
||||
|
||||
Lo strumento matita è disponibile nella maggior parte dei programmi di disegno.
|
||||
Quando viene impostato alla dimensione minima, ti permette di disegnare un pixel alla volta
|
||||
senza alterare le atre parti dell'immagine.
|
||||
Manipolando i singoli pixel si possono creare texture chiare e nette senza alcuna
|
||||
sfocatura non voluta, dando inoltre un alto livello di precisione e controllo.
|
||||
Quando viene impostato alla dimensione minima, permette di disegnare un pixel alla volta senza alterare le atre parti dell'immagine.
|
||||
Manipolando i singoli pixel si possono creare texture chiare e nette senza alcuna sfocatura non voluta, dando inoltre un alto livello di precisione e controllo.
|
||||
|
||||
### Piastrellatura (tiling)
|
||||
|
||||
Le texture usate per i nodi dovrebbero generalmente essere progettate per ripetersi come
|
||||
delle piastrelle.
|
||||
Questo significa che quando piazzi più nodi con la stessa texture vicini, i bordi dovranno
|
||||
allinearsi correttamente creando un effetto di continuità.
|
||||
Questo significa che quando piazzi più nodi con la stessa texture vicini, i bordi dovranno allinearsi correttamente creando un effetto di continuità.
|
||||
|
||||
<!-- IMAGE NEEDED - cobblestone that tiles correctly -->
|
||||
|
||||
@ -52,10 +46,8 @@ gradevole da vedere.
|
||||
|
||||
### Trasparenza
|
||||
|
||||
La trasparenza è importante quando si creano texture per pressoché tutti gli
|
||||
oggetti fabbricabili e per alcuni nodi, come il vetro.
|
||||
Non tutti i programmi supportano la trasparenza, perciò assicurati di sceglierne
|
||||
uno adatto ai tipi di texture che vuoi creare.
|
||||
La trasparenza è importante quando si creano texture per pressoché tutti gli oggetti fabbricabili e per alcuni nodi, come il vetro.
|
||||
Non tutti i programmi supportano la trasparenza, perciò assicurati di sceglierne uno adatto ai tipi di texture che vuoi creare.
|
||||
|
||||
## Programmi
|
||||
|
||||
@ -69,8 +61,7 @@ tuttavia se la trasparenza è un requisito nelle tue texture dovresti guardare o
|
||||
### GIMP
|
||||
|
||||
GIMP viene impiegato spesso nella comunità di Minetest.
|
||||
Ha una curva di apprendimento alquanto alta, dato che molte delle sue funzioni
|
||||
non risultano ovvie nell'immediato.
|
||||
Ha una curva di apprendimento alquanto alta, dato che molte delle sue funzioni non risultano ovvie nell'immediato.
|
||||
|
||||
Quando usi GIMP, puoi selezionare la matita dalla Barra degli Strumenti:
|
||||
|
||||
|
||||
@ -13,8 +13,7 @@ redirect_from:
|
||||
|
||||
## Introduzione <!-- omit in toc -->
|
||||
|
||||
In questo capitolo, imparerai come usare e manipolare gli inventari, siano essi quelli
|
||||
di un giocatore, di un nodo o a sé stanti.
|
||||
In questo capitolo, imparerai come usare e manipolare gli inventari, siano essi quelli di un giocatore, di un nodo o a sé stanti.
|
||||
|
||||
- [Cosa sono gli ItemStack e gli inventari?](#cosa-sono-gli-itemstack-e-gli-inventari)
|
||||
- [ItemStack](#itemstack)
|
||||
@ -31,21 +30,17 @@ di un giocatore, di un nodo o a sé stanti.
|
||||
|
||||
## Cosa sono gli ItemStack e gli inventari?
|
||||
|
||||
Un ItemStack (*pila di oggetti*) è il dato dietro una singola cella di un inventario.
|
||||
Un ItemStack ( lett. "pila di oggetti") è il dato dietro una singola cella di un inventario.
|
||||
|
||||
Un *inventario* è una collezione di *liste* apposite, ognuna delle quali è una griglia
|
||||
2D di ItemStack.
|
||||
Lo scopo di un inventario è quello di raggruppare più liste in un singolo oggetto (l'inventario appunto),
|
||||
in quanto a ogni giocatore e a ogni nodo può essere associato massimo un inventario.
|
||||
Un *inventario* è una collezione di *liste* apposite, ognuna delle quali è una griglia 2D di ItemStack.
|
||||
Lo scopo di un inventario è quello di raggruppare più liste in un singolo oggetto (l'inventario appunto), in quanto a ogni giocatore e a ogni nodo ne può essere associato massimo uno.
|
||||
|
||||
## ItemStack
|
||||
|
||||
Gli ItemStack sono composti da quattro parametri: nome, quantità, durabilità e metadati.
|
||||
|
||||
Il nome dell'oggetto può essere il nome di un oggetto registrato, di uno sconosciuto (non registrato)
|
||||
o un alias.
|
||||
Gli oggetti sconosciuti sono tipici di quando si disinstallano le mod, o quando le mod rimuovono
|
||||
degli oggetti senza nessun accorgimento, tipo senza registrarne un alias.
|
||||
Il nome dell'oggetto può essere il nome di un oggetto registrato, di uno sconosciuto (non registrato) o un alias.
|
||||
Gli oggetti sconosciuti sono tipici di quando si disinstallano le mod, o quando le mod rimuovono degli oggetti senza nessun accorgimento, tipo senza registrarne un alias.
|
||||
|
||||
```lua
|
||||
print(stack:get_name())
|
||||
@ -57,18 +52,13 @@ end
|
||||
```
|
||||
|
||||
La quantità sarà sempre 0 o maggiore.
|
||||
Durante una normale sessione di gioco, la quantità non dovrebbe mai essere maggiore della dimensione
|
||||
massima della pila dell'oggetto - `stack_max`.
|
||||
Tuttavia, comandi da amministratore e mod fallate potrebbero portare a oggetti impilati che superano
|
||||
la grandezza massima.
|
||||
Durante una normale sessione di gioco, la quantità non dovrebbe mai essere maggiore della dimensione massima della pila dell'oggetto - `stack_max`.
|
||||
Tuttavia, comandi da amministratore e mod fallate potrebbero portare a oggetti impilati che superano la grandezza massima.
|
||||
|
||||
```lua
|
||||
print(stack:get_stack_max())
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
Un ItemStack può essere vuoto, nel qual caso avrà come quantità 0.
|
||||
|
||||
```lua
|
||||
@ -76,7 +66,7 @@ print(stack:get_count())
|
||||
stack:set_count(10)
|
||||
```
|
||||
|
||||
Gli ItemStack possono essere creati in diversi modi usando la funzione ItemStack.
|
||||
Gli ItemStack possono poi essere creati in diversi modi usando l'omonima funzione.
|
||||
|
||||
```lua
|
||||
ItemStack() -- name="", count=0
|
||||
@ -87,8 +77,7 @@ ItemStack({ name = "default:wood", count = 10 })
|
||||
|
||||
I metadati di un oggetto sono una o più coppie chiave-valore custodite in esso.
|
||||
Chiave-valore significa che si usa un nome (la chiave) per accedere al dato corrispettivo (il valore).
|
||||
Alcune chiavi hanno significati predefiniti, come `description` che è usato per specificare la descrizione
|
||||
di una pila di oggetti.
|
||||
Alcune chiavi hanno significati predefiniti, come `description` che è usato per specificare la descrizione di una pila di oggetti.
|
||||
Questo sarà trattato più in dettaglio nel capitolo Storaggio e Metadati.
|
||||
|
||||
## Collocazione inventari
|
||||
@ -105,8 +94,7 @@ local inv = minetest.get_inventory({ type="node", pos={x=1, y=2, z=3} })
|
||||
```
|
||||
|
||||
L'esempio in alto ottiene il *riferimento a un inventario*, comunemente definito *InvRef*.
|
||||
Questi riferimenti sono usati per manipolare l'inventario, e son chiamati così perché i dati
|
||||
non sono davvero salvati dentro all'oggetto (in questo caso "inv"), bensì *puntano* a quei dati.
|
||||
Questi riferimenti sono usati per manipolare l'inventario, e son chiamati così perché i dati non sono davvero salvati dentro all'oggetto (in questo caso "inv"), bensì *puntano* a quei dati.
|
||||
In questo modo, modificando "inv", stiamo in verità modificando l'inventario.
|
||||
|
||||
La collocazione di tali riferimenti può essere ottenuta nel seguente modo:
|
||||
@ -115,8 +103,8 @@ La collocazione di tali riferimenti può essere ottenuta nel seguente modo:
|
||||
local location = inv:get_location()
|
||||
```
|
||||
|
||||
Gli inventari dei giocatori si ottengono in maniera simile, oppure usando il riferimento
|
||||
a un giocatore (*PlayerRef*). In entrambi casi, il giocatore deve essere connesso.
|
||||
Gli inventari dei giocatori si ottengono in maniera simile, oppure usando il riferimento a un giocatore (*PlayerRef*).
|
||||
In entrambi casi, il giocatore deve essere connesso.
|
||||
|
||||
```lua
|
||||
local inv = minetest.get_inventory({ type="player", name="player1" })
|
||||
@ -124,8 +112,7 @@ local inv = minetest.get_inventory({ type="player", name="player1" })
|
||||
local inv = player:get_inventory()
|
||||
```
|
||||
|
||||
Gli inventari separati, infine, sono quelli non collegati né a nodi né a giocatori,
|
||||
e al contrario degli altri, vengono persi dopo un riavvio.
|
||||
Gli inventari separati, infine, sono quelli non collegati né a nodi né a giocatori, e al contrario degli altri, vengono persi dopo un riavvio.
|
||||
|
||||
```lua
|
||||
local inv = minetest.get_inventory({
|
||||
@ -138,9 +125,8 @@ Un'ulteriore differenza, è che gli inventari separati devono essere creati prim
|
||||
minetest.create_detached_inventory("inventory_name")
|
||||
```
|
||||
|
||||
La funzione create_detached_inventory accetta 3 parametri, di cui solo il primo - il nome - è necessario.
|
||||
Il secondo parametro prende una tabella di callback, che possono essere utilizzati
|
||||
per controllare come i giocatori interagiscono con l'inventario:
|
||||
La funzione `create_detached_inventory` accetta 3 parametri, di cui solo il primo - il nome - è necessario.
|
||||
Il secondo parametro prende una tabella di callback, che possono essere utilizzati per controllare come i giocatori interagiscono con l'inventario:
|
||||
|
||||
```lua
|
||||
-- Input only detached inventory
|
||||
@ -165,22 +151,18 @@ minetest.create_detached_inventory("inventory_name", {
|
||||
})
|
||||
```
|
||||
|
||||
I callback dei permessi - quelle che iniziano con `allow_` - ritornano il numero
|
||||
degli oggetti da trasferire, e si usa -1 per impedirne del tutto l'azione.
|
||||
I callback dei permessi - quelle che iniziano con `allow_` - ritornano il numero degli oggetti da trasferire, e si usa -1 per impedirne del tutto l'azione.
|
||||
|
||||
I callback delle azioni - quelle che iniziano con `on_` - non ritornano invece alcun valore.
|
||||
|
||||
## Liste
|
||||
|
||||
Le liste negli inventari permettono di disporre più griglie nello stesso luogo (l'inventario).
|
||||
Esse sono particolarmente utili per il giocatore, e infatti di base ogni gioco possiede già
|
||||
delle liste come *main* per il corpo principale dell'inventario e *craft* per l'area di fabbricazione.
|
||||
Esse sono particolarmente utili per il giocatore, e infatti di base ogni gioco possiede già delle liste come *main* per il corpo principale dell'inventario e *craft* per l'area di fabbricazione.
|
||||
|
||||
### Dimensione e ampiezza
|
||||
|
||||
Le liste hanno una dimensione, equivalente al numero totale di celle nella griglia, e un'ampiezza,
|
||||
che è usata esclusivamente dentro il motore di gioco: quando viene disegnato un inventario in una finestra,
|
||||
infatti, il codice dietro di essa già determina che ampiezza usare.
|
||||
Le liste hanno una dimensione, equivalente al numero totale di celle nella griglia, e un'ampiezza, che è usata esclusivamente dentro il motore di gioco: quando viene disegnato un inventario in una finestra, infatti, il codice dietro di essa già determina che ampiezza usare.
|
||||
|
||||
```lua
|
||||
if inv:set_size("main", 32) then
|
||||
@ -192,10 +174,8 @@ else
|
||||
end
|
||||
```
|
||||
|
||||
`set_size` non andrà in porto e ritornerà "false" se il nome della lista o la dimensione dichiarata
|
||||
non risultano valide.
|
||||
Per esempio, la nuova dimensione potrebbe essere troppo piccola per contenere gli oggetti attualmente
|
||||
presenti nell'inventario.
|
||||
`set_size` non andrà in porto e ritornerà "false" se il nome della lista o la dimensione dichiarata non risultano valide.
|
||||
Per esempio, la nuova dimensione potrebbe essere troppo piccola per contenere gli oggetti attualmente presenti nell'inventario.
|
||||
|
||||
### Controllare il contenuto
|
||||
|
||||
@ -219,8 +199,8 @@ end
|
||||
|
||||
### Aggiungere a una lista
|
||||
|
||||
Per aggiungere degli oggetti a una lista (in questo caso "main") usiamo `add_item`. Nell'esempio
|
||||
sottostante ci accertiamo anche di rispettare la dimensione:
|
||||
Per aggiungere degli oggetti a una lista (in questo caso "main") usiamo `add_item`.
|
||||
Nell'esempio sottostante ci accertiamo anche di rispettare la dimensione:
|
||||
|
||||
```lua
|
||||
local stack = ItemStack("default:stone 99")
|
||||
@ -248,8 +228,7 @@ Puoi modificare le singole pile prima ottenendole:
|
||||
local stack = inv:get_stack(listname, 0)
|
||||
```
|
||||
|
||||
E poi modificandole impostando le nuove proprietà o usando i metodi che
|
||||
rispettano `stack_size`:
|
||||
E poi modificandole impostando le nuove proprietà o usando i metodi che rispettano `stack_size`:
|
||||
|
||||
```lua
|
||||
local pila = ItemStack("default:stone 50")
|
||||
@ -267,8 +246,7 @@ print("Hai " .. pila:get_count() .. " oggetti")
|
||||
```
|
||||
|
||||
`add_item` aggiungerà gli oggetti all'ItemStack e ritornerà quelli in eccesso.
|
||||
`take_item` rimuoverà gli oggetti indicati (o meno se ce ne sono meno), e ritornerà
|
||||
l'ammontare rimosso.
|
||||
`take_item` rimuoverà gli oggetti indicati (o meno se ce ne sono meno), e ritornerà l'ammontare rimosso.
|
||||
|
||||
Infine, si imposta la pila modificata:
|
||||
|
||||
@ -278,9 +256,8 @@ inv:set_stack(listname, 0, pila)
|
||||
|
||||
## Usura
|
||||
|
||||
Gli strumenti possono avere un livello di usura; l'usura è rappresentata da un barra progressiva
|
||||
e fa rompere lo strumento quando completamente logorato.
|
||||
L'usura è un numero da 0 a 65535; più è alto, più è consumato l'oggetto.
|
||||
Gli strumenti possono avere un livello di usura; essa è rappresentata da un barra progressiva e fa rompere lo strumento quando completamente logorato.
|
||||
Nello specifico, l'usura è un numero da 0 a 65535: più è alto, più è consumato l'oggetto.
|
||||
|
||||
Il livello di usura può essere manipolato usando `add_wear()`, `get_wear()`, e `set_wear(wear)`.
|
||||
|
||||
@ -293,7 +270,7 @@ local usi_massimi = 10
|
||||
pila:add_wear(65535 / (usi_massimi - 1))
|
||||
```
|
||||
|
||||
Quando scavi un nodo, l'incremento di usura di uno strumento dipende da che tipo di nodo è.
|
||||
Quando si scava un nodo, l'incremento di usura di uno strumento dipende da che tipo di nodo è.
|
||||
Di conseguenza, `usi_massimi` varia a seconda di cos'è stato scavato.
|
||||
|
||||
## Tabelle Lua
|
||||
@ -334,10 +311,8 @@ La tabella di liste ritornata da `get_lists()` sarà nel seguente formato:
|
||||
|
||||
`get_list()` ritornerà una lista singola fatta di ItemStack.
|
||||
|
||||
Una cosa importante da sottolineare è che i metodi `set` qui in alto non cambiano
|
||||
la dimensione delle liste.
|
||||
Questo significa che si può svuotare una lista dichiarandola uguale a una tabella vuota,
|
||||
e la sua dimensione tuttavia non cambierà:
|
||||
Una cosa importante da sottolineare è che i metodi `set` qui in alto non cambiano la dimensione delle liste.
|
||||
Questo significa che si può svuotare una lista dichiarandola uguale a una tabella vuota, e la sua dimensione tuttavia non cambierà:
|
||||
|
||||
```lua
|
||||
inv:set_list("main", {})
|
||||
|
||||
@ -10,21 +10,14 @@ redirect_from: /it/chapters/node_drawtypes.html
|
||||
## Introduzione <!-- omit in toc -->
|
||||
|
||||
Il metodo col quale un nodo viene disegnato in gioco è chiamato *drawtype*.
|
||||
Ci sono diversi tipi di drawtype: il loro comportamento è determinato dalle proprietà
|
||||
impostate durante la definizione del tipo di nodo.
|
||||
Queste proprietà sono fisse, uguali per tutte le istanze, tuttavia
|
||||
è possibile manipolarne alcune per singolo nodo usando una cosa chiamata `param2`.
|
||||
Ci sono diversi tipi di drawtype: il loro comportamento è determinato dalle proprietà impostate durante la definizione del tipo di nodo.
|
||||
Queste proprietà sono fisse, uguali per tutte le istanze, tuttavia è possibile manipolarne alcune per singolo nodo usando una cosa chiamata `param2`.
|
||||
|
||||
Il concetto di nodo è stato introdotto nello scorso capitolo, ma non è mai stata
|
||||
data una definizione completa.
|
||||
Il mondo di Minetest è una griglia 3D: un nodo è un punto di quella griglia ed è composto
|
||||
da un tipo (name) e due parametri (param1 e param2).
|
||||
Non farti inoltre ingannare dalla funzione `minetest.register_node`, in quanto è un po' fuorviante:
|
||||
essa non registra infatti un nuovo nodo (c'è solo una definizione di nodo), bensì un nuovo *tipo* di nodo.
|
||||
Il concetto di nodo è stato introdotto nello scorso capitolo, ma non è mai stata data una definizione completa.
|
||||
Il mondo di Minetest è una griglia 3D: un nodo è un punto di quella griglia ed è composto da un tipo (`name`) e due parametri (`param1` e `param2`).
|
||||
Non farti inoltre ingannare dalla funzione `minetest.register_node`, in quanto è un po' fuorviante: essa non registra infatti un nuovo nodo (c'è solo una definizione di nodo), bensì un nuovo *tipo* di nodo.
|
||||
|
||||
I parametri sono infine usati per controllare come un nodo viene renderizzato individualmente:
|
||||
`param1` immagazzina le proprietà di luce, mentre il ruolo di `param2` dipende dalla
|
||||
proprietà `paramtype2`, la quale è situata nella definizione dei singoli tipi di nodi.
|
||||
I parametri sono infine usati per controllare come un nodo viene renderizzato individualmente: `param1` immagazzina le proprietà di luce, mentre il ruolo di `param2` dipende dalla proprietà `paramtype2`, la quale è situata nella definizione dei singoli tipi.
|
||||
|
||||
- [Nodi cubici: normali e a facciate piene](#nodi-cubici-normali-e-a-facciate-piene)
|
||||
- [Nodi vitrei](#nodi-vitrei)
|
||||
@ -50,14 +43,12 @@ proprietà `paramtype2`, la quale è situata nella definizione dei singoli tipi
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
Il drawtype normale è tipicamente usato per renderizzare un nodo cubico.
|
||||
Se il lato di uno di questi nodi tocca un nodo solido, allora quel lato non sarà renderizzato,
|
||||
risultando in un grande guadagno sulle prestazioni.
|
||||
Il *drawtype* normale è tipicamente usato per renderizzare un nodo cubico.
|
||||
Se il lato di uno di questi nodi tocca un nodo solido, allora quel lato non sarà renderizzato, risultando in un grande guadagno sulle prestazioni.
|
||||
|
||||
Al contrario, i drawtype a facciate piene (allfaces) renderizzeranno comunque il lato interno quando
|
||||
è contro un nodo solido. Ciò è buono per quei nodi con facce in parte trasparenti come
|
||||
le foglie. Puoi inoltre usare il drawtype `allfaces_optional` per permettere agli utenti
|
||||
di fare opt-out dal rendering più pesante, facendo comportare il nodo come se fosse di tipo normale.
|
||||
Al contrario, i *drawtype* a facciate piene (*allfaces*) renderizzeranno comunque il lato interno quando è contro un nodo solido.
|
||||
Ciò è buono per quei nodi con facce in parte trasparenti come le foglie.
|
||||
Puoi inoltre usare il drawtype `allfaces_optional` per permettere agli utenti di fare opt-out dal rendering più pesante, facendo comportare il nodo come se fosse di tipo normale.
|
||||
|
||||
```lua
|
||||
minetest.register_node("miamod:diamante", {
|
||||
@ -77,10 +68,8 @@ Attenzione: il drawtype normale è quello predefinito, quindi non c'è bisogno d
|
||||
|
||||
## Nodi vitrei
|
||||
|
||||
La differenza tra i nodi vitrei (glasslike) e quelli normali è che piazzando i primi vicino a un
|
||||
nodo normale, non nasconderanno il lato di quest'ultimo.
|
||||
Questo è utile in quanto i nodi vitrei tendono a essere trasparenti, perciò permettono
|
||||
di vedere attraverso.
|
||||
La differenza tra i nodi vitrei (*glasslike*) e quelli normali è che piazzando i primi vicino a un nodo normale, non nasconderanno il lato di quest'ultimo.
|
||||
Questo è utile in quanto i nodi vitrei tendono a essere trasparenti, perciò permettono di vedere attraverso.
|
||||
|
||||
<figure>
|
||||
<img src="{{ page.root }}//static/drawtype_glasslike_edges.png" alt="Bordi vitrei">
|
||||
@ -104,8 +93,7 @@ minetest.register_node("default:obsidian_glass", {
|
||||
|
||||
### Vitreo incorniciato
|
||||
|
||||
Questa opzione crea un solo bordo lungo tutto l'insieme di nodi, al posto di
|
||||
crearne più per singolo nodo.
|
||||
Questa opzione crea un solo bordo lungo tutto l'insieme di nodi, al posto di crearne più per singolo nodo.
|
||||
|
||||
<figure>
|
||||
<img src="{{ page.root }}//static/drawtype_glasslike_framed.png" alt="Bordi vitrei incorniciati">
|
||||
@ -127,11 +115,11 @@ minetest.register_node("default:glass", {
|
||||
})
|
||||
```
|
||||
|
||||
Puoi inoltre usare il drawtype glasslike_framed_optional per permettere un opt-in all'utente.
|
||||
Puoi inoltre usare il *drawtype* `glasslike_framed_optional` per permettere un opt-in all'utente.
|
||||
|
||||
## Nodi d'aria
|
||||
|
||||
I nodi d'aria (airlike) non sono renderizzati e perciò non hanno texture.
|
||||
I nodi d'aria (*airlike*) non sono renderizzati e perciò non hanno texture.
|
||||
|
||||
```lua
|
||||
minetest.register_node("miaaria:aria", {
|
||||
@ -155,21 +143,20 @@ minetest.register_node("miaaria:aria", {
|
||||
|
||||
## Luce e propagazione solare
|
||||
|
||||
La luce di un nodo è salvata in param1. Per capire come ombreggiare
|
||||
il lato di un nodo, viene utilizzato il valore di luminosità dei nodi adiacenti.
|
||||
La luce di un nodo è salvata in `param1`.
|
||||
Per capire come ombreggiare il lato di un nodo, viene utilizzato il valore di luminosità dei nodi adiacenti.
|
||||
Questo comporta un blocco della luce da parte dei nodi solidi.
|
||||
|
||||
Di base, non viene salvata la luce in nessun nodo né nelle sue istanze.
|
||||
È invece solitamente preferibile farla passare in tipi quali quelli d'aria e
|
||||
vitrei. Per fare ciò, ci sono due proprietà che devono essere definite:
|
||||
È invece solitamente preferibile farla passare in tipi quali quelli d'aria e vitrei.
|
||||
Per fare ciò, ci sono due proprietà che devono essere definite:
|
||||
|
||||
```lua
|
||||
paramtype = "light",
|
||||
sunlight_propagates = true,
|
||||
```
|
||||
|
||||
La prima riga dice a param1 di immagazzinare l'indice di luminosità.
|
||||
La seconda riga invece permette alla luce del sole di propagarsi attraverso il nodo senza diminuire il suo valore.
|
||||
La prima riga dice a `param1` di immagazzinare l'indice di luminosità, mentre la seconda permette alla luce del sole di propagarsi attraverso il nodo senza diminuire il proprio valore.
|
||||
|
||||
## Nodi liquidi
|
||||
|
||||
@ -180,8 +167,7 @@ La seconda riga invece permette alla luce del sole di propagarsi attraverso il n
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
Ogni tipo di liquido richiede due definizioni di nodi: una per la sorgente e l'altra
|
||||
per il liquido che scorre.
|
||||
Ogni tipo di liquido richiede due definizioni di nodi: una per la sorgente e l'altra per il liquido che scorre.
|
||||
|
||||
```lua
|
||||
-- Alcune proprietà sono state rimosse perché non
|
||||
@ -261,8 +247,7 @@ Guarda default:water_flowing nella mod default di minetest_game per un esempio c
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
I nodi complessi (nodebox) ti permettono di creare un nodo che non è cubico, bensì un insieme
|
||||
di più cuboidi.
|
||||
I nodi complessi (*nodebox*) ti permettono di creare un nodo che non è cubico, bensì un insieme di più cuboidi.
|
||||
|
||||
```lua
|
||||
minetest.register_node("stairs:stair_stone", {
|
||||
@ -278,27 +263,22 @@ minetest.register_node("stairs:stair_stone", {
|
||||
})
|
||||
```
|
||||
|
||||
La parte più importable è la tabella node_box:
|
||||
La parte più importante è la tabella `node_box`:
|
||||
|
||||
```lua
|
||||
{-0.5, -0.5, -0.5, 0.5, 0, 0.5},
|
||||
{-0.5, 0, 0, 0.5, 0.5, 0.5}
|
||||
```
|
||||
|
||||
Ogni riga corrisponde a un cuboide e l'insieme delle righe forma il nodo complesso:
|
||||
i primi tre numeri sono le coordinate (da -0.5 a 0.5) dell'angolo davanti in basso a sinistra,
|
||||
mentre gli altri tre equivalgono all'angolo opposto.
|
||||
Ogni riga corrisponde a un cuboide e l'insieme delle righe forma il nodo complesso: i primi tre numeri sono le coordinate (da -0.5 a 0.5) dell'angolo davanti in basso a sinistra, mentre gli altri tre equivalgono all'angolo opposto.
|
||||
Essi sono in formato X, Y, Z, dove Y indica il sopra.
|
||||
|
||||
|
||||
Puoi usare [NodeBoxEditor](https://forum.minetest.net/viewtopic.php?f=14&t=2840) per
|
||||
creare nodi complessi più facilmente, in quanto permette di vedere in tempo reale le modifiche
|
||||
sul nodo che si sta modellando.
|
||||
Puoi usare [NodeBoxEditor](https://forum.minetest.net/viewtopic.php?f=14&t=2840) per creare nodi complessi più facilmente, in quanto permette di vedere in tempo reale le modifiche sul nodo che si sta modellando.
|
||||
|
||||
### Nodi complessi a muro
|
||||
|
||||
Certe volte si vogliono avere nodi complessi che cambiano a seconda della loro posizione
|
||||
sul pavimento, sul muro e sul soffitto, come le torce.
|
||||
Certe volte si vogliono avere nodi complessi che cambiano a seconda della loro posizione sul pavimento, sul muro e sul soffitto, come le torce.
|
||||
|
||||
```lua
|
||||
minetest.register_node("default:sign_wall", {
|
||||
@ -326,13 +306,11 @@ minetest.register_node("default:sign_wall", {
|
||||
|
||||
## Nodi mesh
|
||||
|
||||
Mentre i nodi complessi sono generalmente più semplici da fare, essi sono limitati
|
||||
in quanto possono essere composti solo da cuboidi. I nodi complessi sono anche non ottimizzati:
|
||||
le facce interne, infatti, saranno comunque renderizzate, anche quando completamente nascoste.
|
||||
Mentre i nodi complessi sono generalmente più semplici da fare, essi sono limitati in quanto possono essere composti solo da cuboidi.
|
||||
I nodi complessi sono anche non ottimizzati: le facce interne, infatti, saranno comunque renderizzate, anche quando completamente nascoste.
|
||||
|
||||
Una faccia è una superficie piatta di una mesh. Una faccia interna appare quando le
|
||||
facce di due nodi complessi si sovrappongono, rendendo invisibili parti del modello
|
||||
ma renderizzandole comunque.
|
||||
Una faccia è una superficie piatta di una mesh.
|
||||
Una faccia interna appare quando le facce di due nodi complessi si sovrappongono, rendendo invisibili parti del modello ma renderizzandole comunque.
|
||||
|
||||
Puoi registrare un nodo mesh come segue:
|
||||
|
||||
@ -351,17 +329,15 @@ minetest.register_node("miamod:meshy", {
|
||||
```
|
||||
|
||||
Assicurati che la mesh sia presente nella cartella `models`.
|
||||
La maggior parte delle volte la mesh dovrebbe essere nella cartella della tua mod, tuttavia
|
||||
è ok condividere una mesh fornita da un'altra mod dalla quale dipendi.
|
||||
Per esempio, una mod che aggiunge più tipi di mobili potrebbe usfruire di un modello
|
||||
fornito da una mod di mobili base.
|
||||
La maggior parte delle volte la mesh dovrebbe essere nella cartella della tua mod, tuttavia è ok condividere una mesh fornita da un'altra mod dalla quale dipendi.
|
||||
Per esempio, una mod che aggiunge più tipi di mobili potrebbe usfruire di un modello fornito da una mod di mobili base.
|
||||
|
||||
## Nodi insegna
|
||||
|
||||
I nodi insegna (signlike) sono nodi piatti che possono essere affissi sulle facce di altri nodi.
|
||||
I nodi insegna (*signlike*) sono nodi piatti che possono essere affissi sulle facce di altri nodi.
|
||||
|
||||
Al contrario del loro nome, i cartelli non rientrano nei nodi insegna bensì nei nodi complessi,
|
||||
per fornire un effetto 3D. I tipi insegna tuttavia, sono comunemente usati dalle scale a pioli.
|
||||
Al contrario del loro nome, i cartelli non rientrano nei nodi insegna bensì in quelli complessi, per fornire un effetto 3D.
|
||||
I tipi insegna tuttavia, sono comunemente usati dalle scale a pioli.
|
||||
|
||||
```lua
|
||||
minetest.register_node("default:ladder_wood", {
|
||||
@ -387,7 +363,7 @@ minetest.register_node("default:ladder_wood", {
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
I nodi pianta raffigurano la loro texture in un pattern a forma di X.
|
||||
I nodi pianta (*plantlike*) raffigurano la loro texture in un pattern a forma di X.
|
||||
|
||||
```lua
|
||||
minetest.register_node("default:papyrus", {
|
||||
@ -405,8 +381,7 @@ minetest.register_node("default:papyrus", {
|
||||
|
||||
## Nodi fiamma
|
||||
|
||||
I nodi fiamma (firelike) sono simili ai pianta, ad eccezione del fatto che sono
|
||||
ideati per "avvinghiarsi" ai muri e ai soffitti.
|
||||
I nodi fiamma (*firelike*) sono simili ai pianta, ad eccezione del fatto che sono ideati per avvinghiarsi ai muri e ai soffitti.
|
||||
|
||||
<figure>
|
||||
<img src="{{ page.root }}//static/drawtype_firelike.png" alt="Drawtype fiamma">
|
||||
@ -426,7 +401,7 @@ minetest.register_node("miamod:avvinghiatutto", {
|
||||
|
||||
## Altri drawtype
|
||||
|
||||
Questa non è una lista definitiva, ci sono infatti altri tipi di nodi come:
|
||||
Questa non è una lista esaustiva, in quanto ci sono infatti altri tipi di nodi come:
|
||||
|
||||
* Nodi staccionata
|
||||
* Nodi pianta radicata - per quelle acquatiche
|
||||
@ -435,5 +410,4 @@ Questa non è una lista definitiva, ci sono infatti altri tipi di nodi come:
|
||||
Le torce in Minetest Game usano in verità due diverse definizioni dei
|
||||
nodi mesh (default:torch e default:torch_wall).
|
||||
|
||||
Come al solito, consulta la [documentazione sull'API Lua](../../lua_api.html#node-drawtypes)
|
||||
per l'elenco completo.
|
||||
Come al solito, consulta la [documentazione sull'API Lua](../../lua_api.html#node-drawtypes) per l'elenco completo.
|
||||
|
||||
@ -28,19 +28,15 @@ Saper registrare nuovi nodi, oggetti fabbricabili e conseguenti ricette, è un r
|
||||
## Cosa sono i nodi e gli oggetti?
|
||||
|
||||
Nodi, oggetti fabbricabili e strumenti sono tutti oggetti.
|
||||
Un oggetto è qualcosa che può essere trovato in un inventario —
|
||||
anche se potrebbe non risultare possibile durante una normale sessione di gioco.
|
||||
Un oggetto è qualcosa che può essere trovato in un inventario — anche se potrebbe non risultare possibile durante una normale sessione di gioco.
|
||||
|
||||
Un nodo è un oggetto che può essere piazzato o trovato nel mondo.
|
||||
Ogni coordinata nel mondo deve essere occupata da un unico nodo —
|
||||
ciò che appare vuoto è solitamente un nodo d'aria.
|
||||
Ogni coordinata nel mondo deve essere occupata da un unico nodo — ciò che appare vuoto è solitamente un nodo d'aria.
|
||||
|
||||
Un oggetto fabbricabile (*craftitem*) non può essere invece piazzato, potendo apparire solo negli inventari
|
||||
o come oggetto rilasciato nel mondo.
|
||||
Un oggetto fabbricabile (*craftitem*) non può essere invece piazzato, potendo apparire solo negli inventari o come oggetto rilasciato nel mondo.
|
||||
|
||||
Uno strumento (*tool*) può usurarsi e solitamente non possiede la capacità di scavare.
|
||||
In futuro, è probabile che gli oggetti fabbricabili e gli strumenti verranno fusi in un unico tipo,
|
||||
in quanto la distinzione fra di essi è alquanto artificiosa.
|
||||
In futuro, è probabile che gli oggetti fabbricabili e gli strumenti verranno fusi in un unico tipo, in quanto la distinzione fra di essi è alquanto artificiosa.
|
||||
|
||||
## Registrare gli oggetti
|
||||
|
||||
@ -60,32 +56,30 @@ Ogni oggetto ha un nome usato per riferirsi a esso, che dovrebbe seguire la segu
|
||||
|
||||
nomemod:nomeoggetto
|
||||
|
||||
Il nomemod equivale appunto al nome della mod che registra l'oggetto, e nomeoggetto è
|
||||
il nome che si vuole assegnare a quest'ultimo.
|
||||
Il nome dell'oggetto dovrebbe essere inerente a quello che rappresenta e deve essere unico nella mod.
|
||||
`nomemod` equivale appunto al nome della mod che registra l'oggetto, e `nomeoggetto` è il nome che si vuole assegnare a quest'ultimo.
|
||||
Esso dovrebbe essere inerente a quello che rappresenta e deve essere unico nella mod.
|
||||
|
||||
Gli oggetti possono anche avere degli *alias* che puntano al loro nome.
|
||||
Un *alias* è uno pseudonimo che dice al motore di gioco di trattarlo come se fosse il nome a cui punta.
|
||||
Ciò è comunemente usato in due casi:
|
||||
|
||||
* Rinominare gli oggetti rimossi in qualcos'altro.
|
||||
Ci potrebbero essere nodi sconosciuti nel mondo e negli inventari se un oggetto
|
||||
viene rimosso da una mod senza nessun codice per gestirlo.
|
||||
È importante evitare di assegnare come alias nomi di nodi inottenibili già esistenti
|
||||
al nodo rimosso, se quest'ultimo poteva essere ottenuto.
|
||||
* Aggiungere una scorciatoia. `/giveme dirt` è più semplice di `/giveme default:dirt`.
|
||||
Ci potrebbero essere nodi sconosciuti nel mondo e negli inventari se un oggetto viene rimosso da una mod senza nessun codice per gestirlo.
|
||||
È importante evitare di assegnare come alias nomi di nodi inottenibili già esistenti al nodo rimosso, se quest'ultimo poteva essere ottenuto.
|
||||
* Aggiungere una scorciatoia.
|
||||
`/giveme dirt` è più semplice di `/giveme default:dirt`.
|
||||
|
||||
Registrare un alias è alquanto semplice.
|
||||
Un buon modo per ricordarne il funzionamento è `da → a`, dove *da*
|
||||
è l'alias e *a* è il nome dell'oggetto a cui punta.
|
||||
|
||||
```lua
|
||||
minetest.register_alias("dirt", "default:dirt")
|
||||
```
|
||||
|
||||
Le mod devono assicurarsi di elaborare gli alias prima di occuparsi direttamente
|
||||
del nome dell'oggeto, in quanto l'engine non lo fa di suo.
|
||||
Ciò è comunque molto semplice:
|
||||
Un buon modo per ricordarne il funzionamento è `da → a`, dove *da*
|
||||
è l'alias e *a* è il nome dell'oggetto a cui punta.
|
||||
|
||||
Le mod devono inoltre assicurarsi di elaborare gli alias prima di occuparsi direttamente del nome dell'oggeto, in quanto l'engine non lo fa di suo.
|
||||
Anche in questo caso non è difficile:
|
||||
|
||||
```lua
|
||||
itemname = minetest.registered_aliases[itemname] or itemname
|
||||
@ -93,17 +87,13 @@ itemname = minetest.registered_aliases[itemname] or itemname
|
||||
|
||||
### Texture
|
||||
|
||||
Per convenzione le texture andrebbero messe nella cartella textures/ con nomi che seguono la struttura
|
||||
`nomemod_nomeoggetto.png`.\\
|
||||
Le immagini in JPEG sono supportate, ma non supportano la trasparenza e sono generalmente
|
||||
di cattiva qualità nelle basse risoluzioni.
|
||||
Per convenzione le texture andrebbero messe nella cartella textures/ con nomi che seguono la struttura `nomemod_nomeoggetto.png`.\\
|
||||
Le immagini in JPEG sono supportate, ma non supportano la trasparenza e sono generalmente di cattiva qualità nelle basse risoluzioni.
|
||||
Si consiglia quindi il formato PNG.
|
||||
|
||||
Le texture su Minetest sono generalmente 16x16 pixel.
|
||||
Possono essere di qualsiasi dimensione, ma è buona norma che rientrino nelle potenze di 2,
|
||||
per esempio 16, 32, 64 o 128.
|
||||
Questo perché dimensioni differenti potrebbero non essere supportate dai vecchi dispositivi,
|
||||
comportando una diminuzione delle performance.
|
||||
Possono essere di qualsiasi dimensione, ma è buona norma che rientrino nelle potenze di 2, per esempio 16, 32, 64 o 128.
|
||||
Questo perché dimensioni differenti potrebbero non essere supportate dai vecchi dispositivi, comportando una diminuzione delle performance.
|
||||
|
||||
## Registrare un nodo base
|
||||
|
||||
@ -139,19 +129,18 @@ minetest.register_node("miamod:diamante", {
|
||||
is_ground_content = true,
|
||||
groups = {cracky = 3},
|
||||
drop = "miamod:diamante_frammenti"
|
||||
-- ^ Al posto di rilasciare diamanti, rilascia miamod:diamante_frammenti
|
||||
-- ^ Al posto di far cadere diamanti, fa cadere miamod:diamante_frammenti
|
||||
})
|
||||
```
|
||||
|
||||
L'attributo is_ground_content è essenziale per ogni nodo che si vuole far apparire sottoterra
|
||||
durante la generazione della mappa.
|
||||
L'attributo is_ground_content è essenziale per ogni nodo che si vuole far apparire sottoterra durante la generazione della mappa.
|
||||
Le caverne vengono scavate nel mondo dopo che tutti gli altri nodi nell'area sono stati generati.
|
||||
|
||||
## Azioni e callback
|
||||
|
||||
Minetest usa ampiamente una struttura per il modding incentrata sui callback (richiami).
|
||||
I callback possono essere inseriti nella tabella di definizioni dell'oggetto per permettere una
|
||||
risposta a vari tipi di eventi generati dall'utente.
|
||||
I callback possono essere inseriti nella tabella di definizioni dell'oggetto per permettere una risposta a vari tipi di eventi generati dall'utente.
|
||||
Vediamone un esempio.
|
||||
|
||||
### on_use
|
||||
|
||||
@ -167,14 +156,11 @@ minetest.register_craftitem("miamod:fangotorta", {
|
||||
})
|
||||
```
|
||||
|
||||
Il numero fornito alla funzione minetest.item_eat è il numero di punti salute ripristinati al
|
||||
consumare il cibo.
|
||||
Il numero fornito alla funzione minetest.item_eat è il numero di punti salute ripristinati al consumare il cibo.
|
||||
In gioco ogni cuore equivale a due punti.
|
||||
Un giocatore ha solitamente un massimo di 10 cuori, ovvero 20 punti salute.
|
||||
Quest'ultimi non devono per forza essere interi, bensì possono anche essere decimali.
|
||||
Un giocatore ha solitamente un massimo di 10 cuori, ovvero 20 punti salute, e quest'ultimi non devono per forza essere interi - ovvero decimali.
|
||||
|
||||
minetest.item_eat() è una funzione che ritorna un'altra funzione, in questo caso
|
||||
quindi impostandola come callback di on_use.
|
||||
`minetest.item_eat()` è una funzione che ritorna un'altra funzione, in questo caso quindi impostandola come callback di on_use.
|
||||
Ciò significa che il codice in alto è alquanto simile al seguente:
|
||||
|
||||
```lua
|
||||
@ -200,14 +186,12 @@ Ci sono diversi tipi di ricette di fabbricazione disponibili, indicate dalla pro
|
||||
* fuel - Definisce gli oggetti che possono alimentare il fuoco nella fornace.
|
||||
* tool_repair - Definisce gli oggetti che possono essere riparati.
|
||||
|
||||
Le ricette di fabbricazione non sono oggetti, perciò non usano nomi oggetto per
|
||||
identificare in maniera univoca se stesse
|
||||
Le ricette di fabbricazione non sono oggetti, perciò non usano nomi oggetto per identificare in maniera univoca se stesse.
|
||||
|
||||
### Fisse (shaped)
|
||||
|
||||
Le ricette fisse avvengono quando gli ingredienti devono essere nella forma o sequenza
|
||||
corretta per funzionare. Nell'esempio sotto, i frammenti necessitano di essere in
|
||||
in una figura a forma di sedia per poter fabbricare appunto 99 sedie.
|
||||
Le ricette fisse avvengono quando gli ingredienti devono essere nella forma o sequenza corretta per funzionare.
|
||||
Nell'esempio sotto, i frammenti necessitano di essere in una figura a forma di sedia per poter fabbricare appunto 99 sedie.
|
||||
|
||||
```lua
|
||||
minetest.register_craft({
|
||||
@ -222,8 +206,7 @@ minetest.register_craft({
|
||||
```
|
||||
|
||||
Una cosa da tener presente è la colonna vuota sulla parte destra.
|
||||
Questo significa che ci *deve* essere una colonna vuota a destra della forma, altrimenti
|
||||
ciò non funzionerà.
|
||||
Questo significa che ci *deve* essere una colonna vuota a destra della forma, altrimenti ciò non funzionerà.
|
||||
Se invece la colonna non dovesse servire, basta ometterla in questo modo:
|
||||
|
||||
```lua
|
||||
@ -237,13 +220,11 @@ minetest.register_craft({
|
||||
})
|
||||
```
|
||||
|
||||
Il campo type non è davvero necessario per le ricette fisse, in quanto sono
|
||||
il tipo di base.
|
||||
Il campo type non è davvero necessario per le ricette fisse, in quanto sono il tipo di base.
|
||||
|
||||
### Informi (shapeless)
|
||||
|
||||
Le ricette informi sono ricette che vengono usate quando non importa
|
||||
dove sono posizionati gli ingredienti, ma solo che ci siano.
|
||||
Le ricette informi sono ricette che vengono usate quando non importa dove sono posizionati gli ingredienti, ma solo che ci siano.
|
||||
|
||||
```lua
|
||||
minetest.register_craft({
|
||||
@ -259,9 +240,7 @@ minetest.register_craft({
|
||||
|
||||
### Cottura (cooking) e carburante (fuel)
|
||||
|
||||
Le ricette di tipo "cottura" non vengono elaborate nella griglia di fabbricazione,
|
||||
bensì nelle fornaci o in qualsivoglia altro strumento di cottura che può essere trovato
|
||||
nelle mod.
|
||||
Le ricette di tipo "cottura" non vengono elaborate nella griglia di fabbricazione, bensì nelle fornaci o in qualsivoglia altro strumento di cottura che può essere trovato nelle mod.
|
||||
|
||||
```lua
|
||||
minetest.register_craft({
|
||||
@ -272,17 +251,13 @@ minetest.register_craft({
|
||||
})
|
||||
```
|
||||
|
||||
L'unica vera differenza nel codice è che in questo la ricetta non è una tabella (tra parentesi graffe),
|
||||
bensì un singolo oggetto.
|
||||
Le ricette di cottura dispongono anche di un parametro aggiuntivo "cooktime"
|
||||
che indica in secondi quanto tempo ci impiega l'oggetto a cuocersi.
|
||||
L'unica vera differenza nel codice è che in questo la ricetta non è una tabella (tra parentesi graffe), bensì un singolo oggetto.
|
||||
Le ricette di cottura dispongono anche di un parametro aggiuntivo "cooktime" che indica in secondi quanto tempo ci impiega l'oggetto a cuocersi.
|
||||
Se non è impostato, di base è 3.
|
||||
|
||||
La ricetta qui sopra genera un'unità di frammenti di diamante dopo 10 secondi quando
|
||||
il blocco di carbone (coalblock) è nello slot di input, con un qualche tipo di carburante sotto di esso.
|
||||
La ricetta qui sopra genera un'unità di frammenti di diamante dopo 10 secondi quando il blocco di carbone (`coalblock`) è nello slot di input, con un qualche tipo di carburante sotto di esso.
|
||||
|
||||
Il tipo "carburante" invece funge da accompagnamento alle ricette di cottura,
|
||||
in quanto definisce cosa può alimentare il fuoco.
|
||||
Il tipo "carburante" invece funge da accompagnamento alle ricette di cottura, in quanto definisce cosa può alimentare il fuoco.
|
||||
|
||||
```lua
|
||||
minetest.register_craft({
|
||||
@ -292,14 +267,13 @@ minetest.register_craft({
|
||||
})
|
||||
```
|
||||
|
||||
Esso non ha un output come le altre ricette, e possiede un tempo di arsura (burntime)
|
||||
che definisce in secondi per quanto alimenterà la fiamma. In questo caso, 300 secondi!
|
||||
Esso non ha un output come le altre ricette, e possiede un tempo di arsura (`burntime`) che definisce in secondi per quanto alimenterà la fiamma.
|
||||
In questo caso, 300 secondi!
|
||||
|
||||
## Gruppi
|
||||
|
||||
Gli oggetti possono essere membri di più gruppi, e i gruppi possono avere più membri.
|
||||
Essi sono definiti usando la proprietà `groups` nella tabella di definizione,
|
||||
e possiedono un valore associato.
|
||||
Essi sono definiti usando la proprietà `groups` nella tabella di definizione, e possiedono un valore associato.
|
||||
|
||||
```lua
|
||||
groups = {cracky = 3, wood = 1}
|
||||
@ -307,8 +281,7 @@ groups = {cracky = 3, wood = 1}
|
||||
|
||||
Ci sono diverse ragioni per cui usare i gruppi.
|
||||
In primis, vengono utilizzati per descrivere proprietà come friabilità e infiammabilità.
|
||||
In secundis, possono essere usati in una ricetta al posto di un nome oggetto per permettere
|
||||
a qualsiasi oggetto nel gruppo di essere utilizzato.
|
||||
In secundis, possono essere usati in una ricetta al posto di un nome oggetto per permettere a qualsiasi oggetto nel gruppo di essere utilizzato.
|
||||
|
||||
```lua
|
||||
minetest.register_craft({
|
||||
@ -320,11 +293,9 @@ minetest.register_craft({
|
||||
|
||||
## Strumenti, Capacità e Friabilità
|
||||
|
||||
Le friabilità sono dei gruppi particolari utilizzati per definire la resistenza di un nodo
|
||||
quando scavato con un determinato strumento.
|
||||
Le friabilità sono dei gruppi particolari utilizzati per definire la resistenza di un nodo quando scavato con un determinato strumento.
|
||||
Una friabilità elevata equivale a una maggior facilità e velocità nel romperlo.
|
||||
È possibile combinarne di più tipi per permettere al nodo di essere distrutto da più tipi di strumento.
|
||||
Un nodo senza friabilità non può essere distrutto da nessuno strumento.
|
||||
È possibile combinarne di più tipi per permettere al nodo di essere distrutto da più tipi di strumento, mentre un nodo senza friabilità non può essere distrutto da nessuno strumento.
|
||||
|
||||
| Gruppo | Miglior strumento | Descrizione |
|
||||
|---------|-------------------|-------------|
|
||||
@ -337,15 +308,11 @@ Un nodo senza friabilità non può essere distrutto da nessuno strumento.
|
||||
| oddly_breakable_by_hand | *qualsiasi* | Torce e simili — molto veloci da rompere |
|
||||
|
||||
|
||||
Ogni strumento possiede poi delle capacità (capability).
|
||||
Una capacità include una lista di friabilità supportate, e proprietà associate
|
||||
per ognuna di esse come la velocità di scavata e il livello di usura.
|
||||
Gli strumenti possono anche avere una durezza massima supportata per ogni tipo;
|
||||
ciò serve a prevenire che strumenti più deboli possano rompere nodi meno friabili.
|
||||
È poi molto comune che uno strumento includa tutte le friabilità nelle sue capacità,
|
||||
con quelle meno adatte equivalenti a proprietà inefficienti.
|
||||
Se l'oggetto impugnato dal giocatore non ha una capacità esplicitata,
|
||||
verrà allora usata quella della mano.
|
||||
Ogni strumento possiede poi delle capacità (*capability*).
|
||||
Una capacità include una lista di friabilità supportate, e proprietà associate per ognuna di esse come la velocità di scavata e il livello di usura.
|
||||
Gli strumenti possono anche avere una durezza massima supportata per ogni tipo; ciò serve a prevenire che strumenti più deboli possano rompere nodi meno friabili.
|
||||
È poi molto comune che uno strumento includa tutte le friabilità nelle sue capacità, con quelle meno adatte equivalenti a proprietà inefficienti.
|
||||
Se l'oggetto impugnato dal giocatore non ha una capacità esplicitata, verrà allora usata quella della mano.
|
||||
|
||||
```lua
|
||||
minetest.register_tool("miamod:strumento", {
|
||||
@ -365,6 +332,5 @@ minetest.register_tool("miamod:strumento", {
|
||||
},
|
||||
})
|
||||
```
|
||||
I gruppi limite (groupcaps) sono una lista delle friabilità supportate dallo strumento.
|
||||
I gruppi di danno invece (damage_groups) servono a controllare come uno strumento (esterno) danneggia
|
||||
quell'oggetto. Quest'ultimi verranno discussi in seguito nel capitolo Oggetti, Giocatori e Entità.
|
||||
I gruppi limite (`groupcaps`) sono una lista delle friabilità supportate dallo strumento.
|
||||
I gruppi di danno invece (`damage_groups`) servono a controllare come uno strumento (esterno) danneggia quell'oggetto. Quest'ultimi verranno discussi in seguito nel capitolo Oggetti, Giocatori e Entità.
|
||||
|
||||
@ -9,7 +9,7 @@ redirect_from:
|
||||
- /it/map/node_metadata.html
|
||||
---
|
||||
|
||||
## Introduction <!-- omit in toc -->
|
||||
## Introduzione <!-- omit in toc -->
|
||||
|
||||
In questo capitolo imparerai i vari modi per immagazzinare dati.
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ redirect_from: /it/chapters/chat_complex.html
|
||||
|
||||
## Introduzione <!-- omit in toc -->
|
||||
|
||||
Questo capitolo ti mostrerà come creare comandi complessi con ChatCmdBuilder, come `/msg <nome> <messaggio>`, `/team entra <nometeam>` or `/team esci <nometeam>`.
|
||||
Questo capitolo ti mostrerà come creare comandi complessi con ChatCmdBuilder, come `/msg <nome> <messaggio>`, `/team entra <nometeam>` o `/team esci <nometeam>`.
|
||||
|
||||
Tieni conto che ChatCmdBuilder è una libreria creata dall'autore di questo libro, e che molti modder tendono a usare il metodo illustrato nel capitolo [Chat e comandi](chat.html#complex-subcommands).
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ I privilegi non sono fatti per indicare classi o status.
|
||||
* ban
|
||||
* vote
|
||||
* worldedit
|
||||
* area_admin - admin functions of one mod is ok
|
||||
* area_admin - se si tratta di un privilegio per gli amministratori è ok
|
||||
|
||||
**Privilegi sbagliati:**
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user