IIYAMA

It would be very unsafe, if that was possible.

And after the movement you should put the cursor back in the middle.

Lol, you created a tree generator too. (at your Youtube channel) Click (sorry for going off topic, I was just surprised)

First try it yourself.

np.

What about making them cooperate? 1 script checks if the other is running. (the one who doesn't mute, checks the one who mutes) If it is running, you start using export functions or a custom event. If not running, use the normal event.

Problem: The client hasn't loaded the script before the server is sending him a trigger. Solution: "onClientResourceStart"(resourceRoot) > triggerServerEvent > triggerClientEvent > openpanel

Well if you wanted to know that: local player = getRandomPlayer () --test 1 -- local timeNow = getTickCount() function setMoney1() local playermoney = getPlayerMoney ( player ) setPlayerMoney(player,playermoney) end for i=1,100000 do setMoney1() -- call the function end outputChatBox(getTickCount()-timeNow .. " ms (with variable)") ------------ -- test 2 -- local timeNow = getTickCount() function setMoney2() setPlayerMoney(player,getPlayerMoney ( player )) end for i=1,100000 do setMoney2() -- call the function end outputChatBox(getTickCount()-timeNow .. " ms (without variable)") ------------

Question 1 -- client triggerServerEvent("Test",resourceRoot) -- does work. triggerServerEvent("Test", localPlayer) -- doesn't work. -- server addEvent("Test", true) addEventHandler("Test", resourceRoot, -- element which which can execute this event. lol -- function ) -- client triggerServerEvent("Test",resourceRoot) -- does work. triggerServerEvent("Test", localPlayer) -- does work. -- server addEvent("Test", true) addEventHandler("Test", root, -- element which which can execute this event. lol -- function ) Like you attach a single gui button to the event onClientGUIClick. Question 2 The event will not be triggered afaik, but I never tried it because I never needed that. See it as an enable and disable switch.

Lol, that is exacly the definition of stupid behaviour.

@Feche1320 Because preventing is better then fixing. If you disagree with that, then you are just stupid. @Chaos --(serverside) -- request positions x,y,z near the player triggerClientEvent(targetPlayer,"event",resourceRoot,x,y,z -- --(clientside) addEvent("event",true) addEventHandler("event",root, function(x,y,z) --... -- check the position testLineAgainstWater processLineOfSight -- if the position fails use a random positions near that point math.random() -- and check again until you find a right spot. Use a loop. testLineAgainstWater processLineOfSight -- if you found a point successfully, send it back to serverside so it can make a new zombie. triggerServerEvent("event2",localPlayer,x,y,z) -- if you didn't find a point, let the server know that there aren't spawn points. triggerServerEvent("event2",localPlayer,false)

You can't destroy serverside peds, clientside. and use this before you spawn the ped, not when you already created it.

Clientside checks are more reliable, you should use clients to find the spawn-positions. Those functions come in handy. https://wiki.multitheftauto.com/wiki/Te ... ainstWater https://wiki.multitheftauto.com/wiki/ProcessLineOfSight It is more work, but it will use less network traffic because the zombies don't become useless when they spawn. "Spawning them underwater will require the network from all players, while a simply secure check will only use 1 client." @ .:HyPeX:. Peds never have names.

If you have the id, you also have the name = MAP EDITOR super OMG!!!

Well very simple: local peds = getElementsByType("ped") local pedPositions = {} for i=1,#peds do local ped = peds[i] local x,y,z = getElementPosition(ped) pedPositions[#pedPositions+1] = { ["element"]=ped, ["x"]=x, ["y"]=y, ["z"]=z } end addEventHandler("onClientRender",root, function () for i=#pedPositions,1,-1 do -- infers loop for using table.remove. local pedData = pedPositions[i] local ped = pedData["element"] if isElement(ped) then setElementPosition( ped, pedData["x"], pedData["y"], pedData["z"], false -- don't interrupt the animation = false ) else table.remove(pedPositions,i) end end end)

Well John, did you tried to render it? Like in the video expect reset the position.

Well no, I never needed it. Cutting your fps is half, that is a very nasty way if you ask me. 30 fps is unplayable in my opinion. So I would need at least 90 fps to keep it a bit smooth, but then of course the animation problems comes in.(60 fps normal and 30 fps for the camera) And for the production of those system. Probably playing with differed render events and creating 2 sources, 1 as overlay and 1 as camera.

That depends of the gpu, 4000x4000 will be nothing for me. But maybe for you it will drop frames. 100x100 will probably not take to much, keep in mind that you scale this to the ratio of his resolution. (so not 100 x 100)

You can also freeze it by rendering. (the ped isn't frozen in this video, but just to show you what is more possible when you render it)

yes, but it also depends on the dxCreateRenderTarget resolution.

You run two race race resources next to each other?

That you forgot to check this guy is your problem. You should ask him to show the result before you paid him. This section is not for requesters like you.

You want to know what is wrong? Well lets see if you are up to that. 1. You attach the weapons only at the localPlayer, the source of the event should be used instead. (so use source) 2. You trigger to all players when you use the command. But when a player joins after, nothing is sending this trigger to him. (use a table for the late joiner, when the player loads his resource = "onClientResourceStart", trigger serverside to get this table > trigger client again with the table) 2.1. Clean this table of that player when he leaves, 3. When you trigger an element to the other side(client< >server) this element can be destroyed and the code starts giving warnings. This is caused by critical network traffic. Good code never gives warnings or errors, if it does it gives lagg. So use: if isElement(source) then 4. Makes totally no sense: for _, nMax in ipairs ( getElementsByType ('player' )) do local nx, ny, nz = getElementPosition ( nMax ) setWeaponTarget ( minigunw ,nMax, 255 ) end

Check if the variable sound is created and if that part is executed.

You have a lot of problems with synchronising serverside data to clientside, this is a very hard learning process. I don't think you are ready for those knowledge yet. But there is another way you can do it, without that required knowledge. Which is creating those custom weapons, based on the player his actions. So when you start your resource and when a player joins. Require no extra communication, because of the events that already exist. You can't trust fully on this because of communication problems, caused by unstable ping and connection timed outs. But for the basic it would work. addEventHandler("onClientPlayerJoin",root, function() -- attach the weapon to the variable source end) addEventHandler("onClientResourceStart",resourceRoot, function () local players = getElementsByType("player") for i-1,#players do local player = players[i] -- attach the weapon to the variable player end end)