Oneshot

Fala, Ékstibiano. Vou dar uma olhada nesse seu segundo pedido, já o primeiro segue abaixo: local config = { time = 5 --[[tempo em segundos]] } function onSay(cid, words, param) return doSetItemOutfit(cid, 4390, config.time*1000) end

Estarei dando uma olhada para ver se consigo adicionar suporte a Conditions. rsrs

Fala, Galera! Eu estive desenvolvendo durante um tempo um sistema avançado de configuração de magias. De modo que você pode criar várias áreas, vários efeitos, vários danos, sem fazer um monte de variáveis de combate. Isso reduz o tamanho de magias em até 50%, falando em linhas de programação. O único conhecimento que você irá precisar é de edição de tabelas. Veja abaixo o template do Advanced Spell Config 0.6: local spellConfig = { {damage = COMBAT_FIREDAMAGE, effect = CONST_ME_FIREAREA, area = createCombatArea(AREA_CIRCLE3X3), formula = { base = "magic", --[[skill or magic]] value = {-1, -100, -2, -200} --[[valores]] } } } local combats = {} for k, config in ipairs(spellConfig) do combats[k] = createCombatObject() setCombatParam(combats[k], COMBAT_PARAM_TYPE, config.damage) setCombatParam(combats[k], COMBAT_PARAM_EFFECT, config.effect) setCombatArea(combats[k], config.area) setCombatFormula(combats[k], (config.formula.base == "magic" and COMBAT_FORMULA_LEVELMAGIC or COMBAT_FORMULA_SKILL), unpack(config.formula.value)) end function callCombat(p) return doCombat(unpack(p)) end function onCastSpell(cid, var) for i, combat in ipairs(combats) do addEvent(callCombat, (#combats == 1 and 0 or 250*i), {cid, combat, var}) end return LUA_NO_ERROR end Vocês podem estar pensando que eu só fiz complicar a vida de vocês, mas o código é grande apenas para uma variável de combate, imagine agora uma magia com 10 efeitos, 10 tipos de dano. Qual sairia melhor? Você só precisar adicionar suas configurações na tabela spellConfig que o código irá fazer tudo sozinho. local spellConfig = { {damage = COMBAT_FIREDAMAGE, effect = CONST_ME_FIREAREA, area = createCombatArea(AREA_CIRCLE3X3), formula = {-1, -100, -2, -200} }, {damage = COMBAT_ICEDAMAGE, effect = CONST_ME_ICEATTACK, area = createCombatArea(AREA_CIRCLE3X3), formula = {-1, -100, -2, -200} }, {damage = COMBAT_ENERGYDAMAGE, effect = CONST_ME_PURPLEENERGY, area = createCombatArea(AREA_CIRCLE3X3), formula = {-1, -100, -2, -200} } }

É uma idéia interessante que pode ser melhor aprimorada. O código está simples, creio que por ser algo simples mesmo.

A única maneira para isso é criar sua própria função que retorne valores de dano, e depois atribuir essa função a sua variável-ambiente. function onGetFormulaValues(cid) local min, max = 300, 400 return -min, -max end setCombatCallback(combat, CALLBACK_PARAM_SKILLVALUE, "onGetFormulaValues") No exemplo dado acima, a função que eu criei, retornaria valores de dano entre 300 e 400, claro que você pode editar para funcionar como uma fórmula. Como por exemplo local min, max = (level*3+maglevel*2)*1.5, (level*3+maglevel*2)*1.7

- Tópico criado em área incorreta. Reportado. Hmm, código adequado para seu nível de experiência, como você diz que é Iniciante. Mas acho que fica legal reduzir todo ele a isto: local vocations = { [1] = 5, [2] = 6, [3] = 7, [4] = 8 } function onSay(cid, words, param) return (doPlayerRemoveMoney(cid, 50000) and doPlayerSetVocation(cid, vocations[getPlayerVocation(cid)]) or doPlayerSendCancel(cid, "You don't have enough money")) end

Bem-vindos ao primeiro tutorial da série Scripting!, escolhi abordar um tema simples, mas que fará muita diferença nos próximos temas que irei abordar. Aprender a linguagem LUA é como aprender matemática. Sabe por quê? Na matemática, para resolver equações, você não precisa ter aprendido soma e subtração? No campo da LUA, para aprender (por exemplo) a construção do escopo do operador FOR, deverá primeiro, aprender o tema de hoje: Controladores Lógicos. Está preparado? Se sim, vamos lá! Para começar, galera, temos que pensar nas estruturas de controle lógico mais comuns no ramo da LUA, são as que trabalham com condições. Provavelmente quando você estava fazendo sua aula de inglês ou de português, seu professor falou algo parecido com isso abaixo: Veja que o Se ali remete a nossa condição (não chover) e ao que irá acontecer (não irei para a escola), por incrível que pareça, no campo da LUA, a coisa é exatamente a mesma, só que usamos o controlador IF. Vejamos abaixo como usar ele: if true then --[[bloco]] end O IF funciona desse jeito mostrado acima, se ele verifica que algo retorna verdadeiro, ele executa o escopo atribuído a ele. Seguem abaixo exemplos do que poderia ser verdadeiro. Para verificar se algo é verdadeiro, você precisa fazer uma relação entre algo declarado e o argumento, para o LUA não é diferente. Para fazer essas verificações, você deverá usar os operadores de relação. Você deve conhecer alguns desses operadores das suas aulas de matemática, são eles: São os operadores que vão retornar o true ou o false da estrutura de controle IF para que ela funcione. Agora veremos um código simples abaixo: local var = 3 if(var <= 4) then print("Legal") end O seu interpretador que, na maioria dos casos, será o executável do seu servidor, entende o bloco acima como algo mais ou menos assim: Certo, se você entendeu tudinho, deixe eu falar algo sábio: "Para tudo existe algo contrário." É com isso que apresento-lhe nosso segundo controlador lógico: ELSE. O ELSE é um controlador lógico que remete a "do contrário". Ele é usado juntamente com o IF, de modo que, podemos nos aproveitar do true e do false. Sendo assim, vamos voltar ao exemplo dado acima: Como já sabemos montar o escopo do IF, vamos prosseguir com o código. local var = 3 if(var <= 4) then print("Legal") else print("Chato") end Lembre-se! Que o ELSE não precisa do then, pois ele se aproveita da verificação do IF que ele é atribuído. Agora existe um último controlador que funciona como junção de ELSE e de IF e o nome não é nada criativo: ELSEIF. Ele foi criado mais com o objetivo de evitar as construções de escopos abaixo: if true then --[[bloco 1]] else if true then --[[bloco 2]] else if true then --[[bloco 3]] end end end Ele tem a função de permitir outra verificação ou outra efeito para a condição, de modo que: Se chover hoje não irei para a escola, mas se nevar irei fazer guerra de neve. De modo que o escopo com o uso do ELSEIF fica assim: if true then --[[bloco 1]] elseif true then --[[bloco 2]] elseif true then --[[bloco 3]] end Um exemplo básico para fixar o conteúdo passado acima é esse abaixo: local var = math.random(1, 3) if var == 1 then print("var tem valor 1") elseif var == 2 then print("var tem valor 2") elseif var == 3 then print("var tem valor 3") end Agora existem dois "operadores-controladores" que são usados para atribuir várias condições a um controlador lógico. São eles o AND e o OR, eles como o nome remete, tem significado lógico de "E" e "OU", respectivamente. Sendo assim, imagine a seguinte frase: Sim, creio que você entendeu. A estrutura montada fica mais ou menos assim: if true and true or true then --[[bloco]] Esse dois operadores fazem um papel grandioso no campo do LUA. Eles, igual ao ELSEIF, evitam construções de escopos do tipo: if true then if true then --[[bLOCO]] end elseif true then --[[bLOCO]] end Veja, é um mesmo bloco (escopo) executado se todas essas condições retornarem verdadeiro. O AND faz o papel daqueles dois IF e o OR faz o papel do ELSEIF. Concorda comigo que esses operadores reduzem o código em muito? O AND verifica todas as condições ligadas, se todas retornarem verdadeiro, ele executa o escopo. Se uma delas for falso, ele pula o escopo. Se houver presença do OR, ao invés do interpretador pular o escopo, ele verifica se a condição do OR é verdadeira. E assim acabamos a matéria do nosso primeiro tutorial. Será que vocês conseguem fazer o exercício de fixação? Com a variável passada acima, quero que vocês montem uma estrutura que faça tudo isso abaixo: O exercício está bem simples, se você ler o conteúdo, você conseguirá fazer. Abraços, galera!

A magia e o código estão muito simples. Você poderia dar uma complementada, adicionar multiplos efeitos ou hits, não?

Código simples e de caráter inutilitário. Como foi dito acima, os jogadores têm a total liberdade de reclamar do "lag", se o servidor o apresenta.

CENTRAL SCRIPTING O que é? Este será o tópico com todos os meus tutoriais que serão re-escritos pouco a pouco Você, XTibiano, terá a versatilidade de acessar apenas um tópico para ver todos os meus tutoriais e aprender um pouco desse tão complexo mundo da programação LUA. E não perca também a Coluna Scripting que estará saindo em breve, organizada por Apocarai e eu. Datas de Lançamento Os tutoriais não terão uma data de lançamento definida, pois como disse acima, estou escrevendo todos denovo, com o intuito de deixar-los mais interativos e bem-explicados. Todos os posts, reservados abaixo deste, são futuros espaços para meus tutoriais. Peço que membros não façam posts, pois preciso reservar os espaços para os tutoriais, um seguido do outro. Estado dos Tutoriais Próximo Tutorial - Controladores Lógicos Aguarde! Espaço Reservado

Como eu disse acima, um Colaborador que cuide apenas da seção referida é inviável, mas não deixa de ser uma boa idéia. Agora unindo a sua idéia de usuários com 100+ posts postarem tutoriais e uma pequena verificação dos Moderadores/Colaboradores nas respectivas áreas, acho que tudo dá certo. Um Abraço.

Uma coisa é certa, sem a seção de Aprovação de Tutoriais, vocês veriam membros postando scripts, mapas, como se fossem tutoriais. Tirando a seção Aprovação de Tutoriais, teríamos um monte de tópicos que não são tutoriais em seções indevidas, e os colaboradores e moderadores teriam que trabalhar da mesma forma, movendo tópicos, fechando tópicos, AVALIANDO... É claro, entramos em um ímpasse, é melhor deixar a seção e colocar alguém "pra trabalhar" ou tirar a seção e colocar alguém "pra trabalhar". Haha. Claro que se a seção continuar, serão necessárias algumas modificações nela, que tal deixar-la vísivel apenas para membros da equipe? E restringir os posts também. Pois do jeito que está, eu interpreto a seção não como Aprovação de Tutoriais, mas sim, Seção Massiva de Tutoriais. Um Abraço.

Creio eu que não, basta vocês selecionarem um moderador ou um colaborador que fique responsável por essa seção. É um jeito de um integrante da equipe mostrar serviços. Entendo que todos tem uma vida além do XTibia, mas pense comigo, se concentramos todos os esforços de um colaborador apenas para a seção Aprovação de Tutoriais, seria até uma boa idéia, creio que inviável, mas uma boa idéia.

É claro que a idéia pode ser muito melhor trabalhada. Ela pode ser um bom substituto para o sistema de reputação de que "nada vale", segundos os membros da comunidade. Poderiam ser várias reputações diferentes e existissem rankings dessas reputações como Intermediário, Avançado, Mestre, Lendário. Bom, isso é tudo. É apenas uma sugestão.

Estive pensando nisso faz um tempo. Que tal vocês adicionarem um pequeno sistema que mede a experiência do usuário com certas áreas do open Tibia? Seria mais ou menos assim, barrinhas, no perfil do Membro ou até abaixo do indicador de Reputação, para cada área (Exemplo: Scripting, Mapping) que indicassem níveis como Iniciante, Intermediário, Avançado. E houvesse em cada área do fórum, um sub-fórum de avaliação, onde o membro do XTibia postaria algo que ele fez para ser avaliado pela equipe (Colaboradores da área ou Moderadores). Quem frequenta fóruns de Design por aí, sabe do que estou tentando falar. São as chamadas "Rates". Bom, isso é tudo. Abraços.

É uma magia interessante, gostei de como você se utilizou da construção de efeitos e áreas. Mas, se você conseguir aprender a sintaxe do comando For, pode reduzir o tamanho do código em 50%. Obrigado por compartilhar conteúdo com a comunidade. Abraços.

Qual a utilidade?