Ae gente, com as ultimas mudanças que foram pushadas hoje no repositório, o sistema de scripts da ugdk tá pronto. 
Ok vai, talvez não exatamente pronto, é capaz que no futuro alteremos algo, ou arrumemos algum bug, mas já tá usável já. hehehe
E também já testamos ele no Windows e funciona (algo que demoramos pra fazer), só falta testar no Mac.
Agora o propósito mor desse tópico não é falar exatamente do Sistema de Script (tem muita coisa pra falar ai, provavelmente eu e o Wil faremos isso depois)…
O propósito aqui é falar dos “módulos” da UGDK, que para os desavisados, são (aproximadamente) os namespaces de C++ contidos na UGDK, exportados (pelo SWIG, parte do sistema) para as linguagens de script que estão implementadas no sistema (por enquanto Lua e Python).
Os módulos são definidos nos arquivos <>.i na pasta src/modules. Eles são basicamente headers de C/C++ com algumas macros a mais do SWIG.
O importante aqui é que eles incluem os headers da UGDK (por exemplo, graphic.i inclui os headers de src/ugdk/graphic), afinal de contas eles exportam as coisas de C++ da UGDK para os scripts, eles tem que conhecer as coisas né 
Então, como você já deve ter pensado agora, QUALQUER MUDANÇA NA UGDK PODE ACARRETAR MUDANÇAS NOS MÓDULOS. Fazer os módulos em suma é fácil, mas ficar revendo toda vez que tem algum commit na UGDK as mudanças que tem pra atualizar os módulos é muito chato, então sem mais delongas: o propósito desse tópico é exatamente falar disso, para que quem mexa na UGDK possa atualizar os módulos por si próprio ou ao menos AVISAR (somehow, talvez até aqui) o que mudaram para que alguém atualize os módulos.
Agora, não é exatamente “qualquer mudança” na UGDK… Mais precisamente, aqui vai a lista das coisas que, se feitas, implicam ter que atualizar os módulos (ou criar novos):
[ul][li]Alterações nos Headers: [list]
[li]Novos headers -> novos módulos ou adicionar os novos headers no módulo existente adequado.[/li]
[li]Novas classes ou outros tipos -> setar ela pra ser export_class no módulo (exceto se for class template), e lembrem-se: nada de nested struct/union.[/li]
[/list][/li]
[li]Alterações na Interface (novos métodos, alterando método existente, e tal): [list]
[li]Se método retornar um objeto novo (sempre ou com possibilidade de ser null), de forma que ele passa a “ownership” do objeto pra quem lhe chamou, tem que setar o método como %newobject[/li]
[li]Se método rouba a ownership de algum objeto que ele recebe como argumento, IN CONSTRUCTION LOL[/li]
[li]Se nome (classe/método) é para ser ignorado (não exportá-lo), usar a macro %ignore (isso pode ser usado para não exportar coisas especificas, como métodos que recebem tipos que não são exportados para a linguagem de script)[/li]
[li]Se nome (classe/método) conflita com outro (por exemplo, overload… SWIG não gosta de nomes conflitantes), %rename pode ser usado para renomear um dos nome em conflito para outro nome durante a exportação.[/li]
[li]Coisas que recebem especializações de templates: como o SWIG não exporta templates, as vezes é necessário que você especialize o template no módulo como um novo tipo usando a macro %template[/li]
[li]Usando coisas da STD (std::map, std::string, e outras): SWIG tem arquivos <>.i “libs” para cuidar da exportação de tipos assim. Se coisas da STD passam a ser usadas, você terá que usar %include <> (onde <> são nomes como “std_string.i”, “std_map.i”, etc)[/li]
[li]Usando coisas de outras partes da UGDK: use %import para importá-las para o módulo em questão. Dê preferência a importar headers (melhor ainda se for headers de forward declaration, como o ugdk/graphic.h) passando a opção ‘module’ especificando o nome do módulo em que o tipo se encontra, se o tipo que você busca foi exportado em outro módulo.[/li]
[/list][/li][/ul]
Eu sei que essa é uma descrição bem “simples” para algo que não é, mas é mais para dar a visão geral para vocês.
Todas essas coisas que falei já são usadas de uma forma ou de outra nos módulos existentes na UGDK agora, então são bons exemplos. Eles também foram todos feitos seguindo um mesmo padrão, note isso
E nos arquivos <>.i, A ORDEM DAS COISAS FAZ DIFERENÇA! Por exemplo, se uma classe que você está exportando usa um tipo que foi exportado em outro módulo, você tem que dar o %import do outro módulo ANTES de incluir essa classe. Assim como %rename, %ignore, %newobject devem ser feitos antes das coisas em questão.
De qualquer jeito, eu e o Wil estamos sempre por ai para esclarecer outras dúvidas.
And that’s all folks! (i think :P)