IIYAMA

yes

addEventHandler ( "onClientPlayerDamage", localPlayer, function (attacker, weapon, bodypart, loss) if attacker and attacker ~= localPlayer and bodypart == 9 and instandHeadshotKillWeapons[weapon] and not isPedDead(localPlayer) then iprint(wasEventCancelled ()) if not wasEventCancelled () then triggerServerEvent("onPlayerSyncHeadshot", resourceRoot, attacker, weapon, bodypart, loss) setElementHealth(localPlayer, 0) startBlockingPlayerControls() end end end, false, "low-100") Headshot script. local function stopDamage ( attacker, weapon, bodypart ) if isTimer(spawnProtectionTimer) then cancelEvent() outputDebugString("event is cancelled") end end addEventHandler ( "onClientPlayerDamage", localPlayer, stopDamage, false, "high+100" ) Spawnprotection script. I am trying to let the client cancel the player damage for spawnprotecion. But it seems like wasEventCancelled doesn't detect that the event was cancelled on the headshot script. I already changed the event order. Do you guys have any idea?

Using elementdata is fine, just make sure you disable the syncronization when you don't need it. ElementData is absolute not for important information. It is very foolish to save passwords or similar data in it. bool setElementData ( element theElement, string key, var value [, bool synchronize = true ] ) You could also use: bool setElementParent ( element theElement, element parent ) element getElementParent ( element theElement ) table getElementChildren ( element parent [, string theType = nil ] ) element getElementChild ( element parent, int index ) Or learn tables.

You haven't checked the debug console didn't you? I haven't tried it yet, but I think I know why it doesn't work. It probably doesn't have right to use callRemote. Check the debug if this is the problem. If that is the problem, then do the following: 1. Add this to your meta.xml (with in the <meta> </meta> tags) <aclrequest> <right name="function.callRemote" access="true" /> </aclrequest> 2. Restart the resource. 3. Login as admin and write: /aclrequest allow resource_compiler callRemote

That nobody is going to help you is obvious, especially when it isn't your code that has to be fixed. Unfortunately I am a scripter that only helps people who are trying to script. That's how I make sure people will learn from my help, else it would be a waste of my time. So I am a bit useless to you. But there are some options left: - Find an idiotic scripter who does it for free. (yes they do exist) They are people that post code for topic creators that didn't started with code. You can try contact those idiots with a pm. - Find a paidscripter. You might be able to fix it for €~3,5,- Which is nothing... - Try out another truf resource, there must be a few of those on the community. You are definitely not out of options.

Aha, Your code is a bit inefficient, so I suggest this as a fix: Clientside local powerName = "invisive11" triggerServerEvent("vipRequestPower", resourceRoot, powerName) Serverside local powerNameToFunction = {invisive11 = invisive11} -- eventName = functionName addEvent("vipRequestPower", true) addEventHandler("vipRequestPower", resourceRoot, function (powerName) local functionToCall = powerNameToFunction[powerName] if functionToCall then local account = getPlayerAccount( client ) if not isGuestAccount(account) and isObjectInACLGroup("user." .. tostring(getAccountName(account)), aclGetGroup("Admin")) then local timeNow = getRealTime().timestamp -- seconds, not ms local lastPowerTime = getAccountData( account, "lastPowerTime" ) if not lastPowerTime or timeNow > lastPowerTime+7200 then setAccountData( account, "lastPowerTime", timeNow) functionToCall(client) end end end end) function invisive11 (player) -- stuff here. end Admin = vip???

Check these conditions in to your script: What should happen if all players left the turf? What should happen if the player his team has been removed? And debug your code pls, then you should know:

@Ridden I do not understand what you want to do. Could you please reduce the amount code, so that I know where I have to look at?

getElementData(p, "acc:admin") > 0 if not getElementData(p, "acc:admin") > 0 then return end local numberValue = getElementData(p, "acc:admin") -- 7 outputDebugString(not numberValue) -- false false > 0 = Attempt to compare number with boolean (getElementData(p, "acc:admin") > 0) if not (getElementData(p, "acc:admin") > 0) then return end local numberValue = getElementData(p, "acc:admin") -- 7 outputDebugString(numberValue > 0) -- true local result = numberValue > 0 -- true outputDebugString(not result) -- false ( ) <<< priority!

You have to see it as 1 large rectangle. local progress = 55 -- 55% local amountOfSegments = 5 -- bars local progressPerSegment = (100 / amountOfSegments) local remainingProgress = progress & progressPerSegment local segmentsFull = math.floor(progress / progressPerSegment) local segmentsInUse = math.ceil(progress / progressPerSegment) iprint("segmentsFull: " .. segmentsFull) iprint("segmentsInUse: " .. segmentsInUse) iprint("remainingProgress: " .. remainingProgress)

Debugging Do you know what debugging is? You might think you do, but unfortunately (in my opinion) only ~15% of the scripters in the community do know the full definition of it. Many people think that debugging code is the same as looking in to the Debug Console and waiting for warning + errors to show up. That's indeed debugging and yet it never provide all information you need to build your scripts. It only can say what goes wrong at a certain line. With other words, the Debug Console by default will only show a limited amount of mistakes you have made in your code. So what is next? You fixed all warnings and errors and yet it doesn't work. You start with making your code visible! I guess 70% would think: Making code visible? Ehhh how??? Let me write it down a little bit different: By using Debug Information making the behaviour of the code visible. I guess 50% would think: Eh what? behaviour of code????? Let me give you an example. Example: (1) outputDebugString("the script has started") -- < this is a debug line if true then outputDebugString("code works here") -- < this is a debug line else outputDebugString("code shouldn't be working here") -- < this is a debug line end Debug console "the script has started" "code works here" The debug console is NOT information for players, it is information for YOU developers! BTW this is a debug line outputDebugString("test") -- < this is a debug line In this case it is just a piece of code that shows information in the debug console. Example: (2) local playerName1 = "snake1" local playerName2 = "cow" if playerName1 == playerName2 then outputDebugString("players playerName1 and playerName2 do share the same name. Name: " .. tostring(playerName1)) -- < this is a debug line else outputDebugString("players playerName1 and playerName2 do NOT share the same name. playerName1: " .. tostring(playerName1) .. ", playerName2: " .. tostring(playerName2)) -- < this is a debug line end Debug console "players playerName1 and playerName2 do NOT share the same name. playerName1: snake1, playerName2: cow" Easy isn't? The concept behind this debug method is to see what the code does / doesn't execute. Is this method handy? It is actually the very basic of debugging, for code that doesn't contain any errors/warnings. I would say it is handy and it is a very powerful method too. It is also handy for people who do not know how to script. If you want people to help you with your code, but you do not know what is wrong with it. You can add those debug lines and point out to where the code stops working. This will make it more efficient for you and the scripter to work out the problem, because the scripter knows where to look. How much debug lines do you have to add to your script? 1? 10? 100? 1000? You could start with around 100 debug lines and as you learn how to script, you can reduce it to 10+ debug lines. Too much debug lines are not always good, because they will give you too much information and it will cost time to manually filter them. So I recommend you to remove some of them afterwards. When you are finished with the tested code, you can remove 90+% of them. Feel free to disable them instead of removing them, if you know that you are going to need them again. For complex code, I use around 25 debug lines, SO DON'T HOLD BACK! Render events It is strongly recommended to remove debug lines that are executed on onClientRender/render events when you are finished with your code. Because that can have influence on the smooth fps.(It will not drop much of the fps, but it can make it feel unsmooth) Clearing the debug console? /cleardebug Know your tools: outputDebugString -- Show a message on the Debug Console bool outputDebugString ( string text, [ int level=3, int red=255, int green=255, int blue=255 ] ) --- outputConsole -- Show a message on the F8 panel. bool outputConsole ( string text ) -- client bool outputConsole ( string text, [ element visibleTo=getRootElement() ] ) -- server --- inspect -- Convert one mixed value to a string. string inspect ( mixed var ) --- print -- Show a message on the terminal / serverwindow / Debug Console. bool print ( string var1[, string var2, string var3...] ) --- tostring() -- Convert a value in to a string. (but for objects/elements, inspect works better) --- iprint -- Show a message on the terminal / serverwindow / Debug Console (convert multiple mixed values automatic to string, no need for tostring or inspect) bool iprint ( mixed var1[, mixed var2, mixed var3...] ) --- outputChatBox -- You can also debug with outputChatBox (even though it is less efficient) bool outputChatBox ( string text [, int r=231, int g=217, int b=176, bool colorCoded=false ] ) -- client bool outputChatBox ( string text [, element visibleTo=getRootElement(), int r=231, int g=217, int b=176, bool colorCoded=false ] ) -- server Debug message levels 0: Custom message 1: Error message 2: Warning message 3: Information message (default) Addition by @Hale https://wiki.multitheftauto.com/wiki/OutputDebugString Advanced tools: local line = debug.getinfo(1).currentline -- get the line of the script where the code has been executed. 1 = current function. (can be useful if you want to get the line where this function has been called from) https://www.lua.org/pil/23.1.html WIKI MTA: WIKI MTA debugging tutorial/information. https://wiki.multitheftauto.com/wiki/Debugging

end, 1000, countdown) I do recommend this. There is no need for an infinity timer since you already know that it is going to stop at 0.

outputChatBox("You're not in a gang. Use /create to create one.", player, 255, 255, 0, ) You used the wrong syntax. (serverside) https://wiki.multitheftauto.com/wiki/OutputChatBox

Usually id's should be unique... ehm, they actually should always be unique, no excuses. The fastest way would be element nesting: https://wiki.multitheftauto.com/wiki/GetElementChildren

https://wiki.multitheftauto.com/wiki/SetWeaponProperty

Yea, they most likely do that, since it is something from gta that can't be overwriting. Also you can change the settings from poor stats to pro settings(even though you still use poor stats).

75: WEAPONTYPE_MICRO_UZI_SKILL Tec9 and uzi 79: WEAPONTYPE_SNIPERRIFLE_SKILL Rifle and sniperrifle

I am expecting a lot of naked sexy female skins, inside fast cars. Or just a mode where nothing works as you would expected and you will be punished for everything you do. (my imaginations are running wild )

Why don't you start with learning how to create an infinity timer? Just create it for fun and let it say something in the chat! https://wiki.multitheftauto.com/wiki/SetTimer https://wiki.multitheftauto.com/wiki/OutputChatBox

Loops are not meant to check if something has changed, they will keep running and delay all other processes until the system stops it. Loops are for processing multiple pieces of data during one action. How about you use a timer instead? (if serverside) https://wiki.multitheftauto.com/wiki/SetTimer Or 'onClientRender' (if clientside) https://wiki.multitheftauto.com/wiki/OnClientRender

Hmm really strange haha. My bad, I really though you used it. (I never said you used the code, but the tutorial) I apologies for this misunderstanding It is sad to hear that your project ended up badly. Roleplay servers do indeed take a lot of time and it is hard to do it alone. Lol 'kutmode' sounds very Dutch haha, even though you are registered as the UK.

I remember it was 'possible' with minigun, except you would crash after aiming your weapon. So they probably disabled it for that reason.

Sounds to me you forgot my tutorial in your credits. As I said in the tutorial, you must add credits if you use my tutorial for your code. I left a watermark, that's how I know you used it. So add credits and re-upload it, thank you! ?

Hackers not really common, true. That's why I mentioned backdoors as well, which are more common. (Especially when there are compiled community scripts running on the server)

There are two reasons why people (like me) do compile + encrypt script. - Security for hackers and backdoors (which unfortunately do exist) - Performance (compiled scripts are optimised) So pls, do not criticize people for doing the right thing. Just fill in your server version. I guess your server is 1.5.3? (Using the server version gives less problems) <min_mta_version client="1.5.3" server="1.5.3" />