dalvorsn

Se o servidor cair nao da pra executar a query tambem, nao da nem pra agendar no scheduler, explicar melhor qual o proposito disso para eu ver se tem algum outro meio de fazer

Usa o decay

Ai ja é outro erro, python define os blocos pela identação, o erro ta descrevendo exatamente o problema

Ta passando um tuple como argumento para color e tentando chamar um metodo de uma tuple '-' Printa o que tem de conteudo nela, pelo que eu saiba tuple só tem index numerico e sequencial

Yep, recompile, e diga se funcionou

Você certamente não entendeu a ideia, o script tem que remover todas as stones necessárias, se forem mais de uma ele remove a que foi usada no use with e as demais desse id restantes para completar a quantidade de stones necessárias, se ele remover como tu ta falando, vai sempre remover apenas uma stone, e isso seria um erro.

Nessa parte: doPlayerRemoveItem(cid, item.itemid, evo[monster][2]-1)doRemoveItem(item.uid, 1) Modifique para: doRemoveItem(item.uid, 1)if evo[monster][2] > 1 then doPlayerRemoveItem(cid, item.itemid, evo[monster][2]-1)end

Deṕos de CXX_FLAGS, na linha seguinte, bota isso: LIBS = -lmysqlclient -llua5.1 -lboost_filesystem -lboost_date_time -lboost_system -lboost_regex -lboost_thread -lcrypto -lpthread -lz -lxml2

Não esse, o makefile.am, o que gerencia as flags do projeto e etc, esse ai é gerado apartir do outro

Isso ta com cara de erro de flag, ja disse, mas se tu nao pastar o makefile fica dificil ajudar u.u

Como ta o makefile? Acredito que esteja faltando flag

Posta o log completo do erro né

Provavelmente, chegou a testar?

Ah sim, agora que notei, pode sim, mas não muda a lista do onDeath ainda

Mas isso foi o que eu fiz na primeira, o unico problema ai é que em outros lugares onde ele usa o damage map vai ter que adaptar também, até a nivel de script, a deathlist por exemplo vai ta passando o guid quando for player

Só um breve comentário, o numero de núcleos do processador a partir de 3 não faz diferença pra otserv, porque ele só usa 3 threads (dispatcher, scheduler, e asio), entao foca mais no clock individual do que o numero de cores, porque a nao ser que va rodar mais de um server esses nucleos extras ficarão ociosos. A máquina depende muito de quantos players tu espera suportar, e qual tamanho do mapa. Alem disso scripts mal feitos e codigos errados podem também causar lag, como por exemplo o uso demasiado de creature scripts onThing. Um projeto de grande porte usaria pelo menos duas máquinas, uma pra db e outra para os servers (ate uns 3 ainda e de boa), memoria tu expande a medida que necessite, é relativamente barato. E nao hospede site na mesma maquina do servidor, isso e um grande erro pois um ataque ao site travaria o server.

Sim, mas o server que envia o effect, se ele estiver limitado ao u8 qualquer valor que tentar usar acima de 256 vai dar overflow Voce teve com certeza que alterar no game.cpp e em protocolgame.cpp, a não ser que no seu server ele nao defina os parametros como uint8_t. Quanto ao tools, ele é usado para pegar o effect como string, e não como enum, não é exatamente necessário, tu usa normalmente sem isso

Negativo, se você não trocar todas as funções no server que usam u8 ele vai dar overflow numa tentativa de cast. Tem que mudar tanto no game, como no packet do protocolgame, e onde mais utilizar ela passando como parametro um u8

Tu tem que colocar elas é na pasta do compilador, e não do projeto

Tu nao instalou ou instalou as libs de forma errada

Sim, facilmente. C++ g_game.getPlayerByGUID(guid) Lua getPlayerByGUID(guid)

A lista permanece enquanto o monstro estiver vivo, te dar um exemplo de algo que aconteceria, se eu ataco o pokemon e corro, espero o battle e deslogo, e eu volto perto dele novamente, ele ja nao vai mais reconhecer que esse player atacou ele porque ele relogou. Caso ele morra aconteceria a mesma coisa. Se isso que foi citado acima não é problema, então basta modificar para: uint32_t id = creature->getID(); if(creature->getMaster() && creature->getMaster()->getPlayer()) id = creature->getMaster()->getID(); if (isPassive() && !hasBeenAttacked(id)) { return false; } e void CreatureaddDamagePoints(Creature* attacker, int32_t damagePoints){ if(damagePoints < 0) return; uint32_t attackerId = 0; if(attacker){ if(attacker->getMaster() && attacker->getMaster()->getPlayer()) attackerId = attacker->getMaster()->getID(); else attackerId = attacker->getID(); }

Não adiantaria, porque o uid é temporario, quando o player deslogar esse uid perde referencia.

Eu alertei que ocorreriam problemas por usar o guid, o deathlist passou a salvar o guid ao invez do uid, logicamente onde mais ele acessa deve tentar encontrar pelo uid alternativamente. Para fazer sem ser assim, teria que criar um outro array, talvez seja até mais trabalhoso.

No monster.cpp no select target tu deixa assim: uint32_t id = creature->getID(); if(creature->getMaster() && creature->getMaster()->getPlayer()) id = creature->getMaster()->getPlayer()->getGUID(); else if(creature->getPlayer()) id = creature->getPlayer()->getGUID(); if (isPassive() && !hasBeenAttacked(id)) { return false; } E o no creature.cpp no addDamagePoints tu deixa assim: void CreatureaddDamagePoints(Creature* attacker, int32_t damagePoints){ if(damagePoints < 0) return; uint32_t attackerId = 0; if(attacker){ if(attacker->getPlayer()) attackerId = attacker->getPlayer()->getGUID(); else if(attacker->getMaster() && attacker->getMaster()->getPlayer()) attackerId = attacker->getMaster()->getPlayer()->getGUID(); else attackerId = attacker->getID(); } Agora se atenta a uma coisa, quando fizer isso, ele vai sempre que houver um master e ele for um player, ou quando for um player salvar o guid. Então outros lugares que esteja usando o hasBeenAttacked deve ter essa logica também, caso contrário não irão encontrar