Classificação de Membros

Algumas Chaotic/Flag Zone's edit o Type de acordo com o Mod de sua DataPack Varias Zones By: AlooK Core Grand Boss Chaotic Zone - Creditos Luke Garcia Forbin Gateway + Cherub Galaxya [ TOI 13 ] By: AlooK Algun's Raid Boss By: AlooK ( Esse vc's Precisam testar , so me lembro dos de Varkas e Ketra ) Procure saber qual e a Linha Type do mod adicionado na sua Pack , Se for Chaoticzone , altere todos Flagzone para Chaoticzone * Exemplo: <zone type="FlagZone" para <zone type="Chaoticzone" * blá ... bláa ..blá by: AlooK

Projeto no github Github Wiki Maven Central Releases Há um tempo estive me perguntando o porquê do mmocore, um dos principais componentes dos servidores L2J, não estar sendo evoluído. O máximo de melhoria que vi, pelos diversos projetos que tive acesso ao código, foi o uso de mais de um SelectorThread. Depois de um tempo de pesquisa, procurando por alguma modificação significante no mmocore, cheguei a conclusão que essa falta de melhorias só podia ter 3 explicações: A alteração no mmocore é custosa e devido ao tempo de maturidade seria um grande risco; Utilizar outra abordagem não iria apresentar um melhor desempenho, talvez até piorasse. Então quem tentou, provavelmente desistiu; Quem evoluiu o mmocore simplesmente não quis compartilhar. Na minha percepção era improvável que uma tecnologia com mais de 15 anos, ainda continue sendo a melhor opção para esse cenário. Visto que a biblioteca NIO, atualmente utilizada pelo mmocore, foi lançada com o Java 1.4 e uma atualização dessa mesma biblioteca chamada de NIO2 foi lançada com o Java 7, então há uma chance de melhorar o mmocore utilizando a API introduzida pelo Java 7. Uns dias atrás, fiquei um pouco ocioso e resolvi tirar a prova eu mesmo. Resolvi desenvolver um novo mmocore, tentando manter o máximo possível de compatibilidade com o atual, utilizando sockets assíncronos que em teoria iria melhorar o tempo de resposta cliente - servidor, o que acarretaria na diminuição de lag. Mas nem tudo é perfeito, há um preço a se pagar por essa melhoria: utilização de mais recursos (Memória e CPU). Inicialmente estimei que haveria um aumento de 25 a 40 KB no consumo de memória para cada player logado, o que daria 4 MB a cada 100 player, se você fizer a façanha de colocar 10000 players no servidor, esse número subiria para 400 MB, o que não é lá muita coisa, levando em consideração os recursos disponíveis atualmente. Após o desenvolvimento de uma versão utilizável, fiz alguns testes de carga utilizando o jmeter, que são apresentados nas tabelas abaixo: O teste realizado foi bem simples, projetado apenas para saber o tempo de resposta de cada solução. Para não sofrer interferência por causa da latência de rede foi realizado em uma única máquina, o que não é recomendado por causa do compartilhamento de recursos, principalmente CPU, entre o jmeter e o servidor. Mas acredito que para uma versão inicial já é o bastante. O teste consiste em uma variedade de players (conexões) enviarem um pacote de 8 Kb, que é maior que a maioria dos pacotes utilizados pelo cliente do Lineage 2, e esperar uma resposta de também 8 Kb. Assim foi calculado o tempo de conexão mais o Round Trip do envio de pacotes. Segue uma breve explicação sobre os dados que estão nas tabelas: Players - Quantidade de conexões concorrentes fazendo requisições (enviado pacote) para o servidor. Média - O tempo médio de conexão mais o tempo de envio do pacote mais o tempo de recebimento e leitura (Round Trip Time) em milissegundos. Min - O tempo mínimo de conexão mais o tempo de envio do pacote mais o tempo de recebimento e leitura (Round Trip Time) em milissegundos. Max - O tempo máximo de conexão mais o tempo de envio do pacote mais o tempo de recebimento e leitura (Round Trip Time) em milissegundos. D. Padrão - medida de dispersão em torno da média, no geral quanto menor quer dizer que os tempos estão mais próximos uns dos outros. Throughput - Quantidade de requisições por segundo. Erro - Porcentagem de requisições que retornaram com erro. MMOCore utilizando Selector: _________________________________________________________________ |Players | Média | Min | Max | D. Padrão | Throughput |Erro | |----------------------------------------------------------------| |998 | 60ms | 43ms | 101ms | 8.68 | 487.3/s |0.0 | |1999 | 62ms | 44ms | 115ms | 9.01 | 769.73/s |0.0 | |3993 | 100ms | 42ms | 1261ms | 190.44 | 733.60/s |0.0 | |7988 | 411ms | 43ms | 7285ms | 889.66 | 807.27/s |0.0 | |31976 | 804ms | 6ms | 8792ms | 1628.33 | 769.96/s |11,3%| ͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ MMOCore Assíncrono (2.0) _________________________________________________________________ |Players | Média | Min | Max | D. Padrão | Throughput |Erro | |-----------------------------------------------------------------| |1000 |1ms |0ms |45ms |4.94 |539.08 |0.0 | |2000 |1ms |0ms |55ms |4.34 |764.81 |0.0 | |4000 |2ms |0ms |64ms |4.62 |804.50 |0.0 | |8000 |1ms |0ms |152ms |6.13 |1106.19 |0.0 | |32000 |726ms |0ms |45,159s |2060.37 |696.06 |11,7% | ͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ ͞ ͞ ͞ ͞͞ ͞ ͞ No geral, utilizando sockets assíncronos apresentou um melhor desempenho, como pode ser visto. Os arquivos com o resultado dos testes estão disponíveis no github [ ]'s

Abandoned Camp ai amigo, edita de acordo com sua rev, as linhas estão ai. <zone type="ChaoticSelfZone" shape="NPoly" minZ="-10000" maxZ="10000"> <node X="-54265" Y="160175" /> <node X="-81656" Y="145653" /> <node X="-64984" Y="125886" /> <node X="-38353" Y="131216" /> <spawn X="107568" Y="218256" Z="-3624" /> <spawn X="107920" Y="218240" Z="-3624" /> <spawn X="107808" Y="217856" Z="-3624" /> <spawn X="108032" Y="218048" Z="-3624" /> <spawn X="107552" Y="218000" Z="-3624" /> <spawn X="110912" Y="219584" Z="-3624" /> <spawn X="110768" Y="219824" Z="-3624" /> <spawn X="110688" Y="220576" Z="-3624" /> <spawn X="110896" Y="220768" Z="-3624" /> <spawn X="111856" Y="220752" Z="-3624" /> <spawn X="112112" Y="220576" Z="-3624" /> <spawn X="112064" Y="219792" Z="-3624" /> <spawn X="111888" Y="219584" Z="-3624" /> <spawn X="17313" Y="170364" Z="-3499" isChaotic="true" /> </zone>

Tópico atualizado com a Release 2.2.0

Isso. Eu preciso só de mais duas informações: o valor dessa constante ADD_SKILL_SAVE; e o código dessa classe: TimeStamp.

bom eu to procurando uma revisao boa pra por online , pq ja to com site , dedicado , hospedagem , dominio so falta o server ta complicado achar um bonzinho

me manda mano tbm vlw

Aparentemente essa parte do código está correta. Procura pelo método que salva essas informações no DB, provavelmente algo parecido com 'storeEffects'.

public void restoreEffects(final boolean activateEffects) { Connection con = null; try { con = L2DatabaseFactory.getInstance().getConnection(false); PreparedStatement statement; ResultSet rset; /** * Restore Type 0 These skill were still in effect on the character upon logout. Some of which were self casted and might still have had a long reuse delay which also is restored. */ statement = con.prepareStatement(RESTORE_SKILL_SAVE); statement.setInt(1, getObjectId()); statement.setInt(2, getClassIndex()); statement.setInt(3, 0); rset = statement.executeQuery(); while (rset.next()) { final int skillId = rset.getInt("skill_id"); final int skillLvl = rset.getInt("skill_level"); final int effectCount = rset.getInt("effect_count"); final int effectCurTime = rset.getInt("effect_cur_time"); final long reuseDelay = rset.getLong("reuse_delay"); // Just incase the admin minipulated this table incorrectly :x if (skillId == -1 || effectCount == -1 || effectCurTime == -1 || reuseDelay < 0) { continue; } if (activateEffects) { L2Skill skill = SkillTable.getInstance().getInfo(skillId, skillLvl); skill.getEffects(this, this, false, false, false); skill = null; for (final L2Effect effect : getAllEffects()) { if (effect.getSkill().getId() == skillId) { effect.setCount(effectCount); effect.setFirstTime(effectCurTime); } } } if (reuseDelay > 10) { final L2Skill skill = SkillTable.getInstance().getInfo(skillId, skillLvl); if (skill == null) continue; disableSkill(skill, reuseDelay); addTimeStamp(new TimeStamp(skill, reuseDelay)); } } DatabaseUtils.close(rset); DatabaseUtils.close(statement); rset = null; statement = null; /** * Restore Type 1 The remaning skills lost effect upon logout but were still under a high reuse delay. */ statement = con.prepareStatement(RESTORE_SKILL_SAVE); statement.setInt(1, getObjectId()); statement.setInt(2, getClassIndex()); statement.setInt(3, 1); rset = statement.executeQuery(); while (rset.next()) { final int skillId = rset.getInt("skill_id"); final int skillLvl = rset.getInt("skill_level"); final long reuseDelay = rset.getLong("reuse_delay"); if (reuseDelay <= 0) { continue; } final L2Skill skill = SkillTable.getInstance().getInfo(skillId, skillLvl); if (skill == null) continue; disableSkill(skill, reuseDelay); addTimeStamp(new TimeStamp(skill, reuseDelay)); } DatabaseUtils.close(rset); DatabaseUtils.close(statement); rset = null; statement = con.prepareStatement(DELETE_SKILL_SAVE); statement.setInt(1, getObjectId()); statement.setInt(2, getClassIndex()); statement.executeUpdate(); DatabaseUtils.close(statement); statement = null; } catch (final Exception e) { if (Config.ENABLE_ALL_EXCEPTIONS) e.printStackTrace(); LOGGER.warn("Could not restore active effect data: " + e); } finally { CloseUtil.close(con); } updateEffectIcons(); } pode me dizer onde devo alterar?

Como você mesmo falou, não está salvando no banco de dados essa informação ou essa informação não está sendo restaurada. Você precisa salvar essa informação no método 'onDisconnection' da classe L2GameClient e restaurar no método que carrega os dados do player na classe L2PcInstance. Geralmente essa informação é salva na tabela 'characters_skills_save'. Infelizmente não conheço a Frozen pra te ajudar além disso.

esse gato [Hidden Content]