Utilizzare editor esterni per LSL

Second Life è dotato di uno script editor interno che ci consente di creare e modificare gli script che utilizziamo (posto che questi siano stati scritti da noi o che siano comunque settati come ‘modificabili’).
Questo editor è sicuramente molto comodo ma, man mano che ci si dedica a script più complessi mostra tutti i suoi limiti, ragion per cui la Linden Lab ha introdotto tempo addietro la possibilità di potersi anche avvalere di editor esterni installati in locale sul proprio computer.

In effetti a ben vedere l’editor integrato non regge il confronto con gli editor attualmente a disposizione degli utenti e di fatto non offre nessuna funzionalità particolare, da ciò consegue che risulti eccessivamente povero e spartano quando ci si deve occupare di script lungi e complessi.
A questo si aggiunge il fatto che l’editor ‘gira’ dentro al client, per cui se ci troviamo in condizioni di lag elevato anche la reattività dell’editor ne risente in maniera diretta (mostrando ad esempio una ben percettibile latenza nel seguire quanto digitiamo da tastiera).

Usare un editor esterno ci permette di affrancarci da questo tipo di problemi, anche se sulla breve distanza non pare essere una scelta così conveniente, alla lunga ripaga di molto i piccoli disagi che essa comporta (un click aggiuntivo all’inizio).

I vantaggi che porta con sè invece un simile approccio sono molteplici e significativi; non solo potremo scegliere il tool di sviluppo che preferiamo o che già sappiamo utilizzare con dimestichezza, ma la sua efficienza non sarà più legata allo stato della sim in cui ci troviamo e le decine di funzionalità che qualsiasi editor moderno offre ci permetteranno di lavorare molto più speditamente sia in fase di stesura che sopratutto in fase di debugging.


Come impostare un editor esterno
Prima di poter utilizzare un editor esterno però dobbiamo informare il nostro client di quale editor intendiamo avvalerci, infatti tale impostazione non dipende dall’account ma  da uno specifico parametro presente in ogni singolo client, tale parametro è raggiungibile via “Advanced > Show Debug Settings” e una volta apertasi la finestra dovremo localizzare la variabile “External Editor”  (che di default è vuota)  e associare ad essa il path attraverso il quale raggiungere l’eseguibile, più eventuali parametri necessari e/o richiesti.

 

post_lslecitor01

 

Le “Best Pratice” (le “buone abitudini”) suggerite dalla wiki ufficiale ( LSL Alternate Editors  ) indicano di racchiudere il path a tra doppi apici (es  “path/nome_editor.exe” ) in modo questi possa essere facilmente interpretato senza errori anche nel caso che siano presenti spazi all’interno della stringa. Inoltre come ultimo parametro è necessario inserire un “%s” per assicurarsi di passare all’editor il sorgente correntemente aperto.

 

post_lsleditor02

 

Una volta inserito il path corretto il nostro client ricorderà tale impostazione automaticamente anche ai successivi riavvi, sino a quando non verrà cambiato o modificato dall’utente.


Quale editor utilizzare?
Non esiste una vera e propria lista di editor consentiti, nella wiki ufficiale di Second Life alla già citata pagina “LSL Alternate Editors” ne sono indicati molti, ma l’elenco è potenzialmente infinito. Nulla ci vieta infatti di utilizzare il buon vecchio notepad.exe di Windows o gedit in Linux, o il nostro wordprocessor preferito. Va da sè però che questi programmi semplicemente non sono stati realizzati per scrivere codice e potrebbero risultare persino più scomodi o più pesanti (in termini di memoria impiegata) per il nostro computer.

La scelta quindi dovrebbe ricadere su software sviluppati espressamente per scrivere codice e tra questi, a meno di non essere particolarmente ‘affezionati’ a questo o a quell’ambiente di sviluppo, andrebbero privilegiate le soluzioni meno impegnative (anche se so per certo che ci sono persone che utilizzano Eclipse o Adobe Dreamweaver per i loro progetti LSL).

Personalmente mi trovo bene con programmi “standalone” piuttosto che dover lanciare interi framework se devo scrivere qualche script in LSL, sono più veloci ad aprirsi e consumano meno memoria (e capiterà sempre di dover aprire una, due, dieci volte uno script  appena compilato per ricorreggere o aggiungere qualche dettaglio).

Un’altra caratteristica estremamente importante, anzi essenziale, è la possibilità di istruire l’editor esterno della sintassi LSL. Il Linden Script Language infatti non è così diffuso tra i programmatori (anche perchè viene usato solo per Second Life) e quindi molto difficilmente troveremo editor già in grado di gestire questo linguaggio nativamente.
Per fortuna la maggior parte degli editor moderni consente di introdurre nuove sintassi di linguaggi non presenti nella dotazione standard e sempre per fortuna (nostra) in alcuni casi c’è già chi ha realizzato dei file di configurazione per LSL, di solito sono dei file XML,  da aggiungere all’editor per renderlo edotto delle specifiche di LSL (parole chiave, funzioni native, tipi di variabili, sintassi, ecc…).

Quest’ultima caratteristica in effetti riduce il range di editor appetibili per i nostri scopi, ma le scelte che ci rimangono sono comunque molte e di alto livello (in fondo all’articolo ne elencheremo alcuni esempi in base alle differenti caratteristiche).


Scriptare usando l’editor esterno
Passare dall’editor del client a quello settato come editor esterno è quasi immediato, non dobbiamo far altro che premere il pulsante “Edit” presente nella finestra dell’editor IW e automaticamente, se abbiamo impostato tutto correttamente, verrà aperto il nostro programma con il codice su cui stiamo lavorando precaricato all’interno di esso.

post_lsleditor03

Se questo non accade dovremo riesaminare i passi eseguiti per vedere cosa è andato storto, ma fortunatamente il client ci darò qualche indicazione su dove focalizzare la nostra attenzione.

post_lsleditor04 post_lsleditor05

Una volta scritte le nostre modifiche per passare il codice al client la procedura è estremamente semplice.
Quando abbiamo caricato il sorgente esso infatti è stato passato con un nomefile del tipo uuid.lsl,  basterà quindi semplicemente eseguire un “Save as” / “Salva con nome”  e di fatto trasferirà il codice dall’editor esterno a quello interno e automaticamente compilato.

Due piccole accortezze però ci permetteranno di lavorare con maggior tranquillità e compatibilità.

  • Le tabulazioni in SL sono gestite di default come una sequenza di 4 spazi e non come /tab per cui assicurarsi che tale impostazione sia presente anche nell’editor ci aiuterà ad avere un codice ‘visivamente’ più simile tra loro nei due tool (interno ed esterno) e anche più pulito rispetto ad una commistione di indentazioni compose un pò da space un pò da /tab, anche se questo ‘mix’  non pregiudica la validazione del codice.
  • I sorgenti in Second Life, un tempo erano codificati in ANSI, attualmente invece utilizzano UTF-8, per cui, per non rischiare che ci siano incompatibilità o fraintendimenti tra quello che scriviamo e quello che verrà poi letto dal ‘compilatore’ è buona norma settare anche nell’editor esterno tale codifica.

Esempi pratici di configurazione di editor esterni

 

Posted in LSL and tagged , .

Leave a Reply

Your email address will not be published.