xWhiteWolf

esse sistema só consegue ser adaptável pra dar itens fixamente (toda task vai dar Y itens X) OU baseado no comprimento e dificuldade dar determinados itens ou um aleatorio entre uma lista. Mas essa idéia de cada task ter uma premiação diferente, da forma que o código está não é possivel

me manda uma dessas spells pra eu modificar ela e aí te ensino a fazer nas outras

o problema em ambos os casos era um addEvent sem o check de isCreature.

depende de como vc vai querer mas basicamente seu npc vai ter um storage e uma tabela contendo a quantidade de resets e os premios. Aí vc verifica se existe os resets que você tem e esse storage, esse storage vai estar salvo qual foi a ultima premiação que vc ganhou e ele só deixa pegar sempre a de menos resets pra mais resets. Então se eu tenho 8 resets eu vou ter que pegar a de 1, 3, 5 e 8 (supondo que não é todo nv que ganho prêmio) respectivamente a tabela vai ser algo assim: premios = { [quantidade de resets] = {items = {{2160, 3}, {2152, 100}, {2163, 1}}}, } if resets > storage then for i = math.max(1, storage + 1), resets do if premios then -- tem premios disponiveis pra ele, lidar com isso ou dando só o primeiro ou ja dando todos acumulados end end end

local function meteorCast(p) if isCreature(p.cid) then doCombat(p.cid, p.combat, positionToVariant(p.pos)) end end deixa a função meteorCast assim que os erros devem parar.

vc precisa alterar a source ou refazer todo o sistema de look via lua. Pq no look normal ele não mostra a special description quando vc dá look em si mesmo (configuração da source)

é só botar doPlayerAddItem(cid, id do item, quantidade) embaixo de setPlayerStorageValue(cid, 378378, resets+1) Se quiser que cada quantidade de resets dê uns itens diferentes aí precisa montar uma tabela com o numero de resets e a premiação e iterar por ela no código

pairs = função next.. ela percorre toda a tabela independente dos dados ipairs = só percorre os pares de elementos numéricos. usar ipairs é semelhante ao usar for i = 1, #table do if not table[i] then break end -- código aqui end enquanto que o pairs itera sobre praticamente qualquer index: considera a tabela local table = { [1] = 1, [2] = 2, [3] = 3, [4] = nil [5] = 4, } Se eu usar ipairs e mandar printar ele vai printar 1, 2 e 3 mesmo tendo o 5 na tabela pq o 4 é nulo e ele cancela ali, O mesmo vale se os indexes forem strings. o pairs itera sobre qualquer coisa, ele printaria 1, 2, 3, 5 (4 não pq é nulo) porém o pairs utiliza uma função next e essa função não é determinística, ou seja, ele não vai retornar exatamente na ordem desejada, então toma cuidado quando usar pairs ou ipairs. Em geral pairs é muito util, mas precisa ter um cuidado especial ao utilizá-lo pq ele é bem mais complexo.

o legal da computação é que você não precisa fazer do meu jeito, desse jeito fica grande? fica? mas funciona igual... Lembra que player não lê script, então se vc conseguiu fazer, mesmo que do seu jeito, vc é muito muito mais talentoso do que você imagina...

não entendir

não entendi o problema.. os storages ja estão declarados, eu fiz eles em função do i do meu for. getGlobalStorageValue(822080+i) Isso significa que na cave 35 o storage será 822105

vc tá usando doPlayerSetVocation ao invés de doPlayerGetVocation() e pra verificar varios numeros vc tem que usar isInArray({1,2,4,5,6}, getPlayerVocation(cid))

se a guild não tem acesso a cidade, como ela mataria o boss que nasce na cidade?

perceba que de 72 declarações de variáveis que vc tinha (72 local ____) agora você tem só um local positions e todo o resto do código funciona em função dessa tabela, sem precisar repetir código desnecessário.

vc só pode ter 60 declarações de váriáveis... se vc tem mais que isso vc tá fazendo algo errado. Nesse caso, o erro é usar 60 variáveis ao invés de uma simples tabela pra organizar tudo.

doSendMagicEffect(variantToNumber(var), CONST_ME_TELEPORT) deveria ser doSendMagicEffect(getCreaturePosition(variantToNumber(var)), CONST_ME_TELEPORT) pois a doSendMagicEffect tem uma position como primeiro parametro.

acho que o unico jeito de fazer isso vai ser criar alguma função na source pra remover o target, por creaturescripts teria que verificar se o onTarget é executado toda hr ou só no momento que dá target.

não é por nada não mas ele ta dizendo que o erro é na linha 1 numa palavra chamada "ew", aparentemente vc digitou algo no script sem querer e é isso que tá dando erro, pq meu script original nao tem ew na primeira linha.

pera deixa eu te explicar como funciona: Em meados de 90 descobriram que a criptografia de tipo HASH não era segura: isso inclui diversas categorias (sha, sha1, sha2, md1, md2, md3, md4, md5...) essas outras tentativas foram pra dificultar a quebra mas como nosso poder computacional cresceu muito, logo elas se tornaram ineficazes. Atualmente existem criptografias muito difíceis de serem quebradas, mas como o TFS é feito em sua maioria por gente que não é da computação, eles preferem continuar usando técnicas antigas e quebráveis. Como funciona o HASH: O hash é uma criptografia que você não descriptografa em nenhum momento: você cria uma senha, ele aplica o hash daquela senha e gera por ex "ahuf8a0anz" aí quando vc digitar sua senha no tibia, a source vai receber aquela senha, criptografar usando HASH novamente e comparar o HASH gerado com o salvo no banco de dados (ahuf8a0anz) se ambos forem iguais ele permite que você logue. Perceba que em nenhum ponto a gente descriptografa, por isso muita gente acredita ser seguro. O que é salt: Após alguns anos da descoberta de que os hashs existentes não eram mais uma criptografia segura, criaram esse conceito de salt que funciona da seguinte maneira: Quando você cria sua conta ele salva agora além do hash, o salt que é um conjunto de dados pseudoaleatórios. A ideia é a seguinte, nós geramos um dado 'aleatório' e salvamos ele no banco de dados, aí concatenamos a senha com o salt e aplicamos a função hash. Dessa forma nosso password ao invés de ser "ahuf8a0anz" poderá ser qualquer coisa aleatória como "gdf7765adsfa97gas7" o que torna mais difícil de quebrar já que ao quebrar o hash não teremos só a senha, mas sim ela misturada com o salt. Quando você digita sua senha agora no tibia, ele pega o salt do banco de dados, concatena ambos e compara o hash disso com o hash salvo no banco de dados. Se for igual ele permite o login. Perceba que seu erro não é resolvido ao apagar o salt, pq o hash salvo em password ainda é o salt com o password... Se você mudou a source, vc precisa verificar.. antes usava salt? agora não usa? tem que fazer as modificações pra tanto o banco quanto a source estarem vendo os mesmos tipos de dados. Espero que essa explicação esclareça um pouco suas dúvidas.

salt tem a ver com a criptografia e a forma que ele compara o hash, apagar o salt não vai mudar a forma como a source aplica o algoritmo na sua conta digitada e compara com hash e salt do banco.

salt fica em account? UPDATE `accounts` SET `salt` = ""

parece que tá faltando o arquivo lib... ele nao tá achando a tabela GRANTOWER que é criada na lib...

cara, até tenho mas essa modificação é tão trivial que acho que você mesmo pode fazer, pq além dela vc tem que ver como ajeitar a formula da quantidade de skills pra ficar algo bom pra todos os niveis. Em vez de usar a quantidade de skill necessária pro proximo level/100 vc pode só botar um valor fixo * o tamanho * a dificuldade... vai testando e vê oque fica bom: -- a divisao por 3000 foi porque cada ponto de skill try equivale a 30 tries de skill e nos naturalmente dividimos por 100. 1/30 * 1/100 = 1/3000 local qnt = math.ceil(getPlayerRequiredSkillTries(cid, SKILL_IDS[msg], getPlayerSkillLevel(cid, SKILL_IDS[msg]) + 1)/3000) * ((getPlayerStorageValue(cid, storages.length)) * (getPlayerStorageValue(cid, storages.difficult)) * config.multiplicator)

ja era pra aparecer no look do player, vc só não consegue ver qnd dá look em si mesmo, por isso o npc tem uma opção pra vc checar sua quantidade de resets. Sobre o rank, se nao me engano tem aqui nos comentários mas se nao tiver nao é dificil fazer, é só ordenar pelo storage.