Protimus

Administrador
  • Total de itens

    1.652
  • Registro em

  • Última visita

  • Days Won

    18

Reputação

176 Especialista

Sobre Protimus

  • Rank
    Administrador & Fundador
  • Data de Nascimento 20-02-1991

Informa??o do Perfil

  • Sexo:
    N?o informado

Últimos Visitantes

18.078 visualizações
  1. Sobre a utilização de memória e otimização é importante salientar o que o SoulBlaker citou. A linguagem de script do emulador não é uma linguagem padrão, ela foi "criada" para uso exclusivo do próprio npc de jogo. Utiliza-se a base de código do C, então muitas coisas são importadas do próprio C. É muito mais interessante e rápido você usar tudo que é padrão dele do que usar macros que foram definidas pelo próprio emulador. Quando você acessa uma macro, você terá que fazer consulta direta do código inteiro da macro/comando de script para coisas que você pode fazer na própria mão... Obviamente os comandos foram feitos pra ajudar não ter que fazer tudo na mão, então não há motivo para não usá-los, mesmo que isso consuma mais do desempenho, coisa que é mínima na maioria dos casos. Entretanto o uso abusivo de estruturas de repetição para estilizar o npc ou então de variáveis temporárias, faz com que o código fique mais demorado ou dependendo do tipo de npc e a quantidade de requisições que são feitas por jogadores nele, o consumo seja maior. Ou seja: Nem sempre um código bonito e enxuto é um código verdadeiramente eficaz, podendo ser um código de várias linhas mais rápido e com menos consumo que um menor
  2. Infelizmente não tenho permissões necessárias para realizar a operação. Irei abrir um chamado técnico para resolver o seu problema, por gentileza peço que aguarde 5 dias até que obtenhamos uma resposta. Você será informado através de mensagem quando o problema for solucionado. Agradeço sua atenção!
  3. Obra de arte, não esperava menos de ti.
  4. Quando você tem uma condição de escolha, utiliza-se o comando "case" em C e C++. No caso de scripts o comando que eu utilizo é o switch select, o mesmo que você usou. Como são várias escolhas, não há a necessidade de colocar vários ifs pois o código fica sujo. Caso existam condições dentro das condições de escolha, você pode adicionar um if dentro dos cases, conforme a necessidade. A condição que nega a condição anterior é o else e caso você queira fazer uma condição posterior a outra, utiliza-se o else if.
  5. Sim, comecei a criar as telas referente as traduções. Haverá uma tela quando você clica em traduções, onde terão dois botões: "Traduzir" e "Entregar". Cada botão direciona para outra tela correspondente à sua devida função, ou seja, a parte de traduções tem 3 telas. Eu já fiz a tela de envio, para entregas e estou fazendo a tela de traduções em si, preciso de depois de dois botões para fazer a outra tela principal que direciona para essas duas.
  6. Página de estatísticas criada: Eu ainda quero colocar um degrade na fonte do h1 do topo referente ao título "Estatísticas de desenvolvimento". Também falta estilizar o hover do gráfico pie (pizza). Fora isso, a página está funcionando com Angular e depois só preciso fazer integrações com o banco de dados para pegar "dados reais".
  7. Eu ainda não decidi o que vou fazer em todas, mas as que eu decidi são as abaixo. Tela de bugs: Vai ser um "mini-forum" dentro da tela de bugs, igual o antigo IP Track que utilizávamos aqui ou outros sistemas de comentário. Onde a pessoa digita qual é o bug, nós atribuímos um status e deixamos público para qualquer usuário ou os desenvolvedores resolverem. É possível conversar com postagens, igual fazemos no fórum. Tela de traduções: A tela de traduções vai ser um pouco diferente, a ideia é fazer uma tabela com todos os arquivos que precisam de tradução e a pessoa pode selecionar qual quer traduzir. Depois de escolher, a tradução ficará pendente e o usuário terá um tempo para traduzir conforme a quantidade de linhas do arquivo. Caso ela não entregue a tradução dentro do período estabelecido pelo sistema, automaticamente o status da tradução muda para "não-traduzido" e sem vinculo com qualquer usuário, podendo ser "pego" novamente por quem queira. Quando a tradução é concluída, o usuário pode enviar o arquivo diretamente pelo sistema. Sempre que uma tradução for enviada/concluída, será enviado um alerta através de email para todos os desenvolvedores. Um dos desenvolvedores precisará aprovar a tradução e ela será enviada manualmente para o Github por ele próprio, com os devidos créditos de quem traduziu. Tela de metas: Será relacionada com o sistema de bugs e traduções, mas também haverão metas para os desenvolvedores. Essas metas serão pré-estabelecidas pelos administradores do projeto, podendo elas serem coisas como: "Criação de NPCs do episódio X do jogo". "Atualização de pacotes para novas versões do executável", etc. Tela de estatísticas: Conterá estatísticas gerais dos sistemas com informativos através de gráficos.
  8. Concluída a tela principal do CMS, agora faltam as telas de conteúdo. https://github.com/Protimus/brACD/commit/8497b214f4e9fe6a625dd0ec1f8b081628cb624e
  9. Tá ótimo, era bem nesse estilo que eu estava pensando. Pode me passar as imagens ou PSD?
  10. Eu pensei nisso, mas achei que não ficaria bom para o estilo de design. Acho que ficaria melhor inline caso não houvesse a coluna com informações do lado esquerdo, ficaria melhor usando a página toda para o formulário. Fique a vontade se quiser alterar para testar como fica, a gente decide qual usar juntos. Agora temos um controlador para os formulários de login. O botão de entrar só funciona após validação dos campos e existe uma segunda tela em javascript após o login que auxilia em uma "segunda validação". As mensagens de erro são exibidas abaixo dos inputs, caso não sejam devidamente preenchidas. https://github.com/Protimus/brACD/commit/a4e7ed30baada4512013f462dea7929bbb6fbc05 EDIT: Foi criada a página de cadastro. Além das informações como email e senha, é necessário informar uma data de nascimento como segundo atributo de verificação para resetar a senha em caso de perda e necessidade de recuperação. Tanto para a página de login como para a página de registro, ainda será adicionado o Recaptcha com Angular para validação do formulário. https://github.com/Protimus/brACD/commit/da2d8cf3e5a3525156affcad5eb853a630f65391
  11. A página de login foi adicionada em: https://github.com/Protimus/brACD/commit/9314255bed8365da2d081db80ac288088fede29b Essa é uma breve exposição de como ficou. Algumas coisas ainda precisam ser alteradas, além disso a escrita onde está a coluna com a logo é feita em javascript, por isso vocês não verão a imagem com animação. *não perderei tempo fazendo gif*
  12. Esse é um dos motivos para a demora, eu não quero liberar o projeto mal feito. Não adianta liberar algo mal programado, mesmo que em funcionamento... Para os usuários não faz diferença, mas para mim faz e acredito que para quem tem sabe o mínimo de programação também é.
  13. Vai dar no máximo uns 8MB as dependências do projeto, então é melhor por no pendrive do que queimar o CD... Nem é DVD ainda por cima, tecnologia ultrapassada. Hoje de tarde tratei pra vocês a tela do login e uma sample online.
  14. brACD - Central de Desenvovimento Olá, Há algum tempo atrás eu fiz um tópico com a ideia de refazer o antigo brACT (Centro de Traduções). Como o nosso projeto está com um desenvolvimento inferior ao que existia há anos atrás (muitos commits por dia), vejo a necessidade de revitalizar a estrutura de organização para dar inicio em uma nova etapa. A ideia principal do brACD é ser uma central onde seja possível enviar traduções, ter um status delas, enviar reports de bugs do emulador, dar prioridade os bugs e também organizar metas e tarefas para os desenvolvedores de modo público. Você poderá me perguntar o "porque não criar tarefas no Github?", a resposta é um pouco fora do padrão. Infelizmente a comunidade brasileira não está acostumada com um sistema diferente como o do Github, poucas pessoas ajudam ou tem coragem de fazer uma conta e entender como fazer um report, se perdem com a quantidade de opções que existem ou tem preguiça de achar. A ideia da central de desenvolvimento é ser algo simples, por isso ela pode ser mais efetiva do que qualquer sistema que já exista. As metas para desenvolvedores, torna aberto o nosso desenvolvimento e incentiva os membros a buscarem soluções em conjunto com os próprios desenvolvedores. A falta de auxilio aos projetos opensource muitas vezes ocorre devido os membros não saber nem por onde começar ou no que podem ajudar. Alguns se contentam com uma simples criação de tutorial, por não terem metas ou objetivos expostos. O sistema do brACD é um CMS feito em PHP, JavaScript, AngularJS, Bootstrap 4, utilizando novas tecnologias como Bower e Gulp. Qualquer um pode ajudar nele, eu estou deixando o repositório aberto ao público para que acompanhem o desenvolvimento: https://github.com/Protimus/brACD Dentro de 2 dias as telas de login e registro estarão concluídas e daremos inicio as telas do CMS (aplicação em si). Esse é apenas um dos passos para a revitalização do projeto, logo após daremos conclusão aos projetos já propostos: brACP, brAPatcher, brAEditor. Lembrando que qualquer ajuda é bem-vinda, seja ela em design ou em construção/melhoria de códigos. Att, Protimus.
  15. Estou dando um parecer, já que ninguém mais falou sobre o acontecido. Eu, o Roberto, Júlio, Tidus, Aly e Carlos (Raizen) conversamos a respeito de uma possível união durante 1 semana mais ou menos. Particularmente eu dei um dos passos iniciais e aderi a ideia, entretanto eu não vi muito motivo para simplesmente recriar a roda. Nós já temos um fórum em pleno funcionamento, uma skin exclusiva e um emulador que apesar de não ser como antes, ainda assim é utilizável e está em ótimo estado. Então eu pergunto: Porque ter o trabalho de fazer tudo isso de novo? Porque eu jogaria no lixo todo o FrontEnd de coisas que já estão prontas? Ainda assim eles conseguiram me convencer de criar uma comunidade do zero, pelo bem da comunidade brasileira em geral eu aceitei a ideia mesmo que isso fosse contra o senso lógico da questão. Depois de muita coisa discutida eu fiz algumas perguntas a respeito de planejamento, como seria a administração, quem seria a equipe e se qualquer um entraria na equipe, etapas de processo para o desenvolvimento. Porque é bom deixar tudo no papel para não haver futuros conflitos e estragar uma das maiores parcerias que seria feita... Entretanto eu não obtive mais respostas a partir do momento que fiz essas perguntas. Infelizmente alguns dias depois de debatermos bastante, o Roberto desistiu da união. Eu respeitei a opinião dele e quero deixar claro que NÃO há qualquer desavença da minha parte com ele ou com qualquer pessoa do Cronus. E pouco me importa quem ainda fala algo sobre mim ou tenta criticar de alguma forma... Se quer criticar ou brincar fique a vontade, mas também tenha competência e faça melhor do que eu já fiz nesses 10 anos ou simplesmente seja só mais um que só sabe falar e pouco fazer. Então é isso, continuaremos com o brAthena e em breve haverão novidades que alguns talvez se surpreendam um pouco. Toda essa história acabou me animando um pouco.