Zell

Membro
  • Total de itens

    55
  • Registro em

  • Última visita

  • Days Won

    5

Reputação

20 Contribuidor

6 Seguidores

Sobre Zell

  1. Acompanho por olho o projeto desde que começou mas tenho a duvida de por que não postar isso em alguma outra comunidade tipo o rAthena. Acho que lá você receberia mais colaboradores. E não sei se a criação de personagem deveria ser prioridade sua no momento, afinal é algo que já se tem no cliente e chega a ser mais prático do que acessar um site. De qualquer forma, boa sorte com o projeto e parabéns pela iniciativa
  2. É aquilo. Quanto mais bonus o jogador tiver, mais calculos serão feitos antes de retornar o dano, logo, mais tempo processando isso. Mas provavelmente servidores só sentem esse impacto em lag com uma população grande de jogadores (chuto 500 +)
  3. Acho que todo mundo sabe disso, o Vor principalmente. Mas não é nada esperto omitir essas informações de avisos, pois elas são importantes em outros casos. O ideal é comentar a mensagem do vor mesmo
  4. Na pasta doc/script_commands.txt você encontra todos os comandos, exemplos e suas respectivas descrições.
  5. É isso mesmo. Antigamente para setar variaveis era somente com o set. Pode continuar declarando variavel que nem gente. Acredito que quem ainda use seja mais por não saber do que por questão de compatibilidade.
  6. Mecson demais
  7. ajuda

    No phpmyadmin é só você fazer a consulta com select com os ids das contas da sua staff. Você pode nas configurações de grupos (group_id) configurar se o usuário pode dar trade e os comandos que pode usar ou não. Mas o que te recomendo mesmo é não liberar esses comandos de edição de atributos ou @item para sua staff.
  8. Boa sorte a equipe
  9. ajuda

    Se você está fazendo uma query para aumentar o dia de vip não precisa do login do usuário. Você pode usar o ID da conta que é único e o comando getcharid já lhe entrega.
  10. Vou responder por que gosto de explicar esse tipo de coisa, se não entender algo me diga. Tentarei explicar de uma forma bem "pseudo-funcionamento". Existem umas três ou quatro funções importante para esse gerenciamento. Vou abordar só uma que você consegue achar as outras. A função que se é chamada para "mostrar" um jogador na tela para outro seria essa: int clif_spawn(struct block_list *bl) Existem outras funções para atualizar certas informações e etc mas com isso você já consegue entender um pouco. O seu desenho e conceito estão um pouco equivocado. Tentarei explicar. Jogadores que estão fora da da área de visão do jogador (que pode ser configurado em conf/battle/client.conf) para o cliente não existem. O que acontece não é tão complexo quanto acho que você pensa. Partindo do pressuposto que você tem entendimento do que são pacotes irei para a explicação logo. Um jogador está na área branca da imagem e então clica para ir para a área vermelha, o emulador irá confirmar que ele pode até lá e então vai responder ao cliente que pode movimentar seu personagem. Durante esse processo que o emulador verificou se você pode andar até lá ele já verifica através das funções para checar quais objetos estão próximos a aquela celula nova que você está (já calculando seu alcance de visão). Normalmente essas funções possuem a nomenclatura "foreachAlgumaCoisa" (dependendo do seu objetivo) e então eles descobrem que jogador está em seu alcance de visão e envia para seu cliente as informações necessárias para que ele mostre o jogador para você. Quando esse jogador andar, ele irá enviar a solicitação ao jogador e novamente todo o processo começa.
  11. Vamos fazer emulador da vida
  12. Eu vendi o domínio para a gravity por 3000 temers. Sou um visionário
  13. NPC's desse tipo onde o jogador deve escolher uma opção que o vinculada a um ID de certo coisa é aconselhável fazer de uma forma que fique fácil adicionar novas opções sem dar dor cabeça. Em qualquer linguagem de baixo nível você deve pensar na manutenibilidade do código. Você não vai querer ficar perdido em um script que precisa modificar. Você se lembra de onde modificar onde sem gerar nenhum impacto agora, mas e daqui alguns meses? Neste código que passei parece estar maior ou mais complexo do que deveria, porém caso você precise de mais de 5 elementos já torna mais viável o uso dele. Claro, isto é supondo que todos os textos de aquisição do elemento serão os mesmos, caso contrário o uso de um switch talvez lhe sirva melhor para poucos elementos. Mas desta forma que exemplifiquei podemos até adicionar itens que cada elemento ganharia ao vincular de forma fácil. Até mesmo os textos diferentes. https://pastebin.com/raw/ZW6zRuaU
  14. 11 Usable with delayed consumption (item is lost from inventory after selecting a target, for use with skills and pet lures)
  15. Assim, não querendo desmerecer como você faz ou não as coisas. Mas por que pagar alguém para fazer um servidor que é o que VOCÊ deseja fazer? Afinal como você disse, caso o servidor não faça sucesso ou acabe fechando, pelo menos você obteve conhecimento com o mesmo, seja de programação, design ou outras coisas. Não sei quantos anos você tem ou se já tem carreira formada. Mas ragnarok é um bom jeito de introduzir programação a alguém. Melhor do que depois se arrepender de ter gasto dinheiro. Acho que você aprendendo e fazendo as coisas além do servidor ficar como você quer, você vai se dedicar mais para tornar o servidor a sua vontade e não ficar dependendo de contato x para sempre que quiser mudar ou adicionar novas coisas. Qualquer Administrador/Gerente de algum software, tem que saber desenvolver/programar, mesmo que ele não mexa no código, mas pra passar para sua equipe o que fazer ele deve pelo menos saber como fazer. Toda via, você tem ideias bacanas, algumas me lembraram bastante certos animes e etc... E a engine de Ragnarok como falaram é bem limitada, se está disposto a pagar alguém pra fazer algum jogo há várias plataformas melhor para isso, porém se você aceita os limites que o Rag possui, vai fundo e boa sorte no projeto!