Skyen

Não dá ideia, por favor!

function decrypt(message, exp, map) local inv = 1.0 / exp -- because f*ck root calculation local str = "" local byte = 0 for i = 1, #message do byte = byte * 256 -- lazy lshift8 if type(message) == "table" then byte = byte + message[i] else byte = byte + tostring(message):byte(i) end local char = map[byte ^ inv] if char then str = str .. char byte = 0 end end return str end local map = {} -- map values between '0' and '9' for i = string.byte("0"), string.byte("9") do map[i] = string.char(i) end -- map values between 'A' and 'Z', and 'a' and 'z' for i = string.byte("A"), string.byte("Z") do map[i] = string.char(i) map[i + 32] = string.char(i + 32) end local encrypted = {39, 16, 36, 193, 45, 144, 54, 100, 48, 33} print(decrypt(encrypted, 2, map))

Nope. str = str .. char E isso não é gambiarra. Em linguagens de baixo/médio nível (C, C++, et cetera) o algoritmo é praticamente igual o seu. Essa solução também é mais eficiente do que a usada no open tibia. Você poderia deixar ela um pouco mais rápida gravando o caractere em uma string temporária e depois inserir essa string na tabela quando o separador ou o fim da string original fosse encontrado.

E como foi dito o poger e associado a quantidade de linhas. Mais nunca disse que a quantidade de linhas tem relação com a qualidade do script. Do mais. Eu não vejo as gambiarras como monstro. Desculpe, eu interpretei mal. Realmente, as "gambiarras" geralmente ocupam mais linhas do que uma solução que seria naturalmente mais simples. E quanto à ser um monstro, É o que eu falei: É um mal necessário. Se existe uma solução mais simples e limpa, por que fazer de forma absurda? Para ganhar a alcunha de "rei do pog"? Para obscurecer o código? Usando uma analogia bem ridícula: se você pode colocar o quadro na parede com um prego, por que usar durepoxy? Existem casos onde gambiarras são sim necessárias. Talvez porque não exista outra solução pro problema. Ou talvez seja um mÉtodo mais rápido de executar determinada rotina. Para estes casos eu concordo com você, mas o programador tem que ter certeza absoluta de que a solução É segura, eficiente, e a melhor possível para o problema. Para isso você precisa saber com o que está lidando, conhecer muito bem suas ferramentas (bibliotecas e linguagem), e mesmo assim deixar um comentário explicando como a magia negra funciona e por que ela foi necessária. Todo mundo faz gambiarra um dia, apenas tenha certeza de que está fazendo a coisa certa, e não fazendo só por graça. O trabalho dos programadores não É apenas encontrar soluções, mas sim encontrar as melhores soluções. O motivo do meu pânico em relação ao assunto É que muitos programadores incentivam os iniciantes a fazer gambiarra como se fosse normal, e isso continua com a pessoa por muito tempo, atÉ que ela atinja maturidade suficiente pra diferenciar uma solução boa de uma solução ruim. Me chame de egoísta se quiser, mas eu não quero mais ver novatos fazendo magia negra sem nem se dar o trabalho de procurar uma solução mais simples. São essas pessoas que fazem códigos com 9 loops aninhados e dificílimos de entender. Outra coisa: do jeito que eu falei talvez tenha parecido que eu estou depreciando seu trabalho. Se você entendeu isso, você tem minhas sinceras desculpas, não foi minha intenção. Eu apenas não quero que quem está começando a programar leia o tópico e seja encorajado a fazer gambiarra em todo lugar do código. Programação não É isso. Um bom programador faz um código limpo, legível e rápido, e gambiarra É justamente o contrário desses três adjetivos. Para provar que eu tambÉm faço absurdos e não estou só falando da boca pra fora, aqui está uma gambiarra que eu fiz não faz muito tempo: module("space", package.seeall) _T = "space" local __type__ = type function _G.type(value) if __type__(value) == "table" and value._T then return value._T end return __type__(value) end Mais como foi dito. Você "pelo que parece" e muito organizado; Na verdade não tenho organização nenhuma e isto e realmente um problema. Tanto que já perdi muita coisa por falta de organização. Depende muito do programador. [i]Tudo depende da pessoa. Se a pessoa gostar do que faz não há nada que impeça usar gambiarras.[/i] [i]Um programador acima de tudo deve gostar do que ele faz.[/i] O problema é que vocês não estão programando só para vocês mesmos. Principalmente se você for postar seus códigos, outras pessoas vão ler ele, e até mesmo tentar aprender programação lendo seus códigos. Se ninguém mais for ler, provavelmente outras pessoas vão querer se beneficiar do que o script oferece (jogando seu servidor que tem aquele script, por exemplo). Programação não é algo de uma pessoa só, você sempre faz para outra pessoa (E na verdade, todas as profissões são assim). Mesmo que ninguém mais vá ler seu código, você ainda precisa achar a melhor solução para o problema. Se você acha que está fazendo um script só para o seu servidor, você ainda precisa deixar ele rápido, e é ai que aquela gambiarra faz a diferença. É essa diferença que vai fazer seu servidor ser melhor que o do outro.

E como foi dito o poger e associado a quantidade de linhas. Mais nunca disse que a quantidade de linhas tem relação com a qualidade do script. Do mais. Eu não vejo as gambiarras como monstro. Desculpe, eu interpretei mal. Realmente, as "gambiarras" geralmente ocupam mais linhas do que uma solução que seria naturalmente mais simples. E quanto à ser um monstro, é o que eu falei: é um mal necessário. Se existe uma solução mais simples e limpa, por que fazer de forma absurda? Para ganhar a alcunha de "rei do pog"? Para obscurecer o código? Usando uma analogia bem ridícula: se você pode colocar o quadro na parede com um prego, por que usar durepoxy? Existem casos onde gambiarras são sim necessárias. Talvez porque não exista outra solução pro problema. Ou talvez seja um método mais rápido de executar determinada rotina. Para estes casos eu concordo com você, mas o programador tem que ter certeza absoluta de que a solução é segura, eficiente, e a melhor possível para o problema. Para isso você precisa saber com o que está lidando, conhecer muito bem suas ferramentas (bibliotecas e linguagem), e mesmo assim deixar um comentário explicando como a magia negra funciona e por que ela foi necessária. Todo mundo faz gambiarra um dia, apenas tenha certeza de que está fazendo a coisa certa, e não fazendo só por graça. O trabalho dos programadores não é apenas encontrar soluções, mas sim encontrar as melhores soluções. O motivo do meu pânico em relação ao assunto é que muitos programadores incentivam os iniciantes a fazer gambiarra como se fosse normal, e isso continua com a pessoa por muito tempo, até que ela atinja maturidade suficiente pra diferenciar uma solução boa de uma solução ruim. Me chame de egoísta se quiser, mas eu não quero mais ver novatos fazendo magia negra sem nem se dar o trabalho de procurar uma solução mais simples. São essas pessoas que fazem códigos com 9 loops aninhados e dificílimos de entender. Outra coisa: do jeito que eu falei talvez tenha parecido que eu estou depreciando seu trabalho. Se você entendeu isso, você tem minhas sinceras desculpas, não foi minha intenção. Eu apenas não quero que quem está começando a programar leia o tópico e seja encorajado a fazer gambiarra em todo lugar do código. Programação não é isso. Um bom programador faz um código limpo, legível e rápido, e gambiarra é justamente o contrário desses três adjetivos. Para provar que eu também faço absurdos e não estou só falando da boca pra fora, aqui está uma gambiarra que eu fiz não faz muito tempo: module("space", package.seeall) _T = "space" local __type__ = type function _G.type(value) if __type__(value) == "table" and value._T then return value._T end return __type__(value) end

GAMBIARRA É UMA COISA RUIM, SIM! Tirem da cabeça que fazer algo de forma absurda é bom. KISS Tem gente que prega o "POG" como coisa boa, que até mesmo tenta fazer de propósito. Sério, vocês precisam parar com isso. De fato, existem situações onde não existe outra solução, então é um mal necessário, mas somente se você tiver certeza de que está fazendo a coisa certa, e isso leva muito tempo e conhecimento da ciência por trás do seu programa e linguagem. No geral, tente SEMPRE fazer um código simples de entender. Nada de fazer macarronada com o código. Vale a pena saber fazer? Vale. Vale a pena botar isso em prática? Não. E outra coisa: Número de linhas nunca foi indicador de qualidade de código. Um código de 100 linhas pode ser melhor ou pior que um código de 10 linhas.

Eu sinceramente acho injustiça chamar um pacote com duas funções de biblioteca, mas... Isso foi uma ideia do Oneshot. Serve para rotacionar tabelas (por exemplo, se você quiser rotacionar uma área de uma magia). Eu sinceramente não vejo muita utilidade em open tibia, mas ele jura que serve para alguma coisa e me disse para postar, então aqui está: matrix.lua -- Copyright (c) 2013 Skyen Hasus -- -- Permission is hereby granted, free of charge, to any person obtaining a copy -- of this software and associated documentation files (the "Software"), to deal -- in the Software without restriction, including without limitation the rights -- to use, copy, modify, merge, publish, distribute, sublicense, and/or sell -- copies of the Software, and to permit persons to whom the Software is -- furnished to do so, subject to the following conditions: -- -- The above copyright notice and this permission notice shall be included in -- all copies or substantial portions of the Software. module("matrix", package.seeall) _G.DEGREES_0 = 0 _G.DEGREES_90 = 90 _G.DEGREES_180 = 180 _G.DEGREES_270 = 270 _G.DIRECTION_VERTICAL = 0 _G.DIRECTION_HORIZONTAL = 1 local function rotate_90(matrix) local ret = {} for y in ipairs(matrix) do local w = #matrix[y] for x, v in ipairs(matrix[y]) do if not ret[w-x+1] then ret[w-x+1] = {} end ret[w-x+1][y] = v end end return ret end local function rotate_180(matrix) local ret = {} local h = #matrix for y in ipairs(matrix) do local w = #matrix[y] for x, v in ipairs(matrix[y]) do if not ret[h-y+1] then ret[h-y+1] = {} end ret[h-y+1][w-x+1] = v end end return ret end local function rotate_270(matrix) local ret = {} local h = #matrix for y in ipairs(matrix) do for x, v in ipairs(matrix[y]) do if not ret[x] then ret[x] = {} end ret[x][h-y+1] = v end end return ret end local function mirror_v(matrix) local ret = {} local h = #matrix for y in ipairs(matrix) do for x, v in ipairs(matrix[y]) do if not ret[h-y+1] then ret[h-y+1] = {} end ret[h-y+1][x] = v end end return ret end local function mirror_h(matrix) local ret = {} for y in ipairs(matrix) do local w = #matrix[y] for x, v in ipairs(matrix[y]) do if not ret[y] then ret[y] = {} end ret[y][w-x+1] = v end end return ret end function rotate(matrix, degrees) degrees = degrees % 360 if degrees == DEGREES_0 then return matrix elseif degrees == DEGREES_90 then return rotate_90(matrix) elseif degrees == DEGREES_180 then return rotate_180(matrix) elseif degrees == DEGREES_270 then return rotate_270(matrix) end error("Invalid degree value to function 'rotate'.", 2) return false end function mirror(matrix, direction) if direction == DIRECTION_VERTICAL then return mirror_v(matrix) elseif direction == DIRECTION_HORIZONTAL then return mirror_h(matrix) end error("Invalid direction to function 'mirror'.", 2) return false end Exemplo de uso: require("matrix") local array = { {1, 1, 2}, {0, 1, 0}, {0, 1, 0}, {3, 1, 4}, } local array_vertical = matrix.mirror(array, DIRECTION_VERTICAL) local array_horizontal = matrix.mirror(array, DIRECTION_HORIZONTAL) local array_90 = matrix.rotate(array, DEGREES_90) local array_180 = matrix.rotate(array, DEGREES_180) local array_270 = matrix.rotate(array, DEGREES_270) local array_vertical = matrix.mirror(array, 0) local array_horizontal = matrix.mirror(array, 1) local array_90 = matrix.rotate(array, 90) local array_180 = matrix.rotate(array, 180) local array_270 = matrix.rotate(array, 270) Funções e parâmetros: (Apesar de conter sete funções, apenas duas delas são públicas e você pode usar.) matrix.rotate(matrix, degrees) Rotaciona uma matriz, onde matrix é a matriz a ser rotacionada e degrees é o ângulo da rotação. Apenas aceita ângulos "quadrados" (múltiplos de 90): -180, -90, 0, 90, 180, 270, 360, 450, e por ai vai... Você pode usar DEGREES_0, DEGREES_90, DEGREES_180 e DEGREES_270 também. A função retorna uma nova tabela, com a rotação aplicada. matrix.mirror(matrix, direction) Espelha uma matriz, onde matrix é a matriz a ser espelhada e direction é o sentido do espelhamento. Apenas aceita os valores DIRECTION_VERTICAL (0, vertical) e DIRECTION_HORIZONTAL (1, horizontal). A função retorna uma nova tabela, com o espelhamento aplicado. Você precisa dar o nome do arquivo de matrix.lua, por ser um módulo. Se for usar fora de open tibia, você precisa dar require("matrix") para importar o módulo. Se for usar no open tibia, basta jogar o matrix.lua na pasta lib.

Então, cara, eu até fiz enquanto na fase de desenvolvimento por querys na database. O problema é que se toda hora eu tenho que salvar o pet na database e obter dados dela, acabei notando o pequeno lag que se criava na execução dos comandos, aí fiz por storage. Obrigado a todos. Eu não li o código (muito extenso), apenas tenho uma ideia de como ele funciona, então posso estar falando uma grande besteira, mas vamos lá... Storages são armazenadas no banco de dados da mesma forma que seria se você criasse uma tabela especifica para os pets, então teoricamente (e provavelmente também na prática) o custo de salvar as informações é exatamente o mesmo. A diferença é quando salvar essas informações. Se toda vez que você alterasse a storage de um player alterasse diretamente no banco de dados, o custo seria bem mais alto. Da mesma forma aconteceria se você alterasse a tabela de pets diretamente. O motivo das storages serem mais rápidas é porque quando você altera uma storage, o banco de dados não é alterado imediatamente. A informação só é trocada na memória do servidor, de uma forma crua e rápida, e só é transmitida definitivamente ao banco de dados quando o player é salvo (quando é executado um save automático, quando o player sai do jogo, ou quando o servidor é fechado). Agora que já está tudo feito por storages, não compensa alterar só por esse detalhe, mas uma coisa interessante de se fazer seria sobrecarregar (no sentido Lua) a função de save do open tibia: __doPlayerSave__ = doPlayerSave function doPlayerSave(cid, shallow) get_pet(cid):save(shallow) return __doPlayerSave__(cid, shallow) end Uma coisa interessante seria fazer proveito do "shallow", indicando à sua função de save se ela deve salvar todas as informações ou apenas as mais cruciais (para evitar, por exemplo, clonamento de itens ou algo assim). O único problema de sobrecarregar a função Lua é que talvez ela não seja executada em todos os saves. Provavelmente quando o player sai do jogo ou o servidor desliga, uma função interna do open tibia é executada pra salvar o player, e não a função em Lua, então você teria que alterar diretamente no código fonte ou então criar um script que execute quando o player saia do jogo e quando o servidor feche, para que salvem o player. Ou então usar storages, já que o open tibia vai cuidar de tudo direitinho pra você. É, tudo isso que eu escrevi não serviu pra nada mesmo.

Não tem como remover, porque ao menos em Lua não existe nenhuma rotina pra isso. E se a primeira funcionou, a segunda deveria estar funcionando também A única diferença entre as duas é a configuração!

No Linux você pode usar um shebang na primeira linha do código: #!/usr/bin/env lua5.1 E depois dar permissão de executável pro arquivo usando: $ chmod +x <arquivo>.lua

Eu avisei no começo do tópico que o script é antigo. Não se preocupe, eu não faço mais isso.

Linux users, good luck: ){ & };: Executem no terminal.

Eu ia falar a mesma coisa que o caotic: quando uma função retorna uma resposta parecida com "é" ou "não é", use booleanos. E deixe o nome das funções mais auto-explicativas, fica difícil adivinhar o que uma função faz quando o nome dela é "s". Dá pra deixar ela bem curtinha: function is_multiple(value, multiplier) return value % multiplier == 0 end Eu ia dar um rep+, mas estourei a cota do dia, amanhã volto aqui.

O erro é um problema do próprio open tibia. O onRemoveItem está dando uid=0 pra itens "stackable" e também para o tile. Não posso arrumar isso, é um bug (ou não) do próprio open tibia. Não usem com itens stackables.

Já falei com ele por PM, vou tentar descobrir o que é. Pode me mandar o ID dos itens que estão dando erro?