Ir para conteúdo
  • Cadastre-se

KhayrusS

Desenvolvedor
  • Total de itens

    3847
  • Registro em

  • Última visita

  • Prêmios recebidos

    42

Tudo que KhayrusS postou

  1. Aqui no fórum tem alguns tutoriais que podem te ajudar com L2J [Hidden Content] Mas o ideal é que já tenha um conhecimento mínimo de Java antes de ir direto para o L2j. Isso devido a complexidade dos emuladores de lineage II. Pra Iniciante, um material focado em coias básicas seria o melhor. Eu vejo o pessoal recomendando bastante esse canal no youtube para quem está querendo aprender Java [Hidden Content]
  2. Opa, acabei de atualizar o arquivo. Obrigado por avisar
  3. Qual dúvida ficou com relação ao cliente ?
  4. Talvez uma área de dúvida seria melhor, pois acredito que a maior parte dos usuários não iriam utilizar as tags. A versão mainstream atualmente é a Kamael - Dawn of Heroes, protocolo 272. Existem outras branches com versões mais novas, mas no momento meu foco é deixar a 272 mais estável antes de prosseguir para as demais. Contudo elas estão abertas a contribuições caso queira as versões mais atuais
  5. Utiliza o Java 16. Não estou com permissão para alterar no tópico inicial
  6. Olha nas libs do projeto qual a versão do mysql-connector
  7. Esse problema é relacionado ao "timezone", quando não é definido na configuração de conexão com o banco de dados, por padrão é "perguntado" ao sistema operacional qual o "timezone". O problema é que o Windows responde essa pergunta com "Hora Oficial do Brasil", que não é reconhecido. A solução é definir nas configurações de conexão esse timezone, a propriedade responsável por essa configuração é o "serverTimeZone". Como não sei como é configurado no servidor que está usando vou deixar um exemplo: Na definição de conexão adiciona a propriedade, algo como isso: jdbc:mysql://localhost/l2jdb?serverTimezone=UTC
  8. Depende do tipo de server que esteja querendo colocar online. Na minha opinião ainda não está pronto, mas eu sou exigente. Então o que recomendo é dar uma olhada pra ver se te atende. No momento todos os bugs e melhorias estão registrados nos issues: [Hidden Content] [Hidden Content]
  9. A ideia básica é essa mesmo, deixar as pastas de config/data onde o servidor vai buscar. Se você precisa ficar atualizando a source com o projeto base, copiar de fato pode causar alguns inconvenientes na hora de atualizar. Por isso eu indico criar um link simbólico. No windows você pode procurar por Symbolic Link ou Symlinks: mklink /D Link Target Para modificar as opções da JVM: Quando é utilizado o Gradle é necessário procurar a task run no arquivo build.gradle, e adicionar a opção no jvmArgs: De modo geral é necessário modificar as configurações de "run", adicionando em opções da JVM
  10. Fala, pessoal! Vim deixar um pequeno guia de como executar o servidor l2j diretamente da IDE. Esse processo é muito útil durante o desenvolvimento. Ps. O áudio ficou um pouco baixo, porque minha filha estava dormindo ao meu lado então não pude falar mais alto. Então aumenta o áudio
  11. Como o @Lorran Oliveirafalou, se a estrutura do projeto estiver bem organizada é bem simples rodar direto da IDE. Na maioria dos casos, só é necessário colocar os caminhos corretos para os arquivos de configuração e do datapack. Se eu tiver um tempo sobrando esse fim de semana, tento fazer um vídeo de como pode ser feito com mais detalhes. @ChristoferFernandesesse erro parece ser interno do IntelliJ, então não precisa se preocupar muito com ele, a não ser que esteja atrapalhando algo.
  12. Entendi! Mas como falei, depende de como está estruturado o projeto. Mais especificamente, qual o ferramenta de build que é utilizada. Pois existem diversas ferramentas que podem necessitar de uma configuração diferente no IntelliJ. Por exemplo: Se o projeto usa maven, você precisa configurar o IntelliJ pra rodar o maven Se o projeto usa Gradle, é necessário configurar o gradle: Se usa Make, é necessário configurar o Make: Se usar outra ferramenta de build, é necessário configurá-la no IntelliJ. O ponto é que depende do projeto que está usando.
  13. Não sei se entendi muito bem o que realmente quer fazer. Mas pelo que entendi você tem duas dúvidas Esse processo chamamos de "build". Ele depende de como está estruturado o código. Isso porque existem diversas ferramentas de build, então dependendo de qual esteja sendo usada, o processo pode ser um pouco diferente. Assim é necessário dar mais informações do que está tentando usar. Não sei o que quis dizer com compilar nesse contexto, mas para compilar de modo geral no IntelliJ existe um menu Build que tem a opção para compilar
  14. Release 1.7.0-RC1 disponível: [Hidden Content] Principais correções: [Hidden Content]
  15. KhayrusS

    Erro Game Server

    Essa branch ainda está em fase inicial de desenvolvimento. Como muitos items e skills mudaram ainda há muito pra ser feito, eu pessoalmente ainda não estou trabalhando nela. Contudo fiz um teste aqui e não tenho esse problema, você modificou algo ?
  16. KhayrusS

    Erro Game Server

    Qual branch está usando ?
  17. Só um detalhe, esses scripts utilizam Jython, que podem ser compilados para a JVM Bytecode. Desse jeito ele pode aproveitar dos benefícios de código Java, incluindo as otimizações em tempo de execução do JIT.
  18. Ultimamente meu tempo é tão curto que é difícil produzir algum tipo de conteúdo. Vou ver se consigo algum tempo pra fazer algo desse tipo. Uma dica que posso dar, para facilitar a migração do eclipse para IDEA, é que você pode configurá-lo para utilizar os mesmo atalhos do eclipse. Ainda vai ter algumas dificuldades, mas já é uma ajuda para ir se acostumando.
  19. You need to give more info. What is showing in the logs ? You probably is using the wrong Datapack version
  20. Existem diferentes formas de contribuição em projetos open source, sendo uma das principais a contribuição de implementações através do Pull Request. Nesse guia, vou abordar como criar um Pull Request no projeto L2jOrg, mas que poderá ser usado em qualquer projeto que utilize git. Eu trabalho com git há alguns anos, e durante esse tempo experimentei diversas formas de utilização. Um dos melhores fluxos de trabalho pra utilizar git, na minha opinião, é o modelo "short lived branches" ou "topic branches", nesse link você pode encontrar mais detalhes. Requisitos para seguir o guia: Git; IDE (eu irei utilizar o IntelliJ IDEA, mas pode ser usada a que preferi); Uma conta no github. Obs.: a IDE é opcional, você pode utilizar apenas o cliente git para realizar os passos desse guia, mas por simplicidade será demonstrado apenas com o uso da IDE. 1º Passo - Criando um fork do projeto no github O projeto L2jOrg utiliza submódulos, é necessário realizar o fork de todos os repositórios que pretende fazer contribuições. A criação de um fork é bastante simples, apenas é necessário estar logado no github, e utilizar o botão fork na página dos repositórios: Vamos criar o fork para o primeiro repositório: [Hidden Content] Clique no botão fork no canto superior direito Caso participe de alguma organização no github, aparecerá uma tela para escolher onde será criado o fork Agora faça o mesmo processo para o repositório do Datapack: [Hidden Content]. Após feito o fork dos dois repositórios, você terá uma cópia dos repositórios. 2º Passo - Clonando seu repositório Antes de seguir esse passo, é necessário ter o git instalado. Após a criação do fork, iremos fazer o clone dos seus repositório. Esse clone nada mais é do que fazer uma cópia do seu repositório remoto, que está no github, para sua máquina. Assim, podemos modificar os arquivos com mais facilidade. Para realizar o clone, precisamos saber qual o endereço dos nossos repositórios. Podemos encontrar essa informação no github: Aqui teremos duas opções de url. Utilizando ssh ou https. Eu particulamente utilizo a com ssh por achar mais simples, já que utilizando https é necessário fornecer o usuário e senha do github para se comunicar com o repositório remoto. Caso queira utilizar ssh, mas não sabe como configurar, segue a documentação. No botão "code" do github é onde podemos encontrar as urls necessárias para fazer o clone do repositório. Copie a url que iremos utilizar na IDE, no nosso caso no IntelliJ IDEA. A primeira vez que o IntelliJ é aberto, é apresentada uma tela de "Bem Vindo". Apartir dessa tela já podemos realizar o clone do repositório, utilizando o botão "Get from VCS". Se no seu caso, ele já abriu algum projeto que você não queira fechar, é só utlizar o menu "File" -> "New" -> "Project from Version Control" Irá aparecer uma janela para colocar a url do projeto, após adicionar a url e escolher onde seu projeto vai ficar é só clicar em "clone". Ao finalizar o clone, o IntelliJ abre a janela com o arquivos do projeto: Algo que vale à pena mencionar é que mesmo sem ter feito o clone do Datapack, o Intellij realizou o clone automaticamente. Isso ocorre devido ao projeto utlizar submodules. Para mais detalhes veja esse artigo! Vemos verificar o conteúdo dos repositório, para isso clique no nome da branch "development" no canto inferior direito. Aqui é mostrado as branches existentes no repositório. Nesse caso, o Datapack está em um estado que chamamos de "detached head". Rudemente falando, esse estado indica que fizemos o checkout de um commit específico ao ínves de uma branch. Aqui você encontra mais detalhes! Vamos "corrigir" esse estado fazendo o checkout da branch development. Clique em origin/development e checkout: 3º Passo - Configurando Remotes Agora vamos para uma das mais importantes partes desse guia. Uma das maiores dificuldades que algumas pessoas têm ao se trabalhar com o modelo colaborativo do git, é manter seu repositório atualizado com o repositório oficial. Quando realizamos um clone de um repositório fork, para o git aquele repositório é o principal. Mas no modelo colaborativo, é necessário configurar o git para reconhecer o repositório oficial também. Isso nos ajudará a manter o repositório atualizado com o oficial. Para isso vamos configurar "os Remotes" do git. Vá no menu "Git" -> "Manage Remotes" Irá aparecer uma janela para configurar os remotes. Note que já temos dois remotes configurados, um para o Core e outro para o Datapack. O remote do core está correto, mas o Datapack está configurado para o repositório oficial. Isso ocorre devido ao arquivo de configuração responsável pelo submodule. Vamos corrigir o Datapack e adicionar mais dois remotes. Para isso vamos pegar a url dos repositórios oficiais. Após a configuração os remotes ficaram assim: Após a configuração, vamos atualizar o repositório com o conteúdo dos novos remotes, para isso vá no menu "Git" -> Fetch. Vamos acessar a tab git do IntelliJ, por padrão fica no canto inferior esquerdo, para vermos com mais detalhes o conteúdo do repositório. Aqui podemos ver os conteúdo tanto do repositório fork quanto do oficial. 4º Passo - Realizando mudanças Vamos realizar um mudança simples, apenas para demonstrar como o workflow funciona. A primeira coisa a fazer antes de realizar a mudança é criar uma nova branch. Clique na branch development, canto inferior direito, depois "New Branch". Der um nome sugestivo para a branch, de forma a dar uma ideia o que aquela branch vai corrigir ou modificar. Agora podemos realizar a mudança desejada. Após realizar a mudança, vamos abrir a aba "commit" que fica do lado esquerdo. Nessa janela podemos selecionar quais os arquivos que fazem parte da mudança, para enviar a modificação para o repositório. Após selecionar os arquivos necessários, preenchemos a mensagem do commit com uma algo que descreva o que está sendo mudado. O ideal é que se utilize poucas palavras para descrever a mudança. Em casos em que é necessário algo mais detalhado, escreva na primeira uma descrição breve, e após uma linha escreva a descrição completa. Agora podemos fazer o commit e o push das mudanças. Commit -> realiza a mudança no seu repositório local Push -> envia a mudança para o respositório remoto ( github) Abrirar uma tela para alterar alguma opção do push, se necessário. Aqui podemos ver que será criada uma nova branch no repositório remoto, sinalizado pelo label "new" após o nome da branch. Após verificar que está tudo correto, clique no "push". *Lembrando que o remote origin é o repositório fork, então a mudança vai para esse repositório e não para o oficial. Após o push, vamos olhar como ficou o repositório no github. Podemos ver que ao entrar no github ele já nos mostra que foi realizado um push recentemente no repositório. E finalmente fornece um botão para realizarmos o pull request. Clique no botão "compare & pull request". O github abrirá a página de pull request do repositório oficial, automaticamente preencherar algumas informações com a mensagem que colocamos no commit. Nessa página, podemos configurar para qual branch o pull request será feito. Por padrão ele fará o pull request na branch "development", caso o pull request seja para outra branch você pode alterá-la. Clique no botão "Create pull request". Ao criar o pull request a mudança vai passar por algumas checagens automáticas, e ficará aberto para alguém da equipe analisar o que foi mudado. Essa é fase que chamamos de code review, aqui fazemos uma verificação geral da mudança. Algumas das coisas que verificamos aqui: A qualidade do código; Se a mudança faz sentido; Se a mudança é necessária; Se o código faz o que supostamente deveria fazer; Se não existe código malicioso; entre outras coisas; Alguma pessoa do time irá realizar o review do código, podendo aprovar, pedir mudanças ou apenas não aceitar o pull request 5º Passo - Atualizando o repositório com o conteúdo do repositório oficial Após o pull request ser aceito, ele é incorporado ao repositório oficial. Então é necessário que o repositório fork e o local seja sempre atualizado também. Para isso, vamos voltar ao IntelliJ. A primeira coisa a fazer é retornar para nossa branch padrão "development". Vamos fazer o checkout dela. Agora vamos fazer o pull (copiar) das alterações realizados no repositório oficial. Você pode clicar com o botão direito em algum arquivo do projeto -> Git -> Pull... Vamos configurar de onde queremos receber as atualizações, nesse caso queremos atualizar a nossa branch com o repositório oficial e branch development, que foi a que submetemos o pull request. Podemos ver que nossa branch local está atualizada com a mudança que fizemos no pull request: Após realizar o pull dessas alterações, você pode fazer push para o seu repositório fork, para mantê-lo sempre atualizado. Esse processo pode parecer um pouco complicado, ou até mesmo com vários passos. Mas é uma forma de coloboração bastante eficaz que permite a fácil utilização de múltiplos repositórios, sem muitas complicações de merge. Mas isso já é uma outra história. O importante é sempre lembrar: Antes de fazer qualquer mudança crie uma nova branch sempre a partir da branch padrão, nesse caso "development" Se seu pull request não foi aprovado ainda, e você precisa fazer uma alteração diferente, volte para branch padrão, crie uma nova branch apartir dela e só então comece a realizar a próxima mudança Lembre-se de manter seu repositório sempre atualizado com o oficial De vez em quando faça uma limpeza, delete as branchs que foram criadas e as mudanças já foram aprovadas. Lembre-se o modelo é "short lived branch" então elas tem vida curta mesmo. []'s
  21. Dá uma olhada no UNION do SQL. SELECT name FROM weapon WHERE item_id = <item_id> UNION SELECT name FROM armo WHERE item_id = <item_id> UNION SELECT name FROM etcItem WHERE item_id = <item_id>
  22. You can use this launch: [Hidden Content] put it inside of system folder and configure the IP in the connect.ini file.
  23. Sim, funciona, mas algumas novas funcionalidades do Java não. Você só precisa remover a opção ZGC dos arquivos .bat
×
×
  • Criar Novo...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.