[M]ister

Para que serviria a consulta a cada x segundos ? Você pode manipular a database apenas no login do player (obter dados) e no loggout/quit (salvar dados). Sendo que in-game, após o login, você salvaria os dados em uma variável/ementdata e manipularia ela... e quando o player sair do servidor você seta esses novos dados na database.

Pelo que entendi um for pode dentro de um while, porém não o contrário ? Não existe qualquer impedimento quanto a isto, uma coisa é implementar um código incorreto gerando loop infinito, outra é dizer que em qualquer circunstância um while dentro do for geraria esse loop sem fim. A linguagem LUA assim como diversas outras é procedual e executa uma instrução por vez, sendo assim, não é possível a execução dos dois loops (while/for) ao mesmo tempo. No código acima ele roda o for (1x) e então começa a execução do while, e uma nova execução do for ocorreria só depois de ter finalizado o andamento do segundo loop(while). E caso o while entre em um loop infinito a segunda execução do for nunca chegaria. No while não é claro a quantidade de repetições e como já comentado ele é executada enquanto a condição de verificação for verdadeira, e por não ter um fim “claro” a lógica de saída (tornar a verificação falsa) do while deve ser sempre implementada em seu bloco (se não o fizer resultará em um loop infinito). O código que ele expôs está correto*, no while ele define a condição de saída do loop (tornando o elementdata-fome igual a zero) * Na realidade não está totalmente correto, mas o código dele é funcional. O while assim como qualquer outra estrutura de repetição deve ser usado apenas quando existe a necessidade ou possibilidade de re-executar o código mais de uma vez, sendo que ali no código usou-se um while que sempre rodará apenas uma vez, e nesse caso uma simples estrutura de condição “if” já satisfaz as necessidade. Abaixo uma adaptação do código para a necessidade de utilização do while: for index, p in ipairs(getElementsByType("player")) do local fome = getElementData(p, "fome") -- suponha que o valor seja -10 while fome < 0 do -- while seria executado 10 vezes fome = fome + 1 setElementData(p, "fome", fome) end end

Na realidade pode, só que você implementou ele de maneira incorreta kkk. Ali não existe necessidade de colocar um loop, um simples if já resolveria: for index, p in ipairs(getElementsByType("player")) do outputChatBox(tostring(getElementData(p, "fome"))) -- debug if getElementData(p, "fome") < 0 then setElementData(p, "fome", 0) end end Obs: Mesmo assim era para o seu código funcionar, provavelmente o elementdata não esteja setado corretamente.

O desenvolvimento em si não é difícil (conhecimento intermediário), o complicado é que precisa conhecer “bem” como funciona a plataforma do fórum que deseja integrar. Já vi vários tópicos sobre o IPBoard aqui no fórum, talvez seja um bom começo.

Também seria bom esclarecer melhor a ideia por trás desses “códigos” que representam as cores… RGB = Red Green Blue (Vermelho – Verde – Azul). Representam o conjunto de cores primárias aditivas (relacionadas com a incidência de luz sobre elas), cada cor é formada apartir de uma numeração que varia do 0 ao 255 (representando a intensidade daquela cor), sendo que quanto mais próximo do 0, mais escuro será, e quanto mais se aproximar do 255, mais intenso será aquela cor. Esse esquema de cores está meio que relacionado com as brincadeiras na nossa infância de misturar cores (com guache) e ver qual cor nova forma, ou seja, variando apenas a tonalidade do Vermelho, Verde e Azul podemos formar “todas” as outras cores: Ex: O conjunto das cores vermelho, verde e azul representam a cor branca (255, 255, 255) A ausência das três cores forma o preto (0, 0, 0) Vermelho com verde forma o amarelo (255, 255, 0) Vermelho com azul forma o roxo (255, 0, 255) Hex = Hexadecimal: sistema numérico formado por 16 dígitos (0123456789ABCDEF). O conjunto de 6 dígitos desse sistema numérico acrescido do símbolo ‘#’ no início forma o código de cor que é utilizado no outputChatBox. As cores hexadecimais podem ser relacionadas com as cores RGB da seguinte forma: - quanto mais próximo do 0, mais escuro e quanto ‘maior’ a letra, mais intenso - cada par de dígitos representam a tonalidade respectivamente das cores RGB. Exemplo: "#RRGGBB" (RR = Nível da tonalidade do red/vermelho, GG = green/verde, BB = blue/azul) - Os algorismos R-G-B não pertencem ao sistema hexadecimal, tornando essa cor inválida (usei apenas para exemplificar a posição relacionando-as com o sistema de cor RGB) ‘F’ é o maior digito hexadecimal, comparando o mesmo em RGB temos o valor 255, com isso podemos citar o seguinte: #FFFFFF (hex) = 255, 255, 255 (rgb) - branco #FF0000 = 255, 0, 0 - vermelho #00FF00 = 0, 255, 0 - verde #0000FF = 0, 0, 255 - azul * Mostrei aqui apenas com as tonalidades mínimas e máximas devido à facilidade de comparação/conversão entre RGB <=> Hex.. descobrir o código exato das demais cores “batendo o olho” como foi feito acima já não é mais tão simples, pois passam a exigir inclusive alguns cálculos matemáticos, para isso temos vários conversores de cores na internet (exemplo) Para quem se interessar: Conversão RGB para Hex Conversão Hex para RGB

Realmente não sei o porque da discussão kkkkk, ambos são totalmente diferentes, cada um abordou um tipo de database (padrão/personalizada)… apesar das querys serem iguais os métodos de utilização mudam. O que importa é que ambos contribuíram, cada um do seu jeito! Só alguns detalhes: O certo seria o tipo: TEXT e não TXT (Referência) Poderia ter comentado sobre dbPrepareString e dbFree que são fundamentais também. Deixo também alguns operadores muito utilizados: AND e OR LIKE LIMIT ORDER BY

local myMarker = createMarker(-2596.625, 579.358, 15.626, 'cylinder', 2.0, 255, 0, 0, 150) function MarkerHit( hitElement, matchingDimension ) if not matchingDimension then return end if getElementType( hitElement ) == "vehicle" then -- se o elemento que entrou no marker é um veículo local vida = getElementHealth (hitElement) if vida < 500 then fixVehicle(hitElement) end end end addEventHandler( "onMarkerHit", myMarker, MarkerHit )

countPlayersInTeam

Realmente essa questão da vida do fogo é algo a ser pensado, pois pelo meu comentário anterior provavelmente o fogo iria apagar rápido (logo que atirasse ia ser acionado o extinguishFire e então apagaria) não ia ter a "graça" de ficar com o extintor um certo tempo até apagar. Talvez definir que com x acertos do onClientPlayerWeaponFire reduziria o tamanho do fogo aos poucos, começa com createFire(x,y,z,10) e com o tempo vai decrementando... x == 10 createFire(x,y,z,10) extinguishFire(x,y,z,10) x == 20 createFire(x,y,z,9) extinguishFire(x,y,z,9)

Faz sentido, inclusive já meio que supos que isso ocorreria antes mesmo comentar (tô sem MTA, ai complica testes desse tipo) Basta ele salvar as posições (x,y,z) utilizadas no createFire() e então no evento onClientPlayerWeaponFire verificar se a posição que está "atirando" com o extintor coincide com as utilizadas no createFire() (seria bom utilizar alguma taxa de variação ( parâmetro size do createFire() ) em relação ao eixo central x,y,z na verificação, pois se não para apagar o fogo iria ter que mirar exatamente na coordenada x,y,z de criação do fogo) e então caso a verificação seja true usa o extinguishFire()

Ah sim. @danilin, você pode usar o evento: onClientPlayerWeaponFire identificando a arma (se igual a extintor) e obtendo a localização (x,y,z) do alvo e usando nos parâmetros do extinguishFire(x,y,z,radius) que então caso retorne true o fogo foi apagado.

extinguishFire()

Se não me engano, quando testa localmente ele não retorna a localização correta do jogador, faz o seguinte no painel do Admin, veja se ele mostra o seu país.

É, sla o que aconteceu então, de olho não vejo falha, talvez seja algum bug ou implementação incorreta do setWeaponProperty

function listarJogadores(thePlayer) local br, gringo = 0,0 for _,p in ipairs (getElementsByType ( "player" )) do local pais = call(getResourceFromName("admin"), "getPlayerCountry", p) if (pais == "BR") then br = br + 1 else gringo = gringo + 1 end end outputChatBox ( "Jogadores Brasileiros: #889123" .. br, thePlayer, 255, 255, 255, true ) outputChatBox ( "Jogadores Gringos: #889123" .. gringo, thePlayer, 255, 255, 255, true ) outputChatBox ( "Total: #889123" .. getPlayerCount(), thePlayer, 255, 255, 255, true ) end addCommandHandler("players", listarJogadores)

Estou sem MTA no momento o que impossibilita qualquer teste de minha parte, mas quando fiz não notei nenhum problema. Até porque não faz muito sentido, já que o reiniciar nada mais é que um stop e start no resource, chamando da mesma forma o evento: onResourceStart Se quiser realizar o teste com esse script para esclarecer essa dúvida, agradeceria também.

local armas = {22,23,24,25,26,27,28,29,30,31,32,33,34,38} local skills = {"pro","std","poor"} function setNoRecoil(tipo) for _,id in ipairs(armas) do for _,skill in ipairs(skills) do if (tipo == "ativar") then setWeaponProperty ( id, skill, "accuracy", 10000 ) elseif (tipo == "desativar") then local original = getOriginalWeaponProperty ( id, skill, "accuracy" ) setWeaponProperty ( id, skill, "accuracy", original ) end end end end addEventHandler( "onResourceStart", resourceRoot, function() setNoRecoil("ativar") end ) addEventHandler( "onResourceStop", resourceRoot, function() setNoRecoil("desativar") end )

É possível, só que seria exatamente o que o @Lord Henry comentou: usando startResource() / stopResource() irá afetar a todos no servidor.... Nas substituições apenas de .txd é só usar destroyElement() no elemento criado pelo engineLoadTXD() Ruas por imagem ? utilizam shader né ?... então seria utilizado o engineRemoveShaderFromWorldTexture()

1. Post na área errada; 2. Código sem formatação; function isPlayerOnGroupPj ( player ) local account = getPlayerAccount ( player ) local inGroup = false for _, group in ipairs ( { "Everyone", } ) do if isObjectInACLGroup ( "user.".. getAccountName ( account ), aclGetGroup ( group ) ) then inGroup = true break end end return inGroup end

Uma maneira de funcionar da maneira que você falou (ativar/desativar os scripts de um resource apenas para o jogador que acionou o comando) é 1. Ler o arquivo meta.xml do resource especificado; 2. Identificar os scripts (.lua) e arquivos (dff/txd/col) percorrendo o xml; 3. Carregar os scripts com loadstring() no lado cliente (necessário ler no lado server e depois transferir); 4. Ler no lado server e transferir para o lado cliente os arquivos (dff/txd/col) e então salva-los; 5. Identificar os modelos substituídos para então retorna-lo ao estado original quando desejado (sobrescrevendo funções do tipo: engineReplaceModel() para conseguir armazenar o ID substituído). Para funcionar o exemplo acima, é necessário que os resources não sejam ativados (apenas deve manter ON o script responsável pela leitura dos resources)! O mais inviável seria o passo (4), talvez adaptar os resources, mudando no meta.xml as tags <script> por <file> dos arquivos .lua e então ativar os resources normalmente, para então baixar os mods (mas não trabalhar os scripts) seria uma boa... Falei o mais simplificado possível, e é necessário um conhecimento intermediário / avançado para construir algo do tipo! Vá por mim, procure outros métodos, e tente utilizar em apenas um resources, unindo todos seus mods de veículos/texturas e etc. Será bem mais fácil fazer o que você quer (desativar/ativar mods)

Boa! Irei tentar acompanhar lá também (tomara que não lhe ignorem kk)

Acho que até com XML envolvido não tenha problema, pois via scripting essas entidades são tratadas como "string": getElementsByType ( "vehicle" ) Enfim, talvez até tenha um motivo maior, mas como você mesmo disse, já se tornou um "vício de programação" para mim kkkk, dificilmente vou abandonar o uso desses nomes em variáveis

Eu não creio que as palavras (player, vehicle, object, pickup, marker, blip...) sejam palavras reservadas! Se fossem, qual é a utilidade/funcionalidade delas ? eu não consigo pensar em nenhuma, possivelmente a coloração "diferente" que é definida no editor de texto do fórum seja para destacar tais "tipos" de elementos/entidades. Talvez essas palavras pudessem ser objetos na programação orientada a objeto, mas dei uma olhada e a nomenclatura deles começam com letra maiúscula, sendo assim, Vehicle é diferente de vehicle Vehicle.create(411, 0, 0, 3) -- ok vehicle.create(411, 0, 0, 3) -- fail Por favor, me esclareça se eu estiver errado, pois sempre fui acostumado a usar essas palavras...

Segue exemplo: local x,y,z = 0,0,0 --- coloque a posição do pickup aqui local dinheiroPorSegundos = 1 local tempo = getRealTime().timestamp local pickup = createPickup(x, y, z, 3, 1274, 1000) local playerPickup = {} addEventHandler("onPickupHit", pickup, function(player) playerPickup[player] = true outputChatBox("*Digite /pegar para obter os $"..obterDinheiroPickup().." acumulados neste local",player) end ) addEventHandler( "onPickupLeave", pickup, function(player) if playerPickup[player] then playerPickup[player] = nil end end ) addEventHandler ( "onPlayerQuit", root, function() if playerPickup[source] then playerPickup[source] = nil end end ) addCommandHandler("pegar", function(player) if playerPickup[player] then givePlayerMoney(player,obterDinheiroPickup()) tempo = getRealTime().timestamp end end ) function obterDinheiroPickup() return (getRealTime().timestamp - tempo)*dinheiroPorSegundos end A cada segundo o pickup acumula + 1$ e quando alguém pega o dinheiro esse valor é zerado e continua acumulando novamente... Ficaria bem mais minimizado o código se fosse utilizado onPickupUse no lugar do comando para pegar o dinheiro do pickup.

Qual a dúvida ? ainda deixamos comentários explicando suas funcionalidades... Basicamente estávamos tentando reinventar a roda... o MTA já dispõe de funções nativas que suprem as necessidade de respawnar veículo quando o player abandona ou explodi o veículo, não necessitando que criemos funções anexadas a eventos: local carro = createVehicle (411, 2475, -1657, 14, 0, 0, 0) toggleVehicleRespawn(carro,true) -- DIFINE QUE O VEÍCULO ESTÁ SUJEITO ÀS FUNÇÕES DE RESPAWN (setVehicleIdleRespawnDelay E setVehicleRespawnDelay) -- ISSO: setVehicleIdleRespawnDelay(carro,10000) -- É IGUAL A ISSO: function saiu(player) setTimer(respawnVehicle,10000,1,source) end addEventHandler ("onVehicleExit", carro, saiu) -- ISSO: setVehicleRespawnDelay(carro,5000) -- É IGUAL A ISSO: function explodiu() setTimer(respawnVehicle,5000,1,source) end addEventHandler("onVehicleExplode", carro, explodiu) *Foi apenas um exemplo lógico, certamente o código fonte das funções setVehicleIdleRespawnDelay/setVehicleRespawnDelay é mais complexo