IIYAMA

The player is a value that is in most cases defined based on the action that made the code run in the first place. If it is an event, it differs from the pre-defined variable or parameter: Predefined variable: 'source'(responsible element for an event: onPlayerWasted), Predefined variable: 'client'(triggerServerEvent) Parameter: onVehicleEnter > first argument is the ped that enters, check wiki. For this event `source` is the vehicle because: onVehicleEnter > the event is about the vehicle and not a player. All this information is available on wiki. When dealing with functions that take input through different ways. It is best to normalize the information first, which you want to pass through your function. An example for addCommandHandler and an event: -- Information normalized from 2 - input(s) function showText (player, text) outputChatBox(text, player) end -- input 1 addCommandHandler("hi", function (player) showText(player, "Hi!") end) -- input 2 addEventHandler("onPlayerWasted", root, function () showText(source, "I died, sorry my bad.") end)

yes Small note: when you set another value, then you do not have to set it first to nil. Your code will overwrite the previous value with a new value: timers[hitPlayer] = nil timers[hitPlayer] = setTimer(stage1, 3000, 1, hitPlayer) -- < overwrite But feel free to leave it as it is, in case you are going expand the code.

When you are on stage3, you could start stage1 again. That is one way of doing. Also, have 1 infinity timer is not the end of the world. As long as it does not start another infinity timer within.

Even if you destroy the timer, both the value of the player(as table key) and timer (as table value) are still inside of the table.

That is correct. But don't forget to clean up: if timers[ hitPlayer ] then if isTimer(timers[ hitPlayer ] ) then killTimer(timers[ hitPlayer ] ) outputChatBox("leaving",hitPlayer) end timers[ hitPlayer ] = nil -- clean up end

That is correct. But it stops by itself, since it only runs 1x. (0= infinity) setTimer(stage3, 3000, 1, hitPlayer) In stage3 there is only a clean up for the value in the table.

This function can give you the position of the door: https://wiki.multitheftauto.com/wiki/GetVehicleComponentPosition (use the example functions to figure out the door component names) Keep in mind that the door can fall off, might be handy to define the positions inside of a static table. And this function can be used to compare the distance between you and the door: https://wiki.multitheftauto.com/wiki/GetDistanceBetweenPoints3D

Recommendation: It is best do not nest timer functions. Just create new named functions outside: local timers = {} --[[ if not timers[hitPlayer] then timers[hitPlayer] = setTimer(stage1, 3000, 1, hitPlayer) end ]] function stage1 (hitPlayer) timers[hitPlayer] = setTimer(stage2, 3000, 1, hitPlayer) end function stage2 (hitPlayer) timers[hitPlayer] = setTimer(stage3, 3000, 1, hitPlayer) end function stage3 (hitPlayer) timers[hitPlayer] = nil end function stopStageTimer (player) if timers[ player ] then if isTimer(timers[ player ] ) then killTimer(timers[ player ] ) end timers[ player ] = nil end end addCommandHandler("stopTimer", stopStageTimer) If your code works in stages, adding more timer tables will create more complexity. It is best to use 1 single timer table for all stages. Especially when you do this: end, 2000, 0 ) end, 12000, 0 ) This combo can kill your server at a given moment. Never create an infinity timer inside of another infinity timer. It will just multiply. Even if you create something that will prevent this inside of the function. > If there is an error inside the most inner function, the function will stop and it is not prevented any more. The following code can be used for: Stopping a timer Prevent double timers if timer2[ hitPlayer ] then if isTimer(timer2[ hitPlayer ] ) then killTimer(timer2[ hitPlayer ] ) end timer2[ hitPlayer ] = nil end

It is fine. That being said. 2x eventHandler will use more CPU. That is not a problem at this stage, but when you add more scripts, it might become a problem later for players that are using toasters. Just him, since the exact same copy of code is running on each player their pc. There is only 1 server. = 1x serverside There can be multiple clients/players. = for each player there is an unique clientside. (repeat: `which is running on their pc`)

Locked, this post has a double. That one is unlocked.

You can manage it like this: function startDrawing() welcome() drawpistol() end --[[ addEventHandler("onClientPreRender", getRootElement(), startDrawing); -- removeEventHandler("onClientPreRender", getRootElement(), startDrawing); ]]

All players. There is only 1 serverside, since there is only 1 server. There can be multiple clientside(s), since there are multiple clients/players. A table will help to manage which player wears which hat: local hats = {} addCommandHandler("hat", function(p) local hat = createObject(2053, 0, 0, 0) hats[p] = hat local id = getElementModel ( p ) if id == 0 then exports.bone_attach:attachElementToBone(hat, p, 2, 0.01, -0.02, -0.48, 0, 0,110) elseif id == 287 then exports.bone_attach:attachElementToBone(hat, p, 2, 0, -0.01, -0.45, 0, 0,100) elseif id == 285 then exports.bone_attach:attachElementToBone(hat, p, 2, 0.005, -0.01, -0.45, 0, 0,100) end end ); function removeHat () local hat = hats[source] if hat then hats[source] = nil if isElement(hat) then destroyElement(hat) end end end addEventHandler( "onPlayerWasted", root, removeHat) addEventHandler( "onPlayerQuit", root, removeHat)

By default: yes bool setElementData ( element theElement, string key, var value [, bool synchronize = true ] ) If synchronize is disabled: no

That is the tricky part about strings and numbers, they are represents each other a lot, but at the core they are very different. The console will indeed not show any difference between strings and numbers, that is also because everything inside of the debug console is already converted to a string. All string indications " " - ' ' - [[ ]] are not included. To debug that correctly, you can use the type function.

Convert both codes to a string. Maybe one is a number and one is a string. if tostring(theCode) == tostring(inputCode) then end That is what people normally do for security reasons. Do what you want.

It is a bit strange that serverside does not validate the code. This even makes it even possible for other players to modify your code, if those players can inject Lua. But about your problem, 1 of the 2 have to be incorrect: iprint("theCode=", theCode, "\ninputCode=",inputCode) Debug to figure out which one is broken.

There are 2 events: https://wiki.multitheftauto.com/wiki/Client_Scripting_Events#Object_events

That depends on the CPU speed as well as the drive. If you change from HDD to SSD, you will nearly eliminate the search time on that drive. But make sure you have enough space on it. ? Also check if there are user input ways that can be abused by your players. If there is a rotten apple in your server, the database is an easy target for exploiting command/input spams that will indirect execute a database request. Counter part. Thank you! ?

I read an article that stated that SQLite is creating temporary files for queries (I didn't know that), these files are of course not included in the size of your database. Are you sure you are not saving too much all the time so that your database can catch-up? It matches your case, as it happens over time and you can't open XML files because of the `missing space`.

Before (without element): guiSetText(switchData.languages[language] or switchData.langauges[defaultLanguage] or select(2, next(switchData.languages)) or guiGetText(switchData.element)) After (with element): guiSetText(switchData.element, switchData.languages[language] or switchData.langauges[defaultLanguage] or select(2, next(switchData.languages)) or guiGetText(switchData.element)) Also please stop putting confusing reactions on most of my replies, it marks them as confusing in general while most of them are not. Sure, I do not mind, if my reply does not make sense at all. You could using emotions in your own replies instead, that makes more sense. @TorNix~|nR

Provide the gui element. switchData.element And then you are ready to go

You need to index one more time with .languages, before you index with the actually language you want. 1. So: switchData.languages[language] 2. Same goes for the other lines that make use of that table. switchData.langauges[defaultLanguage] select(2, next(switchData.languages))

It is the moment of switching languages. It should at least be executed after creating the button. Now it is executed before that. Try to run this line with a command handler or with onClientResourceStart. (that is if you know if the value is set before that)

{Spanish = "policía", English = "Police"} You could swap es with Spanish, does that help? guiSetLanguageSwitch (getElementData(localPlayer, "Language")) -- call the function local defaultLanguage = "Spanish"

You could try this, not tested. But it is a start. local languageSwitch = {} local defaultLanguage = "nl" function guiSetLangaugeSupport (element, languages) languageSwitch[#languageSwitch + 1] = {element = element, languages = languages} guiSetText(element, languages[defaultLanguage] or guiGetText(element)) return element end function guiSetLanguageSwitch (language) for i=1, #languageSwitch do local switchData = languageSwitch[i] guiSetText(switchData.element, switchData[language] or switchData[defaultLanguage] or select(2, next(switchData)) or guiGetText(switchData.element)) end end switchData[language] or -- The option you want switchData[defaultLanguage] or -- default language select(2, next(switchData)) or -- First possible item guiGetText(switchData.element) -- previous text ;O local button = guiSetLangaugeSupport(guiCreateButton(0, 0, 0, 0, "", false, panel), {en = "Police", nl = "Politie"})