Leaderboard

marker = createMarker(2169.62500, -1983.23706, 13.55469, "cylinder", 1) vehicles = {} addEventHandler("onMarkerHit", marker, function(player) vehicles[player] = createVehicle(408, 2169.62500 + 3, -1983.23706, 13.55469) end) addEventHandler("onPlayerQuit", root, function(type) if (type == "Quit") then destroyElement(vehicles[source]) --change player to source end end)

Well remove player argument from the function on the Event ,,onClientRender' just function() and on getElementData replace player with localPlayer Also onClientRender will output something/ refresh every second if i remember, so until the data is not true then it wont output only false.

The best way to sync fire is the same way you'd sync most things, and there are two options: the server creates fire and distributes information about it to clients, or clients create fire and inform the server, which then broadcasts the information to the other clients. The second option is basically a slightly expanded version of the first, so I'll outline how the first could work: Server runs a resource responsible for synchronizing fires between players. This resource has an exported function or custom event Security point: Don't allow remote trigger for custom events unless necessary, keep it server-triggered to prevent untrusted clients from being able to triggerServerEvent and spam the server with unauthorized fire; or, allow remote trigger but add logic to prevent unruly clients from being able to spawn fire where ever they want. When the exported function is called, or the custom event triggered, the server adds to its table of existing fires certain data about the fire, including position, interior, dimension, size, maximum duration and timestamp or tickcount when spawned, and triggers a client event for all players: onReceiveSyncedFireData (or whatever you choose to name it) and sends this data through Each client handles this event, and calls createFire on the client, along with timers to delete the fire when the current timestamp/tickcount exceeds the spawn timestamp/tickcount plus duration If a tickcount is used, it's best if the client at this point determines their tickcount offset from the server's, and uses its own tickcount plus/minus server offset for further calculations. A new client joining should request existing fires by triggering on the server an event onRequestSyncedFireData (or whatever you choose to name it) The server handles this event by triggering on the new client the previously mentioned receive event for each fire in the server's fires table. This client handles the receive events the exactly the same as if the fires were newly spawned. If your scripts move fires around, you may add events that allow clients to make updates, in a similar way to the above but information flowing from the client to the server, and then broadcast down to the other clients Security point: ideally check that only the element syncer is allowed to make changes to a fire, to prevent cheaters from tampering with fires they're nowhere near

for theKey,peds in ipairs(ped) do if ped and isElement(peds) and isElementStreamedIn(peds) then local Zx,Zy,Zz = getElementPosition(peds) zedSound = playSound3D(zombiesounds[math.random(1,#zombiesounds)], Zx, Zy, Zz, false) zedSound variable is overwritten for every ped. This means you're creating new sounds but discarding the pointer/reference/element handle for the old one. The old one will thus remain playing and you have no way* to delete it. What you need instead is a table of sounds you've spawned, and when you call stopSound, you should call it once per sound element in that table. This should stop all the sounds you've created. Example: -- when creating spawnedSounds = {} for theKey,peds in ipairs(ped) do if ped and isElement(peds) and isElementStreamedIn(peds) then local Zx,Zy,Zz = getElementPosition(peds) zedSound = playSound3D(zombiesounds[math.random(1,#zombiesounds)], Zx, Zy, Zz, false) -- do whatever with zedSound spawnedSounds[ped] = zedSound -- store the zedSound into a table for later when calling stopSound -- when stopping for theKey,theSound in pairs(spawnedSounds) do -- go through each sound in the table (note the use of pairs is -- essential if the keys of the table are not numerical and sequential: in this case they are elements so pairs, is needed) -- (also NB: some performance comparisons point out pairs is faster than ipairs even with sequential numeric tables -- so you can just blindly always use pairs instead of ipairs without performance impact) stopSound(theSound) -- stop the sound that is stored as the value of a key=value pair in each row of the table end * You can still recover the pointer/reference/element handle though functions like getElementsByType for sound type but its going to be much harder to identify which one you want.