Lord Henry
-
Posts
4,010 -
Joined
-
Last visited
-
Days Won
184
Everything posted by Lord Henry
-
Verifique se o jogador que colidiu no marker está em um veículo usando a função getPlayerOccupiedVehicle. Se estiver, a função não deve funcionar.
-
Só pra avisar que esse código é server-side. E também faltou o último parâmetro true no seu outputChatBox.
-
Na verdade é apenas pra evitar que a bike nasça dentro do jogador.
-
bike1 = {} function aluga1 (source) local x, y, z = getElementPosition (source) bike1[source] = createVehicle (481, x, y, z + 1) takePlayerMoney (source, 50) end addCommandHandler ("alugar", aluga1) function des1 (source) if isElement (bike1[source]) then destroyElement (bike1[source]) bike1[source] = nil givePlayerMoney (source, 10) outputChatBox ("meu texto", source, r, g, b, true) -- substitua os valores r, g, b. end end addCommandHandler ("desalugar", des1) É mais vantagem deixar o veículo em uma table, para que mais de um jogador possa usar ao mesmo tempo.
-
Não tenho certeza, mas creio que dentro da função do timer, source não existe.
-
destroyElement (bike1) bike1 = nil
-
Aparece alguma mensagem de erro no /debugscript 3?
-
Rapaz, isso é relativamente complexo de ser feito. E vai precisar de setAccountData também.
-
Quando o player inicia o trabalho, é criado um marker com esse player. Logo, se não existir o marker com esse player, significa que ele não está no emprego, pois quando o emprego é cancelado ou concluído, o marker é destruído. O marker com esse player só vai existir enquanto ele estiver no emprego.
-
Você disse que tentou fazer algo, mas está dando erro. Cadê o código pra gente verificar o erro? Qual erro que aparece no /debugscript 3?
-
Se a pessoa não estiver no emprego, não vai existir o Mfim3[source] e então o output não irá aparecer pra ela.
-
Impressão minha ou essa table da linha 56 não existe? vehicleDataTable
-
function kill3 () if isElement(Bfim3[source]) then destroyElement (Bfim3[source]) end if isElement(Mfim3[source]) then destroyElement (Mfim3[source]) outputChatBox ("Você perdeu o emprego porque morreu.", source) end if isElement(veh[source]) then destroyElement(veh[source]) end Bfim3[source] = nil Mfim3[source] = nil veh[source] = nil end addEventHandler("onPlayerWasted", getRootElement(), kill3)
-
O output era só pra testes. Deixe sem o output mesmo. E ele está executando sempre pois o evento funciona quando qualquer um morre.
-
É que meu objetivo era fazer uma série de tutoriais no YouTube, mas não tenho tempo suficiente pra isso.
-
é
-
Não cara. Só usar /kill pra se matar e testar. (se estiver usando Freeroam)
-
Você poderia testar isso colocando um output na função de sair do veículo e então dando /kill no emprego pra ver se aparece o output no chat.
-
Pensei em falar sobre as mensagens privadas, mas alguns iriam ficar muito chateados comigo, pois fazem isso direto.
-
Seasparrow (447).
-
Usando onPlayerQuit.
-
Não sei se é mais seguro. Mas precisa de mais comandos para fazer a troca de dados. No MySQL vc precisa de um comando para iniciar a conexão com o banco de dados, e depois um comando para fazer as alterações. Já no SQLite você só envia e recebe os dados direto, sem necessidade de solicitar conexão. -
Olha... eu não iria comentar nada, mesmo sabendo que já é o terceiro post dele criticando sobre postar códigos prontos, mas como o próprio autor deste tópico entrou no assunto, acho válido deixar minha sincera opinião, bom vamos lá. Eu entendo a crítica dele e concordo em partes. Quando vc posta o código pronto, vc desestimula o cara a pesquisar por conta própria, pois é só o cara dar Ctrl+C e Ctrl+V e o problema está resolvido. No entanto eu observo os usuários do fórum para ver quem está tentando e quem só está copiando código. Posso contar nos dedos quantos usuários realmente estão tentando aprender. Eu posto o código comentado e estimulo os outros a comentarem seus códigos pois quando vc comenta seu próprio código em cada linha, vc sabe exatamente como ele funciona e você não se perde, pois é muito mais fácil de estudar um código funcionando diretamente com o que ele estava tentando fazer do que estudar uma sintaxe e sair chutando os valores. No caso de usuários novos, eu só posto código se ele já vem com uma parte feita, e que claramente não foi baixado da internet, caso contrário eu só indico links por onde ele pode começar, pois não vejo motivos pra começar por ele. Eu entendo que a maioria do pessoal aqui não é fluente no inglês (o que é um grande obstáculo, pois tudo na informática é em inglês) e por esse motivo possuem muita dificuldade com a Wiki. Mas isso não significa que ela seja descartável, aliás muito pelo contrário, pois ela explica o que cada função faz. Nas minhas respostas eu tento sempre manter as funções linkadas em suas páginas da Wiki, para estimular o usuário a clicar e descobrir por si mesmo como ela funciona. É claro que todos nós preferimos os autodidatas, que saem buscando na Wiki, testando as coisas, errando, consertando e aprendendo. Porém existem coisas que não se aprendem em documentações, como por exemplo as boas práticas de programação. Eu por exemplo fico incomodado quando vejo um parâmetro de função declarado como source, pois isso remove o source original da função. É uma coisa besta, mas me incomoda. Outra coisa que me irrita muito é código não indentado. Na maioria das vezes me recuso ativamente a ler o código enquanto ele não estiver indentado. Mas devo lembrá-los, que estamos em uma comunidade, e para isso devemos nos ajudar e não nos explorar e nem nos atacar. Se fosse pra mandar só links, seria mais fácil ir direto no google em vez de perder tempo criando um tópico. Já me estressei algumas vezes com varios usuários deste fórum, o que considero falha minha, pois eu deveria ser sempre neutro. Nem todos os novatos sabem lidar com as críticas, e nem todos os experts sabem criticar sem ser de maneira agressiva. A questão é: Qual será sua resposta quanto a isso? Ela será construtiva? Ela é necessária? Ela ajuda alguém? A discussão vale a pena? É tudo questão de bom senso e auto-controle. Aprender nem sempre é fácil, mas ensinar também não é. Eis meu desabafo.
-
Bom, sou sub-dono e desenvolvedor de um servidor que já bateu 200 players e posso afirmar que se for dar save em todo mundo, vai dar um freeze bem considerável no servidor. É por isso que a maioria dos sistemas de save account funcionam somente ao logar na conta (recebe os dados do banco de dados) e ao sair do servidor/deslogar/perder conexão/quitar do MTA (salvar os dados no banco de dados). No caso, quando é feito assim, não causa lag pois não são feitos tantos acessos simultâneos ao banco de dados. O que causa o lag é justamente a quantidade de acessos que são feitos ao mesmo tempo, pois a quantidade de dados pendentes na sincronização é muito maior do que quando é feito um por um em momentos diferentes. Imagine que o acesso ao banco de dados é um cara levando uma caixa. Você acha que é mais fácil ele fazer 1 única viagem com várias caixas ao mesmo tempo? Ou é mais fácil ele fazer cada viagem com 1 caixa? Se for 1 jogador, o consumo seria insignificante. Pouca quantidade de dados a ser processada ao mesmo tempo. Daria no mesmo.
-
Agora é botar a mão na massa e fazer os paranauê mano. Sim, já vai do [1] ao [3], pois está somando +1 a cada vez que ele entrega em um lugar. O like, por exemplo. XD
