Líderes

Após anos contribuindo pro desenvolver do DB.D, venho com muita dor no coração, disponibilizar para todos essa base(2018) que por anos fez a felicidade de muitos players e que com certeza trás nostalgia só de citar o nome. Infelizmente tem algumas pessoas usando o nome do Moz# e o meu (Abreu) e o nome D.UD em outros servidores, oportunismo e coisa de retardado (sinceramente). O servidor tem bastante gambiarras e coisas a ser arrumada, mas é um bom ponto de partida pra quem quer um bom servidor. Espero que façam bom proveito.

local chance_percent = 100 -- Chance percentual para headshot local extra_damage_percent = 1000 -- Percentual de dano extra function onLogin(cid) registerCreatureEvent(cid, "HeadshotCritical") return true end function onStatsChange(cid, attacker, type, combat, value) if type ~= STATSCHANGE_HEALTHLOSS then return true end if isPlayer(attacker) and getPlayerStorageValue(cid, 71257) < 1 then if math.random(100) <= chance_percent then local dmg = value * (extra_damage_percent / 100) setPlayerStorageValue(cid, 71257, 1) doTargetCombatHealth(attacker, cid, combat, -dmg, -dmg, 255) setPlayerStorageValue(cid, 71257, -1) -- Verifica se o dano causado é letal if getCreatureHealth(cid) <= dmg then doCreatureSay(cid, "HEADSHOT!", TALKTYPE_MONSTER) end return false end end return true end Como o script funciona: Chance de Headshot: O código mantém a chance de "headshot" e o dano adicional, como no script original. Verificação de Morte: Antes de exibir a mensagem "HEADSHOT!", o script verifica se o dano causado é suficiente para matar o alvo (getCreatureHealth(cid) <= dmg). Se for letal, a mensagem é exibida. Mensagem de "HEADSHOT!": A mensagem só aparecerá se o jogador morrer pelo ataque que causou o dano crítico. Como usar: Adicione o script ao seu servidor. Registre o evento no creaturescripts.xml: <event type="statschange" name="HeadshotCritical" script="headshot.lua"/> Reinicie o servidor para que as alterações entrem em vigor. Com essas alterações, o efeito "HEADSHOT!" só aparecerá quando um jogador matar outro jogador com um ataque crítico. Isso evita que a mensagem apareça a cada ataque, melhorando a experiência de jogo.

Olá pessoal, vi esse tutorial em um site gringo sobre a parte básica dos módulos de um otclient, que pode auxiliar muita gente que quiser explorar ainda mais o Otclient, já que essa área eu não vejo tanto conteúdo no Tibia Br, como sempre os créditos estarão ao final do tópico... Então, para começar as coisas que eu vou estar cobrindo: - a criação de módulos. - repassar alguns dos fundamentos para trabalhar no ambiente otclients lua. como testar eficientemente seus módulos e scripts. Para este tutorial você vai precisar: - Um editor de texto de algum tipo (eu gosto de usar o Notepad + +) também seria bom ter conhecimentos básicos de lua e habilidades de programação (mas isso é algo que você pode pegar rapidamente praticando). Agora que já temos tudo o que precisamos, podemos começar ! CRIANDO O NOVO MÓDULO Otclient front-end funciona fora o que chamamos de ' módulos '. Os módulos são uma forma de implementar eficazmente os recursos do cliente separados uns dos outros. Se você está considerando a criação de um novo módulo, é aconselhável que você pense sobre o que o recurso pode ser e se ele iria caber em um módulo já existente (provavelmente um módulo game_xxx), os módulos são encontrados no diretório/modules do otclient. Seus são atualmente dois módulo ' ambientes ': jogo e cliente. Os módulos de jogo usam o prefixo game_ e devem estar refletindo recursos que se relacionam especificamente com os recursos do ambiente do jogador ou do jogo por exemplo game_outfit ou game_mounts são ambos os recursos que são usados no ambiente de jogo. Os módulos de cliente usam o prefixo client_ e devem estar refletindo recursos que se relacionam especificamente com o cliente e o cliente somente. Ele não tem nada a ver com o ambiente de jogo de jogadores, por exemplo, client_options e client_skins estão diretamente relacionados com a funcionalidade de clientes. Isso pode ser um pouco difícil de Visualizar para agora, mas você vai pegar isso mais tarde. Então, agora que você tem uma compreensão do que é um módulo e um pouco como eles funcionam, vamos em frente e começar a criar um novo. COMEÇANDO DO ZERO Nós estamos indo para criar um novo módulo a partir do zero, a primeira coisa que você precisa fazer é criar o diretório modules. O nome do diretório deve refletir o recurso global em si, por isso vamos chamar o nosso game_spells para começar a criar um novo módulo que irá listar todos os players spells com suas informações apropriadas. Nós não estaremos criando este módulo inteiro, mas podemos começar a ver como tudo funciona. Crie um novo diretório chamado game_spells dentro do diretório/Modules clientes. Dentro de game_spells precisamos começar adicionando 3 novos arquivos base: Spells. lua, feitiços. otmod e Spells. otui para a lógica de módulos, registro e design de interface. Criar 3 novos arquivos base spells.lua, spells.otmod e spells.otui dentro/modules/game_spells Você já deve saber o que o arquivo. lua representa, mas quais são essas novas extensões. otmod e. otui? .otmod .otmod é o arquivo que é usado para inicializar o módulo dentro do otclient, é como um registro em que ele irá registrar o módulo para uso dentro do cliente. Este arquivo geralmente tem uma estrutura como esta (eu adicionei comentários, se você copiar este código não se esqueça de remover o--comments): Module nome: game_spells -- nome do módulo (geralmente o mesmo nome que o diretório modules. descrição: Exibir a player spell com sua informação apropriada--descrição do módulo que explica o que é. autor: Sammy -- nomes dos criadores e colaboradores do módulo. website: www.otclient.info -- Se você tem um site externo que você pode ligá-lo aqui. sandboxed: true--sandbox é uma maneira de conter a variável modules e funções para que você não tenha conflitos entre outros módulos. scripts: [ spells.lua ] -- Os scripts são a lógica por trás do módulo onde todas as funções estão contidas. @onLoad: init() -- Este é o lugar onde você define a função de inicialização do módulo (nós vamos cobrir isso mais tarde). @onUnload: terminate() -- Este é o lugar onde você define a função de término do módulo (vamos cobrir isso mais tarde) Copie o código .otmod acima em seu arquivo spells.otmod e remova os comentários. .otui .otui é o arquivo que é usado para criar a interface de usuário modules. Esta é uma linguagem de estilo feito encomenda projetado especificamente para otclient chamado OTML, ele se sente muito como a formatação CSS para aqueles de vocês que têm experiência em webdesign. A estrutura típica de um arquivo .otui se parece com isso (este é o arquivo base iniciar, não concluído): MainWindow !text: tr('Spells') size: 160 450 @onEnter: modules.game_spells.destroy() @onEscape: modules.game_spells.destroy() Label id: spellsLabel !text: tr('Player Spells') width: 130 anchors.top: prev.top anchors.left: prev.left margin-top: 5 margin-left: 5 MainWindow: Esta é a janela que estaremos usando para a interface da Spell List, é uma classe de janela padrão derivado de/client_skins/default/styles/windows.otui styling file estende janela que estende UIWindow. UIWindow é uma classe base dessa inicialização, ele controla a funcionalidade widgets e comportamentos. !text: Este é o texto que é exibido na seção de cabeçalho MainWindow size: isso é usado para definir a largura/altura da mainwindow. @onEnter: configura o retorno de chamada de widgets de MainWindow OnEnter (função que será chamada quando você pressiona a tecla Enter). @onEscape: configura os widgets de retorno de chamada de MainWindow (função que será chamado quando você pressiona a tecla de escape). Label: Este é um widget de etiquetas que é usado para exibir texto na maioria dos casos. É um derivado da classe UILabel. id: Este é o ID que esta mais comum será alias-se com para referenciar usando funções como widget: getChildById ( "spellsLabel ") !text: Este é o texto que será exibido pelo widget UILabel. width: Este é o tamanho da largura do Label anchors. top/bottom/left/right: São onde a parte superior/inferior/esquerda/direita do Label devem ser posicionada. margin-top/bottom/left/right: São deslocamentos para as anchors, eles permitirão que você afinar o posicionamento dos componentes da interface do usuário. Esta é apenas a superfície de .otui formatação e styling, há muito mais que pode ser feito, mas a ideia principal é que você obter uma compreensão sobre como a hierarquia dos componentes da interface do usuário para exibir corretamente, etc as convenções de styling OTML forçá-lo a manter o projeto de um interface separado para o código lógico, por exemplo, o .lua Copie o código otui acima e coloque em spells.otui Agora que entendemos qual arquivo é usado para registrar o módulo e que arquivo (s) são usados para construir os módulos da interface do usuário, podemos aprofundar o código de lógica de módulos e tentar entender como tudo funciona em conjunto. O arquivo spells.lua é o arquivo que contém o código de lógica de módulos. É aqui que os spells serão preenchidos e o manuseio da seleção ortográfica e do display ortográfico serão controlados. Abra o arquivo spells.lua e copie o seguinte código base para começar. Nós estaremos escolhendo aparte este código para ajudar a entendê-lo melhor. Eu fui em frente e comecei o código base para você, aqui está: Spells = {} spellWindow = nil selectedSpell = nil spells = {} function init() connect(g_game, { onOpenSpellWindow = Spells.create, onGameEnd = Spells.destroy }) end function terminate() disconnect(g_game, { onOpenSpellWindow = Spells.create, onGameEnd = Spells.destroy }) Spells.destroy() Spells = nil end function Spells.create(spellList) spells = spellList Spells.destroy() spellWindow = g_ui.displayUI('spells.otui') end function Spells.destroy() if spellWindow then spellWindow:destroy() spellWindow = nil selectedSpell = nil spells = {} end end function Spells.selectSpell() if table.empty(spells) then return end -- TODO end As principais coisas que eu quero focar aqui são: as variáveis (spellWindow, selectedSpell e spells). e as funções (armazenamento de funções e discutir o que init e Terminate são necessários). O VARIÁVEL Variáveis dentro de um módulo em modo seguro não precisam ser localizadas com a palavra-chave local como elas estão dentro de seu próprio ambiente de módulo. Se o módulo estiver em modo seguro: false, então você precisará certificar-se de que você localize a variável e redefini-los dentro da função Terminate (que vamos discutir mais tarde). Dentro deste módulo de feitiço precisamos ter uma maneira de armazenar o objeto janela módulos, fazemos isso definindo a variável spellWindow que temos inicializado como nulo, mas que vamos configurar em breve. Nós também precisamos de uma maneira de conter o que o jogador selecionou o que significa que devemos armazenar uma referência para o spell de alguma forma usando a variável selectedSpell. Por último, mas não menos importante e provavelmente não duram tanto! Precisamos armazenar a lista de spells e fazer isso com a variável Spells. AS FUNÇÕES Funções muito como variáveis estão contidas em módulos de área restrita para que a localização pode variar dependendo de suas preferências. Se você não estiver usando um module sandboxed: true, em seguida, você precisará certificar-se de que você está localizando e armazenar funções corretamente. Eu pessoalmente gosto de usar uma tabela para armazenar minhas funções dentro para manter as coisas organizadas mais este é o lugar onde você vê spells = {}. Spells é uma tabela que eu estarei usando para armazenar todas as funções públicas de um módulo. Funções de módulo privado serão localizadas mesmo que não seja inteiramente necessário dentro de um módulo em modo seguro, eu prefiro declarar quando a função é privada através da palavra-chave local. Então, quais são as funções init () e Terminate () usado para? Como você já deve ter notado dentro dos feitiços .otmod código que você vai ver: @onLoad: init() @onUnLoad: terminate() init() A função init é uma função que é chamada quando otclient tenta carregar o módulo registrado usando chamada de sinal OnLoad. Dentro desta função você deve estar inicializando todos os componentes que são exigidos pelo seu módulo. Como você pode ver dentro de spells.lua estamos chamando uma função dentro de init (): connect(g_game, { onOpenSpellWindow = Spells.create, onGameEnd = Spells.destroy }) terminate() A função Terminate é uma função que é chamada quando otclient tenta descarregar o módulo registrado usando a chamada de sinal OnUnload. Dentro desta função você deve estar destruindo e redefinir variáveis que precisam ser desmarcadas na terminação do módulo. Lembre-se de que nem todas as variáveis precisarão ser redefinidas, mas as referências de widget e a tabela de spells são todas necessárias para serem redefinidas. Como você pode ver dentro de feitiços. lua estamos chamando e definindo uma série de coisas dentro de terminate(): disconnect(g_game, { onOpenSpellWindow = Spells.create, onGameEnd = Spells.destroy }) Spells.destroy() Spells = nil Afirmei anteriormente que chamamos a função Connect dentro init (). Agora que estamos encerrando o módulo precisamos desconectar os retornos de chamada do conjunto de chamadas de sinal. Isto é feito através da função de desconexão (...). Com estas principais coisas cobertas você pode muito bem fazer o que você gosta dentro do módulo. Você pode com cuidado construir e craft o para inserir o que você precisa. Siga através do tutorial para estender o seu conhecimento de criação de módulos e também trabalhar dentro do ambiente do módulo otclients. COMO TESTAR EFICAZMENTE OS SEUS MÓDULOS Testar seus módulos será uma parte importante de fazê-los trabalhar da maneira que você precisa. Módulos de teste pode, por vezes, ser um pouco de um desafio para que haja algumas coisas que você precisa saber, a fim de torná-lo mais fácil para você. RECARREGANDO OS SEUS MÓDULOS Você pode recarregar seus módulos no cliente usando o Gerenciador módulo módulo Gerenciador módulo selecione seu módulo e clique em recarregar. Esteja ciente de que o seu init () e terminate (), funções serão chamados em recarregar por isso, se você não está inicializando e destruindo coisas particulares corretamente, então você pode obter erros no recarregamento. Nota importante: existem algumas alterações raras que podem não ser recarregadas corretamente com o gestor de módulos, coisas como .otui @ alterações (por exemplo, @onClick: edits). Pode haver algumas outras mudanças que não recarregam corretamente, mas para a maior parte ele funciona bem. Se você se encontrar com erros estranhos tentou fazer um reinício completo do cliente para garantir a sua não uma emissão de recarga. COMANDOS DE TESTE ÚTEIS Há uma seleção de comandos úteis que podem ser úteis para testes encontrados no arquivo de script/modules/client_terminal/Commands.lua. Aqui está uma lista dos comandos atuais que você pode inserir no terminal do cliente: dumpWidgets(widget, level) drawDebugBoxes(enable) hideMap() showMap() debugContainersItems() debugPosition(enable) autoReloadModule(name) Você pode adicionar novos comandos ao seu diretório/mod, a fim de evitar fazer alterações no arquivo de comando modules. Você deve sempre assegurar-se de que seus módulos estejam testados completamente antes de criar solicitações da tração ao repositório principal do git. Estas dicas podem ser muito úteis nas fases de teste! ALGUMAS ORIENTAÇÕES ÚTEIS Ao desenvolver seu módulo seja certo dar-lhe lotes do pensamento sobre como está indo trabalhar e mesmo se você pode fundir a característica a um módulo já existente. Também funções globais e variáveis constantes podem ser encontradas nos diretórios modules/corelib e modules/gamelib. Por favor, dê uma cuidadosa consideração para o que você colocar nesses arquivos e se possível tentar evitá-lo. Siga a regra "manter tudo para sua própria causa, e apenas essa causa ". FIM DO TÓPICO =] CRÉDITOS: edubart BeniS Eu(pela tradução e adaptação para o português)