Quarta Lezione di LSL

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!

Mozilla Firefox Download Day

Download Day 2008

Cito direttamente dal sito ufficiale:

Aiutateci a stabilire un Guinness dei Primati. Godetevi una fantastica esperienza sul web. Tutto ciò che dovete fare è scaricare Firefox 3 durante il Download Day, è semplicissimo! Non vi chiediamo niente di trascendentale, come inghiottire una spada o mettere in equilibrio 30 cucchiai sulla faccia, anche se sarebbe un bel record.

La data ufficiale del rilascio di Firefox 3 sarà il 17 Giugno, 2008. Unitevi alla nostra comunità aderendo già da oggi stesso a questo tentativo di record.

Uso Firefox da sempre… quindi ovviamente io ci sarò!

Allora, che cosa aspetti? Aderisci anche tu al Mozilla Firefox Download Day!

Attenzione: a causa della differenza dei fusi orari, il Download Day inizierà in Italia alle ore 19 di oggi 17 giugno, e finirà alle 19 di domani. Scaricate Firefox 3 all’interno di questo arco di tempo!
A questa pagina potete leggere l’orario di inizio in tutto il mondo.

Quinta Maratona Dr.Why

C’eravamo anche noi Sabato 7 Giugno al Kirby’s Garden per la V Maratona del Dr.Why: i PiGreco: Marco, Alessandra, Sara, Mario, Francesca, Fabio (in sostituzione di Daniela!), Daniele ed Ernesto!

La Squadra, fondata da Ernesto in una serata al Sotto Casa di Andrea con Marco ed Alessandra, si è difesa egregiamente nella sua prima Maratona arrivando dodicesimi in Finalissima su un totale di 98 squadre provenienti da tutta Italia!

In Particolare…

  • Classifica Finale: 12mo posto;
  • Classifica Maratoneti: 17mo posto;
  • Quarta manche: 18mo posto;
  • Terza manche: 21mo posto;
  • Seconda manche: 7mo posto;
  • Prima manche: 52mo posto.

In più vincitori di un premio sprint!!!

Al prossimo anno… per la VI Maratona… sempre più agguerriti!

Il Secondo Mondo cambia in Mono!

Mono

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.