dalvorsn

Parece ta bacana, só uma coisa, em relação ao uso de storage, tu pode substituir isso por uma condition outfit. E tem mais uma coisa, quando anda no pxg ele para a pesca, tu pode fazer isso pelo onThink mesmo que tu ja usou ai, so verificar se ele andou mesmo e tals. não me lembro agora se tem alguma callback pra onMove no tfs 1.x, vou dar uma olhada. Uma coisa bacana seria tambem fazer uma relação entre fishing level e quantidade de pokes que podem vir, algo como: local num = math.min(math.max(1, math.floor((playerSkill - fishIsca.skill) /10)), 4) Tu disse que programa em c++, math.min e max são a mesma do c++ std::min std::max , dai isso vai fazer vir o maximo de 4 pokes, e a cada 10 skills que tu exceder a skill da isca tu adiciona mais um pokemon pra poder vir dai é só math.random(num) e pronto xD

Considerando que tudo que tu disse é verdade, e que esta usando o binario correto gerado pela compilação, a unica coisa que poderia explicar isso é que em alguma lib esta setando a variavel setPokemonLevel como nil. Dê um find in files nos arquivos do servidor e veja se acha algo semelhante

Eu participaria, mas tem que ter um tema definido, esse negocio de tema livre sempre da merda. E acho bacana ter requisitos, por exemplo, se eu quiser fazer um sistema pra tfs 1.1 e otclient eu terei muiiito mais recursos que um sistema feito num tfs 0.3.6 para cliente tibia(estou supondo que quando se refere a scripts está se referindo a script dentro do opentibia, e não algo generico em lua puro) Quanto a premiação acho valido algo simbolico como uma medalha

Não existe limitação alguma no otc, inclusive dentro da classe Creature existe a função setName void Creature::setName(const std::string& name) { m_nameCache.setText(name); m_name = name; } Porém a questao é nos pacotes, quando uma criatura ja é conhecida, o server nao envia novamente diversos dados, não te aconselho a mecher nessa parte. Meu conselho é o seguinte, crie um opcode para enviar o nome da creature, dai no cliente tu só vai precisar receber o opcode, com algum parametro que lhe permita identificar a criatura. Porem tem que lembra de uma coisa, voce precisa enviar esse opcode pra todos os spectators da creature para que atualize em todos.

sem postar o script é impossivel pra que alguem te ajude tu tem que mostrar o script, em alguns casos ate nas sources tem que verificar

Como ta no *.otmod? se não tiver como autoload não vai iniciar. O usual é colocar ele no load-after do game interface

Precisa disso não vei, é so acessar o nome do monsterType, que é o que carrega quando da load no monster int32_t LuaScriptInterface::luaGetCreatureName(lua_State* L) { //getCreatureName(cid) ScriptEnviroment* env = getEnv(); if(Creature* creature = env->getCreatureByUID(popNumber(L))) { if(Monster* monster = creature->getMonster()) lua_pushstring(L, monster->getMonsterType()->name.c_str() ); else lua_pushstring(L, creature->getName().c_str()); } else { errorEx(getError(LUA_ERROR_CREATURE_NOT_FOUND)); lua_pushboolean(L, false); } return 1; }

No script não tem nada relacionando a ela então, tem que ver nas sources como ta, só pode ser la

Mas isso não formata o codigo não né?

https://gist.github.com/dalvorsn/ddd2e23ab8c651fb91da ps.: tu não falou a respeito do level, então julguei que seria um valor dinamico de acordo com a cidade ...

O tipo de combate não define o effect, ele é definido de outra maneira, posta a spell se não fica dificil te ajudar ps.: o distro que está usando também é de suma importancia

Não é dificl, basta pegar um de exemplo, se usar nodes então facilita muito. Eu poderia fazer pra ti, mas não te traria conhecimento se tu não tentasse primeiro.

Segundo as sources, os WeaponType_t sao: enum WeaponType_t { WEAPON_NONE = 0, WEAPON_SWORD, WEAPON_CLUB, WEAPON_AXE, WEAPON_DIST, WEAPON_SHIELD, WEAPON_FIST, WEAPON_WAND, WEAPON_AMMO }; Ou seja, começa em 0, sendo none, depois sword 1 ate chegar em ammo que é o 8. Agora é só ir nessa parte do script: function isHandItem(uid) -- NW based on Mock uid = uid or 0 if isInArray({1,2,3,4,5,6}, getItemWeaponType(uid)) then return true end return false end Especificamente na tabela, removendo os numeros referentes aos tipos de equipamento que não quer refinar. function isHandItem(uid) -- NW based on Mock uid = uid or 0 if isInArray({5,6}, getItemWeaponType(uid)) then return true end return false end Deixando assim somente serão refinados shield e fist.

Tem bbcode de github ai?

começa a fazer ele que eu te ajudo na parte da storage

https://gist.github.com/dalvorsn/181968ae477debd90d2d

De mais informações sobre o servidor, mostre mais dados para que possam te ajudar. Em si parece simples, "adicionar um novo pokemon", mas deve-se levar em conta que um unico pokemon está ligado a diversos sistemas(o que vai variar de acordo com o servidor open source a que se refere). Adicionar como monstro, sem sistemas nem magias e simples, basta criar o xml dele com os respectivos dados, health, looktype, name, name description e etc. Porém ele não vai ter magias, não vai ter os comandos "m1" etc, não vai ter a vida regulada por scripts, não terá captura, não terá nada, será apenas um monstro. Entendo isso, você deve se perguntar: - Quais sistemas eu tenho no meu servidor? - Quais dependem de configuração individual de pokemon? - Quais os arquivos responsaveis por isso e como faço para adicioná-las? - Tenho conhecimento em programação o suficiente para entendê-los? Dentre outras ... Bom, boa sorte, e tente ser menos genérico. A pergunta é simples, mas a resposta é demasiadamente extensa.

Claro que sim, é só controlar no goback/death e etc Voce terá que mudar o modo como é salvo, terás que salvar quantos segundos restam para a magia ser usada, e só iniciar a contagem quando der go Faça algo assim na string que salvar no attribute: local example = "LastGo: "..os.time() .."TimeRemain: 5" Toda vez que der go(summonar seu pokemon) tu seta o atributo lastGo, e toda vez que der back seta o TimeRemain dai na função de pegar o cooldown, voce vai somar o lastGo com o TimeRemain e comparar com o os.time()

Ninguem vai adivinhar o erro por uma imagem, poste o modulo que talvez alguem te ajude. Podem ser inumeras coisas, mas a mais provavel e que no otui esteja sendo configurados uma quantidade fixa de moves, sendo que o certo seria criar os widgets de acordo com o numero de moves

Procure por algum addEvent, e a unica forma de fazer esse delay, leia o script e veja qual o certo

Acho que não dá não, tu tem é que editar no otb/dat mesmo

Se tu quer usar a lib do jiddo system leia e aprenda como usá-la, os arquivos dela estão todos no pasta de npcs do seu servidor, va lendo aos poucos e testando, sem duvidas ela tem muita funcionalidades, mas sinceramente acho muito mais versátil e livre fazer diretamente com as callbacks, voce com uma tabela simples faz o talkstate, e as falas por ifs, não tem misterio nenhum nisso

Usa somente as callbacks do npc, nao usa o jiddo system function onCreatureAppear(cid) --aqui e quando player chega perto end function onCreatureDisappear(cid) -- aqui e quando o player se afasta da visao do npc end function onCreatureSay(cid, type, msg) -- aqui e quando o player fala, e aqui que tem que fazer o msg container, do jeito que tu tava --fazendo no primeiro hi ele nao chamava sua funcao ele tava chamando a --callback do jiddo end function onThink() -- aqui e a callback que executa de tempos em tempos, nao sei dizer de quantos --emquantos segundos, mas deve ter configuracao pra isso no xml end

acabei de falar, "é só tirar as mensagens de greeting do xml", dai na callback onSay do npc tu faz normal, como os npcs mais antigos aquele msgcontains e etc

negativo, tem como tu configurar tudo em lua, é so tirar as mensagem de greeting do xml