Jump to content

Stanley Sathler

MTA Contributors
  • Posts

    563
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Stanley Sathler

  1. Respondendo diretamente à sua pergunta: qual a diferença entre usar no começo e no final? Absolutamente nenhuma. Quando você usa, em qualquer linguagem, function() codigo_da_funcao end (respeitando a sintaxe de cada linguagem, claro), isto é, uma função sem nome, chamamos-a de função anônima. Geralmente usamos function NomeFuncao(), certo? function() end é uma função anônima, uma função sem nome. Funções anônimas são usadas quando você usa o addEventHandler() no começo. Só existe diferença entre as duas se você quer vincular uma função à mais de um evento (quando um jogador se cadastra e quando um jogador morre, por exemplo, chamar a função que spawna o player e lhe dá algumas armas). Usando função anônima, você precisaria reescrever a MESMA função duas vezes: uma para cada evento. Usando função comum, nomeada, você simplesmente chama o nome da função nos dois eventos.
  2. O único objetivo do setElementData() é garantir que esse pickup é um pickup de dinheiro. No seu caso, poderia simplesmente checar se o modelo do pickup é 1212 (dinheiro). Como cada caso é um caso, podem existir servidores que usem um pickup do modelo 1212 com o mesmo objetivo que você. Porém, use também o mesmo pickup (de dinheiro) para outros casos... as vezes pra montar um interior de um banco, enfim, diversas situações. Se esse setElementData() não existir, toda vez que um jogador passar por cima de uma pickup de modelo 1212, a condição será chamada. Isso só faz com que aquele pickup seja um pickup específico para essa função de dar o dinheiro para quem pegar.
  3. Exato, Felipe. Tem a mesma função que a gambiarrinha que fizemos ontem.
  4. Adisson, pode postar seu código? Verifiquei o meu e este está exatamente igual ao do Roots, somente com os valores numéricos alterados. Quero ler seu código porque pode acontecer de você ter definido playSound3D() em um IF e, no ELSE, somente setado a distância máxima. Como eu disse, o local define o escopo ao qual a variável existe. Ou seja, o som precisaria ser criado antes da condição ou dentro de cada uma (indubitavelmente preferível a primeira opção, de declarar antes da condição).
  5. Trabalhar com elementos gráficos na tela é realmente mais complexo. Puramente matemático. Você precisa pegar o tamanho da tela do jogador e, a partir daí, fazer cálculos para centralizar na tela, por exemplo. A função para pegar o tamanho da tela é guiGetScreenSize(). Ela retorna a largura e altura da tela daquele usuário. Imagens nem sempre terão aquele aspecto bonito. E o motivo é simples: se eu jogar em modo fullscreen com a resolução 1024x860, em um monitor de resolução 1440x900 (19 polegadas), o jogo simplesmente vai aumentar o tamanho dos pixels. Afinal, vai ter que preencher uma tela de 1440x900 com apenas 1024x800 pixels. Aí é inevitável.... sai feinha mesmo.
  6. Roots, o código que você postou resolve de fato o problema. Mas não pelo true, e sim pelo fato de que você usou o mesmo sistema: armazenou, em sound, o retorno de playSound3D(), e não de setSoundMaxDistance(). Já o Adisson armazenava em sound o retorno de setSoundMaxDistance(). O true na verdade é só um argumento opcional. Inclusive, como ele quer alterar o som dos disparos, acredito que ele prefira com false (ou sem nada, já que false é padrão).
  7. O problema não é a existência das variáveis duplicadas porque, com o uso do local, informa-se que aquela variável só existe dentro do escopo atual que, no caso, é o if ou else. Ou seja, o primeiro sound só existe dentro do if e, o segundo, só existe dentro do else. Maiores informações sobre variáveis locais e globais podem ser encontradas aqui. Quando usamos variavel = funcaoQualquer(), armazenamos o retorno que funcaoQualquer() possui. No código atual, a variável está armazenando não o retorno de playSound3D, que é responsável por retornar um elemento do tipo som. Ela está armazenando o retorno de setSoundMaxDistance(), que retorna simplesmente um true ou false indicando se a distância foi ou não alterada. -- Primeiro crie o som em si local sound = playSound3D("soundweapons/winchester.wav",muzzleX, muzzleY, muzzleZ) -- agora sound é o som em si -- Definimos a distancia maxima setSoundMaxDistance(sound, 150) --retorna true ou false, mas como nao é relevante, nao armazenamos em variavel nenhuma -- Define o volume. Funciona porque sound agora não é true ou false, mas o som em si setSoundVolume(sound, 100) Deu para sacar o que eu quis dizer? Sua variável sound não era o som em si, mas sim um valor booleano. Aí quando você usava setSoundVolume, você não passa o som, mas sim um valor booleano.
  8. Roots, há uma diferença discrepante entre ser um programador com vários resources e ser um moderador apto a atuar como tal. Já parou pra perceber que em todo tópico você se desentende com alguém? Hoje peguei você dando "up" em tópico, cara. Acha que são estas as atitudes que um moderador deve ter? Continuo dizendo: ainda não te acho maduro o suficiente para assumir tal posição. E, inclusive, espero não estar incluído nos que "falam por trás", porque quando discordo, eu falo sem medo, tal como estou fazendo neste exato momento, tal como fiz nos meus posts anteriores. Se formos atribuir capacidade administrativa à capacidade de desenvolvimento em Lua, você continuaria perdendo. Existem dezenas de programadores aqui na comunidade que podem não ter vários resources espalhados por aí, mas são excelentes programadores. Num fórum, interação não é responsabilidade da moderação. Interação é responsabilidade de toda a comunidade. O papel do moderador não é responder a todos os tópicos, resolver todas as dúvidas de todos os membros que surgirem. Isso é papel de nós, simples membros. O papel do moderador é administrar a comunidade. Imagina você, moderador, discutindo em todo tópico onde exista alguém que discorde de você, tal como tem feito. Feio, né? Não só para você, como para toda a nossa comunidade. Então, para ter meu apoio, você já deveria começar a resolver esse grande problema que você tem apresentado nos últimos tempos. Não acho que você esteja preparado ainda. É simples assim. Se te ofende, cabe a mim me desculpar, visto que não é minha intenção. Mas é minha opinião.
  9. #Roots, gosto muito de você como pessoa. Mas acredito que você esteja, ultimamente, forçando muito a barra para adquirir uma posição aqui no fórum. E não creio que você esteja preparado para assumir um cargo de moderador. Não ainda. Já vi você fazendo spam e, em todo tópico, vejo você discutindo com alguém. Ser moderador vai muito além de presença constante. É respeito ao próximo, independente da situação. É conhecer as regras. É fazer as coisas pela comunidade por amor, não por interesse numa posição. Volto a dizer: não força a barra, cara. Nós não somos bobos. Do nada um cara surge com um tópico e, em seguida, uma enxurrada de membros que nem nunca vimos elogiando também.... é claro que tem dedo seu nessa jogada. E isso não te traz admiração. Pelo menos não de mim. Tem trazido é repulsa. Relaxa.... tudo tem seu tempo. A comunidade nem carente de moderação está, não há porque incluir ou alterar a equipe.
  10. Porra, todo santo tópico tem que ter uma briguinha? Pelo amor de Deus! Anyway, pra ser sincero, nunca tinha nem ouvido falar que RGBA também possuía a denominação 'Java'. E olha que sou desenvolvedor Web há anos. No mais, post bacana. Mas também acho que pode dar uma aprofundada legal. Pode, por exemplo, usar algumas imagens para exemplificar o uso das coordenadas X e Y na tela, já que o foco são os iniciantes.
  11. Sendo bem sincero: achei muito estranho surgir tanta gente que eu nunca nem vi aqui no fórum, em um horário "seguido" (ou seja, em intervalos de 1 hora, mais ou menos). Esse tópico foi postado em algum outro lugar solicitando um "voto público"? Enfim, Banex e DNL já comentaram o que havia de ser. Com absoluta certeza tem sido um excelente trabalho. Mas excelente trabalho muitos têm feito também. Um exemplo é o RaceXtreme que, apesar de sumido, contribuiu grandiosamente para a comunidade brasileira/portuguesa. Calma. Cada coisa na vida da gente tem o seu tempo. Tentar forçar só trará repulsa. E caso alguém pergunte sobre o meu status, sou Past MTA Contributor porque sou ex-moderador. Provavelmente o DNL, se um dia renunciar, receberá o mesmo título.
  12. Felipe, de forma alguma usar tabelas não é recomendado. Só apresentei outra alternativa. Há diferenças sim, mas em um nível mais aprofundado referente ao gerenciamento de memória. Totalmente insignificante neste caso. Quanto ao tráfico, ele é gerado justamente quando fazemos, efetivamente, a sincronização. Tanto que a própria Wiki aconselha usarmos lançadores de eventos ao invés de utilizar element datas para este tipo de sincronia. No caso do código em questão, não trata-se de sincronização.
  13. Você conhece a função setElementData()? É como se fosse um banco de dados temporário com três colunas: elemento, chave e valor. Quando o usuário digitar /explosivo, você pode usar setElementData(thePlayer, "hasExplosive", true), indicando que aquele usuário acaba de criar um explosivo e, portanto, a partir de agora já tem um criado. Quando quiser checar se ele já tem um explosivo criado ou não, você usa getElementData(thePlayer, "hasExplosive"), que simplesmente retorna o valor (neste caso, true ou false). Você pode simplesmente definir qualquer valor com o setElementData(). Um valor booleano, uma string, um inteiro... qualquer valor. Só a chave (segundo argumento) é que precisa ser única, para não causar conflitos. Não vejo problema nenhum em usar element datas com um script pequeno, principalmente porque são destruídos quando o usuário se desconecta.
  14. Pensei na mesma solução apresentada pelo Banex. Mas o modo Freeroam, além da janela principal, não possui alguns comandos? Eu não tenho certeza disso, mas se houver, a solução acima ainda é ineficaz para a execução destes comandos. A menos que você verifique a dimensão à cada addCommandHandler() que chame uma função especial.
  15. Pedro, me refiro ao código completo do arquivo. Estas poucas linhas simplesmente não ajudam em nada.
  16. Acabei de refatorar o começo do antigo arquivo survivorSystem_client. Dêem uma olhada na diferença. Velho | Novo
  17. Pedro, poderia postar os códigos? Se sim, não poste-os aqui, mas sim no Pastebin. Facilita a leitura.
  18. Pedro, porém, em contrapartida, elementos GUIs só funcionam se desenvolvidos no lado cliente. Logo, o código que desenvolve o Debug Monitor (a interface em si) e a função getPlayerCount() não podem estar no mesmo arquivo.
  19. MrBugsFive, de cara já pude ver que você tem um problema com o getPlayersOnline. Quando usamos esse tipo de comando sem parênteses, estamos nos referindo à uma variável. Com parênteses, à uma função. Geralmente, comandos com prefixo get e set são funções. Logo, presumo que getPlayersOnline() seja uma função e deveria possuir os parênteses. No entanto, isso não é o suficiente para funcionar. getPlayersOnline() deve estar ligado à uma função no server-side, porque getPlayersCount() (função nativa do MTA para pegar o número de jogadores conectados) funciona apenas no lado servidor.
  20. MrBugsFive, não se preocupe. Passa longe dessas porcarias que alguns brasileiros costumam fazer (convenhamos: a gente tem tendência à aplicar mod em absolutamente tudo). E como o Chico falou, uma coisa boa é os interiores que estão todos mapeados na mesma dimensão, sem os tradicionais "teleports" nas "setinhas amarelas".
  21. Passando apenas para dar meu feedback: o pouco que joguei hoje agradou bastante. Pessoal super prestativo. O que perguntamos, eles respondem com paciência e educação. Para quem gosta de RPG, a hora de aproveitar é agora, porque o servidor não é tão cheio e ainda há muitas coisas boas para comprar (exemplo: casas). Gostei bastante do servidor.
  22. Sim, MrBugsFive. Infelizmente ser programador é passar por isso. Foi por isso que decidi me render ao estresse e começar a liberar tudo que desenvolvo. Vão roubar de qualquer jeito mesmo....
  23. #RooTs, também tenho pretensão de criá-los. Talvez pudesse me ajudar quando eu der início à estas etapas. FelipeMallmann, não sabia da história. E concordo plenamente com sua opinião sobre a MtaZ: são muitas pessoas com pouquíssimos saberes. Roubam e, quando criam algo, criam com N gambiarras. Quanto à sua pergunta, francamente, acho sim. Porém, com um código aberto, possivelmente podem surgir participações de programadores mais experientes como, por exemplo, os daqui da comunidade que, quando vêem que é o script roubado, não ajudam. Talvez com um novo código e um projeto Open Source eles se disponham a ajudar no desenvolvimento. Mas infelizmente, vão continuar surgindo pessoas sem qualquer conhecimento que pegam um script pronto e rodam como se fossem seus. Vão continuar surgindo pessoas que vão criar seus próprios scripts privados. Vão continuar surgindo pessoas que consideram um servidor de DayZ como uma empresa, vendendo até o ar que respiram. Mas ao menos o código não será roubado da forma injusta como foi. Prévia das mudanças No momento estou trabalhando em toda a reorganização dos nomes e propriedades de cada item como, por exemplo, nome, id, slots ocupados, dano causado (no caso de armas), etc. Tudo em um único arquivo, porque se algo for mudado, você só precisa mudar em um único lugar e não se preocupar com mais nada. http://pastebin.com/F1BWBuNq
  24. Pessoal, agradeço de coração pelas mensagens! O objetivo é de fato tornar o código Open Source. Porém, como é imoral utilizar o código descompilado do atual DayZ, que foi liberado sem a aprovação dos autores originais, precisarei refatorar, tornando-o independente. Até porque o código tem muito que pode ser melhorado. É praticamente criar um novo DayZ do zero, porém com as mesmas regras de negócio.
×
×
  • Create New...