Questa operazione è estremamente utile per aumentare la modularità di uno script e per attuare delle modifiche senza dover modificare e ricompilare il codice.

In script aventi una complessità medio-alta, la tecnica di salvare informazioni in un file di testo esterno è estremamente diffusa.

Il presente articolo si prefigge l’obiettivo di semplificare e rendere automatica una operazione di questo tipo. Lo script prevede una fase di impostazione delle variabile ed una fase di validazione delle stesse.

Inizio con il postare il codice completo del template per poi discutere le parti essenziali con un esempio.

// ReadConfiguration
//
// Il seguente template viene usato per leggere un file di configurazione.
// Il file di configurazione può essere formattato nel seguente modo:
// <var>        Singola variabile
// <var>=<var>    Variabile <var> che deve essere inizializzata con il valore in <var>
// # line        Linea di commento
//
// @version 1.0
// @author MarcoDuff Palen (http://www.marcoduff.com/)

// Variabili
string configNotecard;
integer line;
key requestId;

// Legge i singoli comandi di configurazione.
//
// @param var    Nome della variabile letta (sempre totalmente maiuscola).
// @param val    Valore della variabile associata o una stringa vuota in caso di nessuna inizializzazione.
readConfig(string var, string val) {
}

// Valida la configurazione.
//
// @return    Restituisce TRUE se la configurazione è valida, FALSE altrimenti.
integer validateConfig() {
    return TRUE;
}

// Stato di inizializzazione.
default {
    state_entry() {
        configNotecard = llGetScriptName()+".config";
        line = 0;
        requestId = llGetNotecardLine(configNotecard,line);
    }

    state_exit() {
        line = -1;
        requestId = NULL_KEY;
    }

    dataserver(key request_id, string data) {
        if(requestId==request_id) {
            if(data!=EOF) {
                data = llStringTrim(data,STRING_TRIM);
                if(llSubStringIndex(data,"#")!=0&&llStringLength(data)>0) {
                    list dataList = llParseString2List(data,["="],[]);
                    string var = llToUpper(llStringTrim(llList2String(dataList,0),STRING_TRIM));
                    string val = "";
                    if(llGetListLength(dataList)==2) val = llStringTrim(llList2String(dataList,1),STRING_TRIM);
                    readConfig(var,val);
                }
                line++;
                requestId = llGetNotecardLine(configNotecard,line);
            }
            else {
                integer validate = validateConfig();
                if(validate == TRUE) state ConfigOkState;
                else state ConfigErrorState;
            }
        }
    }
}

// Stato se la configurazione è andata a buon fine.
state ConfigOkState {
    changed(integer change) {
        if(change & CHANGED_INVENTORY) llResetScript();
    }
}

// Stato se la configurazione è errata.
state ConfigErrorState {
    changed(integer change) {
        if(change & CHANGED_INVENTORY) llResetScript();
    }
}

Lo script non fa altro che cercare il file di testo nel contents dell’oggetto chiamato come lo script e con estenzione .config, leggere tutte le righe del file ignorando le linee vuote e le linee che iniziano con il carattere #, validare le variabili lette e portarsi nello stato ConfigOkState se tutto è andato a buon fine o nello stato ConfigErrorState in caso di errori.

Questo significa che lo stato di default della nostra applicazione diventa ConfigOkState. Le uniche righe di codice da modificare nel template sono, infatti, l’inserimeto delle variabili utili al problema, il contenuto delle due funzioni readConfig e validateConfig e gli stati ConfigOkState e ConfigErrorState.

Facciamo un esempio che spiega il funzionamento del template.

Supponiamo di voler creare un oggetto che visualizzi un testo sopra di esso. Il testo ed il colore dell’oggetto devono essere specificati in un file di testo esterno allo script. Il testo deve sempre specificato, mentre il colore, se non specificato, deve essere nero.

Il modo più semplice per lavorare con questo template è creare prima il file di testo di configurazione. Suppunendo di voler visualizzare il testo “Prova riuscita!!!” di colore blu, il file di testo risulta essere il seguente:

# Questa è una prova di configurazione dello script ReadConfiguration

# Text indica il testo da visualizzare
text = Prova riuscita!!!

# Color è opzionale, fai i tentativi commentando o impostando la variabile!
color = <0.0,0.0,1.0>

Notate il massiccio uso di commenti (righe che iniziano con il carattere #) che verranno ignorati, insieme alle righe vuote, dallo script.

Come possiamo notare dal file di testo, per soddisfare questo problema abbiamo sicuramente bisogno di due variabili: la prima di tipo string per salvare il testo da visualizzare, la seconda di tipo vector per il colore.

Questo significa che al template bisogna aggiungere in testa il seguente codice:

string text;
vector color;

l’impostazione di queste due variabili viene fatto all’interno della funzione readConfig. Questa funzione, infatti, riceve in input due variabili chiamate var e val che contengono rispettivamente la parte sinistra e quella destra rispetto al simbolo = di ogni riga letta nel file di configurazione (se non è presente il simbolo = allora viene valorizzata solo la variabile var). La variabile var ha la particolarità di essere sempre in maiuscolo, mentre la variabile val mantiene i caratteri originali.

Per fare un esempio, quando lo script leggerà la riga “text = Prova riuscita!!!” richiamerà la funzione readConfig passando per var il valore “TEXT” mentre per val il valore “Prova riuscita!!!”.

Detto questo, modifichiamo l’interno della funzione readConfig per impostare le nostre variabili text e color in questo modo:

readConfig(string var, string val) {
    if(var=="TEXT") text = val;
    else if(var=="COLOR") color = (vector)val;
    else llOwnerSay("[WARNING] Variabile "+var+" alla linea "+(string)(line+1)+" non prevista.");
}

in questo modo quando verranno letti i due valori dal file di testo, questi verranno opportunamente impostati nelle variabili. Notate che in questa particolare implementazione, se viene letto un comando non previsto viene dato un warning all’owner dello script che ha un utile feedback (pensate a quante volte avete perso tempo inutile per un semplice errore di battitura come scrivere “calor” invece di “color” o simili… mettere feedback di questo tipo è sempre molto utile e assolutamente consigliato). Notate anche come ho utilizzato la variabile line che indica la linea corrente di lettura del file (p.s.: ho dovuto incrementarla di 1 visto che la prima riga di un file di testo parte da 0!).

Se vogliamo inserire una validazione o vogliamo mettere dei valori di default per una variabile, dobbiamo modificare il contenuto della funzione validateConfig (se non vogliamo farlo, ci basta lasciare il return TRUE;). Nel nostro esempio dobbiamo controllare che il testo sia stato inserito, visto che lo consideriamo obbligatorio, mentre dobbiamo controllare che se il colore non è stato inserito dobbiamo impostarlo a Nero. La modifica da attuare è la seguente:

integer validateConfig() {
    if(color == ZERO_VECTOR) color = <0.0,0.0,0.0>;

    if(llStringLength(text)==0) llOwnerSay("[ERROR] Non hai impostato la variabile TEXT");
    else return TRUE;

    return FALSE;
}

se noto che la variabile color non è stata impostato, lo imposta io a nero. Se noto che la variabile text non è stata impostata stampo un messaggio di errore. Notare che la funzione restituisce TRUE esclusivamente nel caso in cui la variabile text viene impostata, in tutti gli altri casi restituisce FALSE. Il risultato della funzione TRUE o FALSE impone il passaggio di stato rispettivamente a ConfigOkState a ConfigErrorState.

A questo punto non ci resta che riempire lo stato ConfigOkState con il codice che avremmo scritto nello stato default di un normale script ma supponendo che le variabili a noi utili siano già state impostate, mentre lo stato ConfigErrorState con eventuali messaggi di errore. Ad esempio:

state ConfigOkState {
    state_entry() {
        llSetText(text,color,1.0);
    }

    changed(integer change) {
        if(change & CHANGED_INVENTORY) llResetScript();
    }
}

state ConfigErrorState {
    state_entry() {
        llOwnerSay("Errore di configurazione nel file "+configNotecard);
    }
    changed(integer change) {
        if(change & CHANGED_INVENTORY) llResetScript();
    }
}

Notate che tutti e due gli stati gestiscono l’evento changed in modo da captare eventuali modifiche del file di configurazione e resettarsi in automatico (ovviamente se non si vuole questa estenzione basta cancellare l’evento!).

Per chiarezza posto il codice completo dell’esempio:

// ReadConfiguration
//
// Il seguente template viene usato per leggere un file di configurazione.
// Il file di configurazione può essere formattato nel seguente modo:
// <var>        Singola variabile
// <var>=<val>    Variabile <var> che deve essere inizializzata con il valore in <val>
// # line        Linea di commento
//
// @version 1.0
// @author MarcoDuff Palen (http://www.marcoduff.com/)

// QUI INSERISCO LE VARIABILI DA RIEMPIRE TRAMITE IL FILE DI CONFIGURAZIONE
string text;
vector color;

// Variabili
string configNotecard;
integer line;
key requestId;

// Legge i singoli comandi di configurazione.
//
// @param var        Nome della variabile letta (sempre totalmente maiuscola).
// @param val        Valore della variabile associata o una stringa vuota in caso di nessuna inizializzazione.
readConfig(string var, string val) {
    // QUI INSERISCO I SETTAGGI DELLE VARIABILI
    llOwnerSay("[INFO] Reading "+var+" = "+val+" on line "+(string)(line+1));
    if(var=="TEXT") text = val;
    else if(var=="COLOR") color = (vector)val;
    else llOwnerSay("[WARNING] Variabile "+var+" alla linea "+(string)(line+1)+" non prevista.");
}

// Valida la configurazione.
//
// @return            Restituisce TRUE se la configurazione è valida, FALSE altrimenti.
integer validateConfig() {
    // QUI INSERISCO L'EVENTUALE VALIDAZIONE DELLE VARIABILI

    // Il colore non è una variabile richiesta, se non viene impostata la imposto a nero
    if(color == ZERO_VECTOR) color = <0.0,0.0,0.0>;

    // Il testo è una variabile fondamentale, mando un messaggio di errore
    if(llStringLength(text)==0) llOwnerSay("Non hai impostato la variabile TEXT");
    else return TRUE;

    return FALSE;
}

// Funzione per la visualizzazione dell'output.
//
// @param message    Messaggio da visualizzare.
// @param color        Colore di visualizzazione.
showOutput(string message, vector color) {
    llSetText(message,color,1.0);
}

// Stato di inizializzazione.
default {
    state_entry() {
        configNotecard = llGetScriptName()+".config";
        showOutput("Reading "+configNotecard,<0.0,1.0,0.0>);
        line = 0;
        requestId = llGetNotecardLine(configNotecard,line);
    }

    state_exit() {
        line = -1;
        requestId = NULL_KEY;
        showOutput("",ZERO_VECTOR);
    }

    dataserver(key request_id, string data) {
        if(requestId==request_id) {
            if(data!=EOF) {
                data = llStringTrim(data,STRING_TRIM);
                if(llSubStringIndex(data,"#")!=0&&llStringLength(data)>0) {
                    list dataList = llParseString2List(data,["="],[]);
                    string var = llToUpper(llStringTrim(llList2String(dataList,0),STRING_TRIM));
                    string val = "";
                    if(llGetListLength(dataList)==2) val = llStringTrim(llList2String(dataList,1),STRING_TRIM);
                    readConfig(var,val);
                }
                line++;
                requestId = llGetNotecardLine(configNotecard,line);
            }
            else {
                integer validate = validateConfig();
                if(validate == TRUE) state ConfigOkState;
                else state ConfigErrorState;
            }
        }
    }
}

// Stato se la configurazione è andata a buon fine.
state ConfigOkState {
    state_entry() {
        // SE TUTTO E' ANDATO BENE VISUALIZZO IL TESTO SULL'OGGETTO CON I PARAMETRI DEL FILE DI CONFIGURAZIONE
        llSetText(text,color,1.0);
    }

    changed(integer change) {
        if(change & CHANGED_INVENTORY) llResetScript();
    }
}

// Stato se la configurazione è errata.
state ConfigErrorState {
    state_entry() {
        // SE TUTTO E' ANDATO MALE VISUALIZZO UN ERRORE
        llOwnerSay("Errore di configurazione nel file "+configNotecard);
    }
    changed(integer change) {
        if(change & CHANGED_INVENTORY) llResetScript();
    }
}

Buono Scripting LSL a tutti!

Video di Natale girato alla Land del Forum per CBM Italia Onlus dal grande Yash!

Io sono quello al minuto 2:57!

Indeciso fino alla fine se rispondere o tacere. Molti mi consiglierebbero di tacere, sopratutto i miei nemici. Ma il punto è capire chi sono questi nemici… perché il non lo so.

Allora li esamino ad uno ad uno… a partire dalla più importante Alice.

Ovviamente non sei la più importante, ma ti piace pensare di esserlo (il grassetto ovviamente non sei tu, ma adoro il tuo egocentrismo che ti fa accaparrare tutto l’accaparrabile). Ma si, sei una mia amica. Perchè con te c’è sempre stato un rapporto di odio e odio, ma di quello che mi ha sempre portato a dire “Io Alice devo conoscerla di persona”, ed ho molti testimoni che possono confermare questa mia frase. Abbiamo avuto tantissimi battibecchi in passato e ne avremo almeno altri duemila in futuro, sei testarda da morire, ma anche se è molto duro farlo, con te si può parlare.

E con te ho finito! Quindi non cercare altri riferimenti alla tua persona dopo questa riga perché sono finiti, volendo puoi anche chiudere la pagina.

Tornando seri…

Sumichan non so chi sia, ma le sue parole, come quelle di Castalia, sono sempre state le lette con un grande sorriso. Penso sia positivo!

Helm è un amico anche in RL. Continuo a non capire i suoi riferimenti alla cricca di intoccabili, che continua ad essere una sterile polemica. Helm, è cosi che la penso e credo di averla detta in tutte le salse. Tra gli intoccabili, o presunti tali, vi sono (parlando di ex-mod) MarcoDuff, Annett, Alice, Enea e tra gli utenti Publio, Esecutore, Darko? Tutti questi hanno ricevuto almeno un richiamo nella loro carriera e più di uno un ban. i continuo a domandare… chi sono questi privilegiati? Se X fa 1 a Y ed Y, per risposta, fa 100 a X… mi dispiace, è Y che avrà le conseguenze peggiori. Si, è brutto a dirsi… ma mica sei autorizzato a sparare in testa ad un ladro che ti ruba casa, no? In ogni caso, continuo a dire… lasciate correrre… chi se ne frega! Provate a chiarire tra di voi… è Second Life! Spetta a noi residenti renderla migliore della nostra First Life!

Sonia. Questa è stata una sorpresa… visto che non mi aspettavo quel tipo di post. Faccio subito una premessa sulla parte iniziale, non so perché l’hai scritta, probabilmente per errore ma sinceramente non l’ho capita. Io non ho apportato alcuna censura al commento. Nessun commento viene censurato, esiste una moderazione per il semplice fatto che essendo il mio blog voglio che scrivano al suo interno soltanto persone che conosco, il filtro sta sull’autore, assolutamente non sul contenuto. Sonia, non mi sono mai vantato di essere un lupo, figuriamoci! E’ stata una etichetta che mi è stata associata e alla quale sono rimasto molto affezionato. No, non sono un animale nobile e nemmeno una faina, non mi interessa il pettegolezzo e non sono mai stato il primo ad attaccare. Le mie sono sempre state delle risposte ragionate, magari in ritardo, ma mai fatte con cattiveria. Conosco mille persone disposte a dimostrare esattamente il contrario di quello che ho affermato e ne conosco altrettante mille capaci di confermarlo… lascio a questi duecento individui la briga di giudicarmi, cosa che ovviamente non faranno perché sono tre o quattro di quelli non mi ignorano come è giusto che sia!

Angelica *umpf*. Altra persona che vorrei conoscere per capire se sei vera oppure ti diverti ad impersonare un personaggio. Inizio chiedendoti scusa. Ti chiedo scusa perché probabilmente mi sono espresso male nel mio post. Il tuo commento, infatti, devo ignorarlo… perché rispondi a frasi non rivolte a te in modo nemmeno esatto. Penso che tutto sia da ricondurre alla mancata comprensione del post. Tanto per fare degli esempi: la citazione “E’ una guerra e bisogna combattere” che fai è ovviamente una frase ironica, non esiste nessuna guarra! Implica il fatto che non ti ho mai visto come una nemica, al massimo come una ingenua, come tu stessa confermi di essere in più di un pm che mi hai inviato in passato. Inoltre ho parlato del ban a te e basta! Dove ho affermato che non andavano presi altri provvedimenti verso altre persone? Dove ho detto che non parli mai per te stessa? Penso che lo fai! Inoltre non ho nessun preconcetto nei tuoi confronti… la tua voglia di polemizzare contro la moderazione è risaputa come da tua stessa affermazione (PM), ma capisco anche che lo fai per difendere “a modo tuo” la community (che IMHO è il modo peggiore per difenderla). Ultima precisazione… non ho nessun problema a dire che la bannata è Angelica Lean, ma scherziamo??? Anche questo era un riferimento ad una frase urlata sui bannati che mi ha fatto ridere! E poi c’è veramente qualcuno che non ha capito che eri tu???

Sul legittimo disprezzo avrei da ridire… perché non ho capito. O meglio, il disprezzo alla fine ci può stare, pazienza, avrò sbagliato qualche cosa… il legittimo può essere discutibile. Ma quello su cui non si discute è ovviamente il regolamento. Capisco che un navigatore con un quoziente intellettivo pari a 1 ci stia meno di un micro secondo a scoprire la mia professione, ma che un amministratore di un forum, che è andato via da un altro forum per questo stesso motivo, nel suo forum si vanti ricevendo anche complimenti da altri utenti di aver fatto un regolamento che tuteli la sfera personale degli iscritti, e che poi si permetta di scrivere la mia professione violando le stesse regole scritte da lui, mi lascia quantomeno perplesso. Ma tranquilla, faccio io il primo passo. Voglio collaborare! Autorizzo ufficialmente l’amministratore a scrivere la mia professione sul suo forum! Perché è di questo che parlavo… collaborare e mi dispiace aver ricevuto una chiusura da parte tua. Dicevo che avere alternative sarebbe bello e stimolante. Chi se ne frega di chi ha più utenti! Tutti sappiamo che il numero del forum è falsato… e allora? Chi ha detto che sono migliori le community con 1000 iscritti postanti rispetto ad una con 1000000 iscritti con 100 postanti? Penso che community sia un luogo dove ti senti a tuo agio. Io nel mio forum sto a mio agio. Nel tuo ovviamente no, tanto che non sono iscritto. Ma non lo prendere come un attacco! Parliamoci chiaro, su 276 post quanti parlano di Second Life (visto che più della metà stanno in aree private)? Per una volta ascoltate il consiglio del vostro moderatore Darko, basta parlare del forum (sul serio… il tuo sembra il Forum del Forum!)! Inizia a mettere contenuti e togli quella stupida regola “vietato insultare la moderatrice da siti esterni”!!! Ma daiiiii!!! E poi chiamavi la mia censura??? Metti un paio di contenuti in quel forum, pulisci il db e stai certa che al primo topic interessante sugli script avrai un nuovo utente iscritto (perchè é cosi che mi farai sentire a mio agio e attirerai utenti attivi… altrimenti attiri utenti con rancore odio o come lo chiami tu, legittimo disprezzo!).

Piccola precisazione per non perdere amicizie! Non ho mai identificato come nemico Tayra e Sonia… con Tayra continuiamo a sentirci in modo più o meno regolare per piacevoli brevi chiacchierate su script. Magari abbiamo avuto discussioni in passato (anche se adesso non le focalizzo), ma penso si siano risolte nel migliore dei modi! Darko è un caso a parte anche se non lo reputo un nemico. Sfortunatamente con lui non riesco a spiegarmi in modo corretto, sopratutto utilizzando mezzi come PM chat e compagnia bella. Per questo motivo ho dato a Darko il mio numero di cellulare, cosa che non avrei sicuramente dato ad un nemico o ad una persona con cui voglio chiudere un rapporto. Inoltre lui mi ha pure regalato la sua collezione 2007 in SL! Detto questo… mi sono rimasti veramente pochi nemici… appena ho i nomi li posto!

Dulcis in fundo… un rapporto va curato… ma che significa curare? Perché alcune volte ho come l’impressione che serva un manuale, un insieme di regole da seguire, in modo preciso, senza mai sbagliare altrimeti cadi! Caschi giù e di nuovo tutto da capo… ma sempre più fragile.

Seconda vita del cavolo.

Il che equivale a dire vita del cavolo. Ma per fortuna solo una parte, una piccolissima parte, la parte più piccola in assoluto.

Perché ho la grande fortuna che le persone importanti della seconda vita adesso fanno parte della prima vita.

Perché ho la grande sfortuna che le persone importanti della seconda vita adesso fanno parte della prima vita.

Non mi sono creato una seconda vità per scappare dalla mia prima bellissima vita, ma come la mettiamo se io adesso volessi scappare dalla mia second vita. No, non sono l’unico che l’ha fatto… una persona, finita nel dimenticatoio ormai da tanto tempo, dimeticata dai più, l’ha fatto. Si chiama Iao… o forse si chiamava, visto che non so nemmeno che fine abbia fatto… ogni tanto domando. Ed un’altra persona a cui sono molto affezionato sta lasciando lentamente… lentamente perché so che in cuore suo non vuole farlo, ma ne è costretta dalla noia e dalla polemica… Medea.

E a queste chi si aggiunge? Io? Forse si, forse no. Sarebbe bello avere alternative, fare parte di più community, condividere le informazioni, collaborare, evitare polemica. Ma, guardate la coincidenza della frase, questo nelle community straniere accade in Italia no! Si, il riferimento è dritto a te. Perché come te, ogni giorno ti leggo e sorrido… sorrido per ipocrisia. Fino a quando sei ipocrita con il nemico, ci può stare! E’ una guerra e bisogna combattere… ma non puoi essere ipocrita con le tue stesse frasi o peggio ancora con la tua stessa firma. Ma ti capisco, l’odio ed il rancore rende ciechi.

E poi un’altra… la bannata della situazione. Adesso prendi appunti, perché grazie alla mia non indifferenza ho avuto un grosso battibecco con la moderazione ed ho litigato in modo aspro con una cara amica. Quindi non ti azzardare un’altra volta a dire che gli ex-moderatori sono privilegiati, che ci sono utenti tutelati e che si fa sempre una barriera per difendere i moderatori. Hai avuto la dimostrazione in mano che Annett non è stata privilegiata, che se esistono utenti privilegiati quella sei stata proprio tu visto che personalmente ti avrei bannato già una settimana fa e per molti più giorni e che le barricate non esistono visto che personalmente ho litigato e discusso con buona parte della moderazione in modo incivile ma rispettando il regolamento, ecco perché non ti accorgi di nulla visto che questo tipo di comunicazioni vanno fatte via PM. Quindi la prossima volta che ti vengono queste idee pensa bene a quello che vedi scritto qui, perché se continui, IMHO, sei solo una ragazzina amante della polemica.

E se qualcuno scrive una frase per solidarietà, per un saluto, per divertimento e la mette in firma ci stiamo (me compreso) un micro secondo a scandirla e a vederci dietrologie sataniche o riti voodoo. Facciamoci un favore, rilassiamoci, me compreso.

Dulcis in fundo tu. Si ho sbagliato. Si abbiamo sbagliato. Si ogni tanto si fa. Si, dovevo prima contattarti e mandarti a quel paese come esordio, come fai di solito tu. Non l’ho fatto, amicizia finita? Se la mia amicizia con te è legata ad un filo cosi sottile, che basta un pollaio a distruggerlo, per una volta sono io a dire che non ho perso nulla. E continuerò a chiamarlo cosi, pollaio, perchè se una gallina solo per il gusto di usare il suo becco dice che le da fastidio il grassetto le cose sono due, o civilmente vi innalzate dal ruolo di galline scambiandovi insulti costruttivi via pm, o almeno ti innalzi solo tu dal livello gallina e per un breve periodo di tempo eviti il grassetto per diplomazia… penché scrivere proprio quel nome in grassetto è un chiaro, chiarissimo segnale diretto… non lo ha fatto di proposito, siamo noi a vederci il lato oscuro ed abbiamo sbagliato tutti a darti contro senza chiedere spiegazioni… per questo personalmente ti chiedo scusa… ma rifletti anche sotto altri punti di vista.

Per una volta, forse il lupo è stanco… si vuole riposare. Perché quando si combatte con la stupidità lo si fa con il sorriso e divertendosi un mondo… ma quando arrivi a combattere pure con gli amici è finita.

Vediamo di esaminarle una per una.

Sei di queste sono di tipo llDetected* applicabili esclusivamente in un contesto di tipo Touch e che accettano in ingresso il solito indice che tiene conto dei click multipli.

integer llDetectedTouchFace(integer index);
Restituisce il numero della faccia toccata.

vector llDetectedTouchPos(integer index);
Posizione del punto toccato in coordinate globali (regione).

vector llDetectedTouchST(integer index);
Posizione del punto toccato nella faccia in percentuale.

vector llDetectedTouchUV(integer index);
Posizione del punto toccato nella faccia in coordinate UV.

vector llDetectedTouchNormal(integer index);
Vettore normale alla superficie nel punto toccato.

vector llDetectedTouchBinormal(integer index);
Vettore tangente alla superficie nel punto toccato.

Una funzione riguarda le informazioni su un agent.

string llGetAgentLanguage(key agentKey);
Restituisce il codice della lingua dell’agent rappresentato dalla key.

Una funzione riguarda la regione.

integer llGetRegionAgentCount();
Restituisce il numero degli agent nella regione in cui gira lo script.

Se volete provarle tutte quante con un click, ecco un codice di esempio:

default {
    touch_start(integer total_number) {
        integer i;
        for(i=0;i<total_number;i++) {
            key agentKey = llDetectedKey(i);
            string agentName = llDetectedName(i);
            string agentLanguage = llGetAgentLanguage(agentKey);

            llOwnerSay("*** Informazioni Agent ***");
            llOwnerSay("Nome: "+agentName);
            llOwnerSay("Key: "+(string)agentKey);
            llOwnerSay("Lingua: "+agentLanguage);

            integer faceIndex = llDetectedTouchFace(i);
            vector posVec = llDetectedTouchPos(i);
            vector posSTVec = llDetectedTouchST(i);
            vector posUVVec = llDetectedTouchUV(i);
            vector normalVec = llDetectedTouchNormal(i);
            vector tangentVec = llDetectedTouchBinormal(i);

            llOwnerSay("*** Informazioni Tocco ***");
            llOwnerSay("Faccia: "+(string)faceIndex);
            llOwnerSay("Posizione toccata (Regione): "+(string)posVec);
            llOwnerSay("Posizione toccata (ST): "+(string)posSTVec);
            llOwnerSay("Posizione toccata (UV): "+(string)posUVVec);
            llOwnerSay("Vettore normale: "+(string)normalVec);
            llOwnerSay("Vettore tangente: "+(string)tangentVec);

        }
        integer agentInRegion = llGetRegionAgentCount();

        llOwnerSay("*** Informazioni Region ***");
        llOwnerSay("Numero agent: "+(string)agentInRegion);
    }
}

I Viewer abilitati alla compilazione Mono sono esclusivamente quelli con versione uguale o maggiore alla 1.21. Per il momento, l’unico viewer compatibile è il Preview Grid Viewer, quindi se fate girare Second Life tramite il Viewer Ufficiale o tramite il Release Candidate non sarete abilitati alla compilazione Mono.

La prima cosa da fare è quindi scaricare dal sito ufficiale la versione Preview Grid Viewer.

La Preview Grid Viewer di norma si connette alla Beta Grid di Second Life. Per accedere alla Main Grid dobbiamo forzare il Viewer. Facciamolo partire e prima di effettuare il login premiamo i tasti Ctrl-Shift-G. Ci appare, come mostrato nella seguente figura, un menù a tendina. Selezioniamo “agni” che sta ad indicare la Main Grid (di default è selezionato “aditi”, ovvero la Beta Grid). Fatto questo possiamo effettuare normalmente il login.

Una volta dentro Second Life dobbiamo assicurarci di essere in una Land con server compatibile con Mono. Dal menù “Help” selezioniamo “About Second Life…”, ci verrà visualizzata la seguente immagine.

Tra tutte le scritte presenti facciamo caso alla prima “Second Life 1.21.0 (94415)” che indica la versione del Viewer (che ricordo deve essere maggiore o uguale alla 1.21 per far compilare in Mono) e la scritta “Second Life Server 1.24.0.94778″ che indica la versione del server.

Per far girare e per far compilare gli script con Mono, il server deve avere la versione maggiore o uguale a 1.24. Server più vecchi non sono compatibili con Mono.

Cerchiamo quindi una Land con installata una versione del server compatibile con Mono (io sono andato a Sandbox Island). Notiamo subito che quando cambiamo versione del server il viewer ci avvisa con un messaggio:

Adesso non ci resta che creare un oggetto, aggiungere uno script e verificare che la spunta sulla casella Mono sia abilitata come mostrato in figura

Ed ecco che il nostro script è pronto!

Dopo aver testato il nostro oggetto, portiamolo in una land non compatibile con Mono (versione del server minore a 1.24)… noteremo che il nostro script non funziona più, e se proviamo ad aprire in modifica la casella Mono è disabilitata.

Concludendo, Mono risulta essere estremamente più veloce della vecchia macchina virtuale. I primi test che ho fatto dimostrano una velocità di esecuzione più che raddoppiata. L’unica pecca è una mancata segnalazione di script Mono non funzionanti in zone non compatibili (non viene visualizzato nessun errore nemmeno nella consolle di debug!)… ma è un problema da poco visto che il Viewer ufficiale sarà rilasciato esclusivamente dopo che tutte le sim saranno coperte dalla nuova macchina virtuale e che la copertura dovrebbe essere abbastanza rapita!

Enjoy with Mono!

Girovagando sulla rete mi sono imbattuto nella definizione di “Comportamento del gregge” che si contrappone alla parola “Branco”.

Citando da Wikipedia:

Comportamento del gregge è un termine usato per descrivere situazioni in cui un gruppo di individui reagisce coerentemente, senza che ci sia alcun coordinamento tra i singoli individui. Un tale gruppo viene chiamato gregge. Il termine viene usato unanimemente per descrivere il comportamento degli animali all’interno del gregge o dello stormo, e più controversamente per descrivere alcuni tipi di fenomeni umani quali le bolle speculative e il comportamento nelle dimostrazioni politiche.

applicando il comportamento del gregge alle società umane abbiamo…

La frase “comportamento del gregge” ha acquisito una certa popolarità nell’ambito della psicologia popolare, dove l’idea di un istinto del gregge viene offerta come spiegazione di fenomeni come le follie collettive, dove grandi numeri di persone agiscono allo steso modo nello stesso momento. Tali persone vengono talvolta etichettate con il termine dispregiativo di “pecoroni”.

Una follia è una moda eccessiva o una mania collettiva dovuta al comportamento del gregge. Alcune follie hanno conseguenze lievi (mode), ma altre portano agli eccessi dell’isteria collettiva. Gli psicologi popolari descrivono questo come qualcosa che coinvolge la scomparsa della personalità individuale, con una regressione a un qualche inferiore denominatore istintivo emotivo descritto come “sentimento della folla”. La prova che esista un qualsiasi reale processo psicologico di questa natura è, ad ogni modo, debole e in molti casi il termine “comportamento del gregge” è decisamente inappropriato per il fenomeno, in quanto il gruppo reagisce in base agli ordini o all’influenza di un capo carismatico (si veda carisma).

Esempi di fenomeni che sono stati descritti come coinvolgenti il comportamento del gregge includono le bolle speculative i crolli in borsa, la violenza di strada, la demonizzazione e la persecuzione delle minoranze, e lo zelotismo politico o religioso. In realtà questi comportamenti possono avere poco in comune oltre al fatto superficiale che tutti coinvolgono un certo numero di individui che fanno più o meno la stessa cosa, e l’estensione con la quale possono essere ragionevolmente descritti come “comportamenti del gregge” varia. Attribuire tali comportamenti collettivi a una “mentalità di branco” o a una “mente di gruppo” spiega poco e può facilmente distrarre l’attenzione dalla vera spiegazione per le azioni del gruppo. I seguenti esempi illustrano l’estensione dei fenomeni a cui in vari periodi è stata appiccicata l’etichetta di “comportamento del gregge”.

Possiamo quindi astrarre il concetto di “Pecoroni da Blog”.

Il Pecorone da Blog è quindi composto da svariati elementi folli, violenti, demoniaci, perseguitati e zeloti. Portando per eccesso il concetto, abbiamo visto, che l’insieme dei Pecoroni forma a sua volta un Branco!

Che dire… “Il Lupo si morde la coda”!

Quarta lezione di LSL sempre alla Land del Forum!

Argomento della lezione, questa volta, la comunicazione interna in un oggetto. Come già detto in passato, un oggetto in Second Life è formato da uno o più prim linkati tra di loro. L’ordine dell’operazione di link, effettuata selezionando tutti i prim e premento CTRL + L, imposta il numero del link. In particolare, l’ultimo link selezionato sarà il prim root, ovvero il prim con il numero di link uguale ad 1, tutti gli altri saranno i prim child, con il numero di link decrescente rispetto alla selezione (il penultimo linkato ha valore 2, il precedente 3, e cosi via).

Per scoprire il numero di link abbiamo creato un oggetto formato da tre prim:

• Un cubo come prim root;
• Due piramidi con le basi adiacenti a due facce opposte del cubo come child.

Per fare delle prove abbiamo applicato a questi tre prim il seguente script:

default {
	touch_start(integer total_number) {
		string agentName = llDetectedName(0);
		integer linkNumber = llGetLinkNumber();
		llSay(PUBLIC_CHANNEL, agentName+" ha toccato il prim con il link number uguale a "+(string)linkNumber);
	}
}

La funzione llGetLinkNumber() ci restituisce infatti il numero del link in cui sta girando lo script.

Effettuando la separazione dei link, ovvero premento CTRL + SHIFT + L, abbiamo ripetuto il test ed abbiamo notato che il numero di link è pari a 0.

Quindi siamo arrivati alla seguente conclusione: se un oggetto è formato da un unico prim, questo ha numero prim uguale a 0, mentre, se l’oggetto è formato da due o più prim, l’ultimo oggetto selezionato ha valore 1 ed è il prim root, tutti gli altri hanno valore maggiore di 1, in base alla selezione, e sono i prim child.

Detto questo abbiamo posto la nostra attenzione verso un’altra funzione di sistema: llMessageLinked, la cui firma è llMessageLinked(integer linknum, integer num, string str, key id).

Questa funzione viene utilizzata per fare comunicare i prim che formano un oggetto. Il primo parametro, infatti, indica il numero del link del prim destinatario del messaggio. Il primo parametro, oltre al numero secco del prim, accetta anche le seguenti costani:

• LINK_ROOT: per comunicare con il prim root (ovviamente, come abbiamo visto, questa costante assume valore 1);
• LINK_SET: per comunicare con tutti i prim che costituiscono l’oggetto;
• LINK_ALL_OTHERS: per comunicare con tutti i prim diversi da quello in cui sta girando lo script;
• LINK_ALL_CHILDRENS: per comunicare con tutti i prim child;
• LINK_THIS: per comunicare con lo stesso link in cui sta girando lo script.

I rimanenti tre paramentri della funzione llMessageLinked servono appunto per passare il messaggio. Possiamo passare contemporaneamente un intero, una stringa e una key rispettivamente nelle variabili num, str e id.

Il nostro obiettivo è creare tre script da inserire nei tre prim che costituiscono il nostro oggetto. Due script molto simili da applicare nelle piramidi per simulare delle frecce, ed uno script nel cubo (il prim root) che riceve i messaggi.

Il particolare, gli script delle piramidi devono essere sensibili al tocco di un agent e devono inviare al prim root il numero 1 o -1 in caso sia la freccia Indietro o Avanti, il nome dell’agent che ha toccato il prim e la key dello stesso.

Lo script per la freccia indietro risulta quindi essere il seguente:

default {
	state_entry() {
		llSetText("Indietro",<1.0,1.0,1.0>,1.0);
	}

	touch_start(integer total_number) {
		key agentKey = llDetectedKey(0);
		string agentName = llDetectedName(0);
		llMessageLinked(LINK_ROOT,-1,agentName,agentKey);
	}
}

mentre lo script per la freccia avanti è il seguente:

default {
	state_entry() {
		llSetText("Avanti",<1.0,1.0,1.0>,1.0);
	}

	touch_start(integer total_number) {
		key agentKey = llDetectedKey(0);
		string agentName = llDetectedName(0);
		llMessageLinked(LINK_ROOT,1,agentName,agentKey);
	}
}

Notate che la prima manda come intero il messaggio -1, mentre la seconda 1.

Lo script posizionato nel cubo, invece, non fa altro che leggere l’input del messaggio e visualizzarlo come testo.

Ogni volta che viene ricevuto un messaggio inviato tramite llMessageLinked, viene sollevato l’evento link_message(integer sender_num, integer num, string str, key id).

Se notate bene, i parametri di ingresso sono del tutto analoghi a llMessageLinked, fatta eccezione per il primo. Questa volta, infatti, il primo paramentro identifica il numero del link del prim mittente del messaggio. I restanti parametri contengono rispettivamente il numero, la stringa e la key inviata dal prim mittente.

Lo script risultante, da inserire nel prim cubo, risulta quindi essere:

default {
	state_entry() {
		llSetText("In attesa che qualcuno tocchi le freccie!",<1.0,1.0,1.0>,1.0);
	}

	link_message(integer sender_number, integer number, string message, key id) {
		llSetText("Il link numero "+(string)sender_number+" mi ha mandato il messaggio ("+(string)number+","+message+","+(string)id+")",<1.0,1.0,1.0>,1.0);
	}
}

Questo oggetto sarà molto utile la prossima lezione, dove lo utilizzeremo per spiegare le liste!

Alla prossima lezione!

Finalmente siamo vicini alla transazione verso Mono. Questa è prevista con la versione 1.21 del viewer.

Vediamo di capire nel dettaglio come funziona l’architettura di Second Life sotto il punto di vista degli Script, i motivi del cambiamento, cosa c’è attualmente, cosa cambierà.

Ogni volta che scriviamo uno script questo viene compilato in un linguaggio particolare, tecnicamente chiamato bytecode, che deve essere interpretato da una entità chiamata “Macchina Virtuale”. A questa spetta l’onere di eseguire lo script.

Il Server che si occupa dell’esecuzione del bytecode è sempre il server della regione in cui si trova attualmente lo script.
Quindi, nel caso di attachment scriptati, dopo un teleport o un passaggio tra due regioni adiacenti c’è un passaggio di consegna tra due server. Il primo impacchetta le informazioni e le passa al secondo che continua l’esecuzione.

Come già accennato, su ogni server è presente una Macchina Virtuale, il cui unico scopo è interpretare il bytecode ed eseguirlo.

In questo momento, l’unica macchina virtuale esistente è quella nativa della Linden. Questa è stata pensata per un basso numero di script in esecuzione e per script relativamente semplici.

Con l’evoluzione di Second Life, gli script sono diventati sempre più complessi, pesanti e quindi la macchina virtuale esistente risulta essere inadeguata. A complicare il tutto si è aggiunto il nuovo motore fisico, sicuramente più preciso e realistico del precedente, ma anche più pesante.

Il pensiero è quindi quello di cambiare totalmente lo strato della macchina virtuale. Sostituirla, quindi, con una più efficiente e dalle prestazioni maggiori. La scelta è ricaduta su Mono, attualmente disponibile nella versione Beta del client di Second Life (ovvero il client che fa girare Second Life sulla BETA Grid e non sulla Main Grid).

La difficoltà nel passaggio tra le due macchine virtuali sta, ovviamente, nella incompatibilità tra i due bytecode. L’obiettivo di Linden è quello di creare un compilatore capace di generare un bytecode compatibile sia con la vecchia versione sia con la versione mono.

Nel periodo di transizione sarà utilizzata la tecnica chiamata Het Grid. Ovvero una griglia capace di far girare alcune regioni sotto un simulatore (attualmente Havok 4) e altre regioni sotto Mono. Ad ogni teleport, verrà segnalato all’agent l’eventuale passaggio di simulatore.
A poco a poco verranno coperte tutte le regioni dalla macchina virtuale mono ed, appena il passaggio verrà ultimato, la vecchia macchina virtuale verrà definitivamente deprecata.

Secondo i primi benchmarck della Linden, la macchina virtuale Mono risulta essere ben 220 volte più veloce della vecchia macchina virtuale. Se questo fosse vero, diciamo che il lag sarà un lontano ricordo almeno per qualche mese (il tempo di sfruttare al massimo le nuove potenzialità).

Permettetemi una critica al numero 220… il test prestazionale è stato fatto sicuramente sulla Beta Grid, notoriamente meno affollata della Main Grid, quindi l’unico dubbio è vedere come si comporta sotto sforzo Mono.

Per provare i nostri vecchi script sotto la nuova macchina virtuale Mono, ci basta:

• Scaricare la versione BETA del client
• Teletrasportarci su una regione abilitata a Mono, Linden segnala le seguenti:
  - Sandbox Cordova MONO;
  - Sandbox Goguen MONO;
  - Sandbox Newcomb MONO;
  - Sandbox Wanderton MONO.
• Editare lo script ed abilitare la casella Mono e salvare, come già accennato, infatti, il vecchio bytecode NON è compatibile, quindi dobbiamo ricompilare tutti i nostri script affinché possano girare correttamente sotto Mono (se la casella è oscurata, vuol dire che non siamo in una regione compatibile con mono);
  - Attenzione che dopo aver compilato il codice sotto Mono, quegli script funzioneranno esclusivamente in regioni compatibili con questo!

Andiamo adesso nel dettaglio le differenze di Mono rispetto alla vecchia macchina virtuale LSL:

• La sintassi, gli stati, le funzioni, gli eventi del Linguaggio LSL sono le stesse nelle due macchine virtuali, quindi continueremo a scrivere gli script esattamente come abbiamo fatto fino ad adesso, quello che cambia è il compilatore (quindi il bytecode generato) e la macchina virtuale. In poche parole, il programmatore non si rende conto di nulla, visto che tutti i cambiamenti concentrati dopo il click al pulsante Save degli script;
• Maggiore velocità di esecuzione, Linden dichiara che la macchina virtuale Mono è fino a 220 volte più veloce della vecchia macchina virtuale;
• Maggiore memoria nei nostri script, fino a 64Kb rispetto ai vecchi 16Kb;
• Gestione dinamica della memoria, probabilmente verrà incrementata la potenza della funzione llGetFreeMemory che potrà restituire lo stato effettivo della memoria e non soltanto il picco;
• Tutti gli script compilati con il vecchio compilatore dovranno essere ricompilati sotto Mono (semplicemente aprendoli e cliccando su Save dopo aver selezionato la casella Mono, o utilizzando il Tool messo a disposizione del nuovo client per compilare contemporaneamente più tool). Di contro, gli script compilati sotto Mono non funzioneranno in regioni in cui gira la vecchia macchina virtuale e viceversa.
• I vecchi script continueranno a funzionare ancora per lungo tempo, la vecchia macchina virtuale verrà dismessa, alleggerendo l’architettura, solo dopo che Mono avrà coperto tutta la Main Grid;
• La macchina virtuale Mono è capace di interpretare e compilare codice proveniente anche da altri linguaggi come lisp, javascript, phyton. Ma,per il momento, non è prevista una espansione per linguaggi diversi dall’LSL.
• Il codice verrà compilato direttamente dai server Linden, non dal client come avviene adesso. Questo significa un alleggerimento dei client ed una maggiore sicurezza nel controllo del codice scritto (non sarà più possibile infatti inviare bytecode dal client).

Concludendo non posso che darvi un consiglio: per il momento ignorate Mono!
Sicuramente questo è più veloce e performante, ma ci vorrà del tempo affinché tutta la Main Grid sarà coperta dalla macchina virtuale Mono e quindi si corre il rischio di avere degli script che funzionano in pochissime regioni e non funzionano nella maggior parte.
Inoltre, le potenzialità di Mono non sono attualmente disponibili, il linguaggio è lo stesso e le librerie di sistema non sono ancora state adattate per sfruttare al massimo tutte le potenzialità offerte.

Quindi, meglio attendere un poco!

Maggiori informazioni si possono trovare nel wiki ufficiale della Linden.

Terza lezione di LSL alla Land del Forum!

Abbiamo continuato il discorso iniziato alla seconda lezione di LSL: la Comunicazione.

Ovvero come fa un oggetto ad ascoltare su di un canale ed a rispondere. Abbiamo creato due oggetti: il primo che ascolta su un canale, il secondo che appena toccato parla sullo stesso canale.

In questo modo abbiamo simulato la comunicazione tra i due oggetti. Il progetto consiste in due oggetti distinti, ognuno con il proprio script, che comunicano tra di loro.

Il primo script inizializza un listener tramite la chiamata a funzione llListen sul canale 1234567890. Al listen non vengono applicati filtri, quindi qualunque agent può interagire con esso.
Dentro l’evento listen è stata inserita una chiamata a funzione llSay su canale PUBLIC_CHANNEL (ovveo il canale 0), per avere un feedback del messaggio ascoltato.

integer CHANNEL = 1234567890;

default {
    state_entry() {
        key owner = llGetOwner();
        llSetText("Oggetto che riceve di "+llKey2Name(owner),<0.0,1.0,0.0>,1.0);
        llListen(CHANNEL,"",NULL_KEY,"");
    }

    listen(integer channel, string name, key id, string message) {
        llSay(PUBLIC_CHANNEL,name+" mi ha detto \""+message+"\" sul canale "+(string)channel);
    }

    changed(integer change) {
        if(change & CHANGED_OWNER) llResetScript();
    }
}

Il secondo script si occupa di attendere un click dal proprietario dell’oggetto per inviare nel canale prestabilito la stringa “NOME_AGENT mi ha toccato!”. In questo modo, questa stringa verrà intercettata dallo script del primo oggetto!

integer CHANNEL = 1234567890;

default {
	state_entry() {
		key owner = llGetOwner();
		llSetText("Oggetto che invia di "+llKey2Name(owner),<1.0,0.0,0.0>,1.0);
	}

	touch_start(integer total_number) {
		key agent = llDetectedKey(0);
		if(agent==llGetOwner()) {
			llOwnerSay("Invio messaggio '"+llKey2Name(agent)+" mi ha toccato!' sul canale "+(string)CHANNEL);
			llSay(CHANNEL, llKey2Name(agent)+" mi ha toccato!");
		}
		else {
			llInstantMessage(agent,"Non puoi toccare il mio oggetto!");
		}
	}

	changed(integer change) {
		if(change & CHANGED_OWNER) llResetScript();
	}
}

In tutti e due gli script è stata fatta un’aggiunta: l’evento changed. Questa è stata fatta per gestire un eventuale cambio di owner. In questo caso, infatti, l’intero script viene resettato per permettere la ridefinizione dei listener.

Possiamo provare il funzionamento del progetto in due modi:

• Cliccando sul secondo oggetto;
• Parlando sul canale (nel nostro caso ci basta scrivere nella chat “/1234567890 Prova!”).

Alla prossima lezione!