Lord Henry
-
Posts
4,006 -
Joined
-
Last visited
-
Days Won
184
Everything posted by Lord Henry
-
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
-
destinos = { [1] = {2801.3, -1088.4, 30}, -- table com todos os destinos em ordem. [2] = {1110, -966.67, 42}, [3] = {192.8, -1746.18, 3.5} } local Minicio4 = createMarker (1038, -1338, 12.8, "cylinder", 1, 16, 102, 231, 255) -- Cria o marker onde o player deve usar o comando. local veh = {} -- Cada elemento específico de cada jogador deve estar em uma table para ser criado e acessado corretamente. local Mfim4 = {} -- Marker final específico do player. local Bfim4 = {} -- Blip do marker final específico do player. function inicio4 (hitElement) if hitElement and getElementType (hitElement) == "player" and not getPedOccupiedVehicle (hitElement) then -- Quando o jogador colide no marker e está sem veículo, então: outputChatBox ("Digite /trampo4 para iniciar este emprego.", hitElement) -- Avisa pra ele usar o comando /trampo4 para começar o emprego. end end addEventHandler ("onMarkerHit", Minicio4, inicio4) function startJob4 (thePlayer, cmd) if isElementWithinMarker (thePlayer, Minicio4) and not getPedOccupiedVehicle (thePlayer) then -- Ao usar o comando, só funciona se o jogador estiver no marker e estiver sem veículo. if veh[thePlayer] and isElement (veh[thePlayer]) then -- Se por acaso existir o veículo do trampo do jogador, destroi ele. destroyElement (veh[thePlayer]) veh[thePlayer] = nil end veh[thePlayer] = createVehicle (498, 1009.5, -1355.2, 13.4) -- Cria o veículo do trampo. local x, y, z = unpack (destinos[1]) -- x, y, z recebem as coordenadas do destinos[1]. Mfim4[thePlayer] = createMarker (x, y, z, "cylinder", 2, 0, 255, 0, 255, thePlayer) -- Cria o marker do objetivo do jogador na coordenada 1. setElementData (Mfim4[thePlayer], "owner", thePlayer) -- Seta esse jogador como dono do marker, para que só funcione com ele. setElementData (Mfim4[thePlayer], "trip", 1) -- Seta uma data no marker pra saber a qual coordenada ele pertence. Bfim4[thePlayer] = createBlipAttachedTo (Mfim4[thePlayer], 19) -- Cria o blip e anexa ao marker. warpPedIntoVehicle (thePlayer, veh[thePlayer]) -- Teleporta o player para o veículo do trampo. outputChatBox ("Leve as rosquinhas até a bandeira no radar! (1/"..#destinos..")", thePlayer) -- Avisa o player o que ele tem que fazer agora. addEventHandler ("onMarkerHit", Mfim4[thePlayer], fim4) -- Adiciona o evento que faz funcionar o marker do objetivo. end end addCommandHandler ("trampo4", startJob4) function fim4 (hitElement) if (hitElement == getElementData (source, "owner")) then -- Se o elemento que colidiu for o dono do marker, então: if veh[hitElement] and isElement(veh[hitElement]) then -- Se existe o veículo do trampo do jogador, então: if (getElementData (source, "trip") < #destinos) then -- Se a data do marker é menor que a quantidade de destinos, então: (indicando que não é a última viagem) local x, y, z = unpack (destinos[getElementData (source, "trip") + 1]) -- x, y, z recebem a próxima coordenada da table destinos. setElementPosition (source, x, y, z) -- Coloca o marker de objetivo nessa nova coordenada. setElementData (source, "trip", getElementData (source, "trip") + 1) -- Seta a nova viagem nesse marker. outputChatBox ("Você entregou as rosquinhas no destino. Siga para o próximo. ("..getElementData (source, "trip").."/"..#destinos..")", hitElement) -- Avisa o jogador quantas viagens ele fez e quantas são no total, pra ele não pensar que está trabalhando de graça. else -- Se o marker de objetivo colidido não tem data menor que a quantidade de viagens, então: (indicando que esse é o último objetivo) removeEventHandler ("onMarkerHit", Mfim4[hitElement], fim4) -- Remove o evento que ativa este marker, pois ele não será mais usado. destroyElement (veh[hitElement]) -- Destroi o veículo do trampo do jogador. givePlayerMoney (hitElement, 2500) -- Dá o dinheiro do trampo. destroyElement (Bfim4[hitElement]) -- Destroi o blip anexado ao marker de objetivo. Bfim4[hitElement] = nil destroyElement (Mfim4[hitElement]) -- Destroi o marker de objetivo. Mfim4[hitElement] = nil outputChatBox ("Você entregou as rosquinhas a todos os destinos marcados e ganhou R$2500!", hitElement) -- Avisa o jogador que ele completou o trampo. end end end end function sair4 (thePlayer) if (veh[thePlayer]) and isElement(veh[thePlayer]) then -- Se o veículo do trampo existe, então: removeEventHandler ("onMarkerHit", Mfim4[thePlayer], fim4) -- Remove o evento que ativa o marker de objetivo. destroyElement (veh[thePlayer]) -- Destroi o veículo do trampo. destroyElement (Bfim4[thePlayer]) -- Destroi o blip de objetivo do trampo. Bfim4[thePlayer] = nil destroyElement (Mfim4[thePlayer]) -- Destroi o marker de objetivo do trampo. Mfim4[thePlayer] = nil outputChatBox ("Você saiu do veiculo e perdeu o trabalho!", thePlayer) -- Avisa o jogador que ele falhou no trampo. end end addEventHandler ("onVehicleExit", getRootElement(), sair4) -- Executa essa função quando o player sair de um veículo qualquer.
-
Ah, vc não quer fazer aleatório? Quer fazer sequência, é isso? E o player só recebe após completar a última entrega?
-
No caso de ser possível fazer várias entregas seguidas no mesmo emprego, eu primeiramente colocaria todas as coordenadas possíveis dos objetivos em uma table. Depois usaria um math.random para obter uma dessas coordenadas aleatoriamente. Exemplo de math.random: destinos = { [1] = {2060.7685546875, -1941.1181640625, 13.14103603363}, -- [int] = {x, y, z}, [2] = {2086.9731445313, -1571.7086181641, 13.38231754303}, [3] = {1922.9521484375, -1758.1259765625, 13.16081237793}, [4] = {1032.1564941406, -1552.7036132813, 13.545647621155}, [5] = {1133.2607421875, -1286.6201171875, 13.245727539063}, [6] = {1162.1402587891, -1717.9711914063, 13.945343971252}, [7] = {1249.0665283203, -2049.9089355469, 59.945289611816}, [8] = {825.31280517578, -1870.5678710938, 12.8671875}, [9] = {405.81915283203, -1778.1610107422, 5.5676455497742}, [10] = {438.53366088867, -1559.4774169922, 27.096113204956} } function testeRandom (thePlayer) local x, y, z = unpack (destinos[math.random (#destinos)]) -- x, y, z recebem uma coordenada aleatória da table destinos. setElementPosition (thePlayer, x, y, z, true) -- Coloca o player que executou o comando nessa coordenada, só pra testes. end addCommandHandler ("eae", testeRandom)
-
Se for de alguns em alguns segundos, sim, consumiria bastante.
