IIYAMA

Lua Language Server - Definition files The Lua language server is a powerful tool that enhances the development experience for Lua programming. It provides a comprehensive set of code editing features, including suggestions, auto-completion, and error checking. With the Lua language server, developers can effortlessly navigate through their resource files, access documentation easily, and ensure code correctness by giving warnings. Why should you care? The language server will inform you about all sorts of problems: type mismatches, missing function arguments, missing variables, etc. You have access to a lot of MTA syntax/autocomplete out of the box. The syntax information will remain while writing. You do not have to restart your resource so often in order to validate if everything is working. Type validation Having value type validation in your code editor is one of the main key features of the Lua Language Server. When working with variables, parameters, and arguments in Lua, you are not restricted to specific value types. This flexibility can make mistakes more likely to happen. However, being able to validate those mistakes instantly saves you a lot of time and frustration. Type annotations for your own functions Adding type annotations to your own functions can help improve validation and catch logic mistakes. It is particularly useful when calling functions from different parts of your code, as the annotations provide clarity on the expected input (arguments) and output (return values). Additionally, comments that are placed above or adjacent to a variable or function are visible when hovering over them in another file or line. This can provide helpful information and context when working with the code. How that looks like: How can I quickly add annotations in less than a second? Open the spoiler: AddEventHandler auto-complete Most MTA addEventHandler functions have full eventName autocompletion. And the attached anonymous function is fully autocompleted and typed as well. Navigation features of Lua Language Server It can be time consuming to find out where a (global) function or variable is located. Being able to jump right to it, saves you a lot of time. Other information which you can find in the readme Installation for the Lua Language Server How to use the definition files? Known issues Make sure to always have an empty new line at the end of your files, as recommended in this issue. Currently, the Lua server language definition files do not have a clear separation between serverside functions/events and clientside functions/events. However, it is possible to enforce this separation for specific functions if needed. outputChatBox--[[@as outputChatBox_server]]("Serverside", player) In certain cases, certain functions in the Lua server language definition files may return multiple types, even if you have selected a different syntax. To handle this situation, you can use the `cast` or `as` notation to explicitly specify the desired type or adjust the returned type. See `Casting and as` syntax below. Casting and as In certain situations, you may have a strong understanding of the type(s) that a variable or expression will have. This is where the keywords "cast" and "as" come into play. These keywords enable you to explicitly specify the intended type, ensuring proper type handling. local varName = exampleFunc() ---@cast varName string local varName = exampleFunc() ---@cast varName string | number local varName = exampleFunc() --[[@as string]] local varName = exampleFunc() --[[@as string | number]] Download The definition files can be downloaded here.

Yes, as long as you do not break the code. <script> function onRemotePlayerWasted (arg) { /* ... */ } </script> addEventHandler("onClientPlayerWasted", root, function () local arg = 123 -- Or string "\"123\"" | "'123'" | '"123"' | [["123"]] --[[ Or table through JSON: local arg = '`' .. toJSON({}) .. '`' In JS: const result = JSON.parse(arg) ]] executeBrowserJavascript(browser, [[onRemotePlayerWasted(]] .. arg .. [[);]]) end) *adjusted JSON example, Must be tested through trial and error.

For example you have an html file with: <script> function onRemotePlayerWasted () { /* ... */ } </script> And you inject the following JavaScript to call the function. addEventHandler("onClientPlayerWasted", root, function () executeBrowserJavascript(browser, [[onRemotePlayerWasted();]]) end)

You could try something like this. -- See https://wiki.multitheftauto.com/wiki/ExecuteBrowserJavascript for the rest of browser the code function reloadList (browser) local list = { "a", "b" } local htmlItems = {} for index, value in ipairs(list) do table.insert(htmlItems, [[<li>]] .. value .. [[</li>]]) end local js = [[{ const list = document.createElement("ul") list.innerHTML = `]] .. table.concat(htmlItems, "\n") .. [[`; document.body.append(list); }]] executeBrowserJavascript(browser, js) end addEventHandler("onClientBrowserDocumentReady", browser, function () reloadList (source) end) See: https://wiki.multitheftauto.com/wiki/OnClientBrowserNavigate when having different pages

There is also the executeBrowserJavascript function used to inject JavaScript in to the browser (browser with local context only).

Having very complex winning conditions also makes it harder for your players to understand. Maybe it is for the best to keep things simple.

Something I like to do it is logging the current situation. playerCount in the area (of all teams) score winner And then go manually through the system with the current situation until you find the issue.

I took a look at it. But I am not sure if I understand all the rules. One thing that I can suggest to make it more readable: local example = { ["Grove Street"] = function (score, playerCount) -- Aztecas or Vagos if score > 0 and (playerCount["Aztecas"] > 0 or playerCount["Vagos"] > 0) and playerCount["Aztecas"] ~= playerCount["Vagos"] then if playerCount["Aztecas"] > playerCount["Vagos"] then return "Aztecas" end return "Vagos" end -- or Ballas if score > 0 and playerCount["Ballas"] > 0 or playerCount["Grove Street"] == 0 then return "Ballas" end -- or Grove Street return "Grove Street" end } -- local winner = example[areaTeam](score, playerCount)

It does. The new method is a utility function, which does everything for you. But also for some parts it forces you to be more strict. For example the: protectedKeys table part. For resourceRoot you can also block this, instead of reporting. Saves you some lines of code. addEvent("onRaiseTheRoof", true) addEventHandler("onRaiseTheRoof", resourceRoot, function(arg1, arg2) end, false) -- propagate disable, making sure only resourceRoot can be passed as the source

Bullets do not start from the weapon Muzzle position. The start position is: https://wiki.multitheftauto.com/wiki/GetPedTargetStart And the end position: https://wiki.multitheftauto.com/wiki/GetPedTargetEnd Both can be used to create a vector for the line you are referring to. This is related to the reason why people can shoot around corners without showing more than their elbows. Since the bullets start more to the right of the weapon.

As roaddog mentioned, toJSON is the easiest way to dynamic store data. But keep an eye on the limitations of JSON. Only store JavaScript structured default {} objects or [] arrays, nothing in between! (else it will be converted to the default {} object variant) This would be the most space saving solution. Depending on the amount of players you receive every day, it might be a better solution when there are a lot. Just keep in mind that it will be more work.

If you are worrying about performance, in that case you might consider using MySQL triggers. Those are as close as it gets to your db, making sure you do not cause overhead and align the value-checks with the update moments. https://dev.mysql.com/doc/refman/8.0/en/trigger-syntax.html Create a value-check table / rollback table: Stores the value that it is being incremented (within 30 seconds) Stores the future time, when elapse the incrementing value can be ignored and resets to 0 Create a trigger which triggers on update Do behaviour of value-check table. If the value jumps too much UP: Report to a separate table Freeze account Rollback manually / automatic (not recommended)

Preventing is better than checking for unusual values. Especially when you can't don't keep track of how they have been changed. This could have been done by an exploit instead of real cheats. I personally consider exploiting almost cheating, since the developers should be responsible to deliver decent code. Back to the subject: Value changes in databases are often done by user input. This should be your primary objective. For example if you have a marker that opens a GUI to transfer money: addEvent("onPlayerTransferMoney", true) addEventHandler("onPlayerTransferMoney", resourceRoot, function (marker, transferAccountId) -- Possible cheating? = hard returns if not isElement(marker) then return end local playerX, playerY, playerZ = getElementPosition(client) local markerX, markerY, markerZ = getElementPosition(marker) if getDistanceBetweenPoints3D ( playerX, playerY, playerZ, markerX, markerY, markerZ ) > 10 then return end -- More user friendly returns if not checkPassiveTimer("event:onPlayerTransferMoney", client, 1000) then return outputChatBox(client, "You can only transfer money every 1 sec.") end -- Source code: https://wiki.multitheftauto.com/wiki/CheckPassiveTimer if not transferAccountId then return end -- resume operations -- end) Check if marker exist Check if player is close enough to the marker Limit execution speed (else users can create database lag by spamming the UI button) Building an anti cheat system to check for anomalies in your database should be a secondary objective. In this case you could start with defining limits. For example a money limit. A soft limit to detect possible cheating and a hard limit to define the impossible. For a soft limit you only report to yourself, as it might be very active player. And for a hard limit, you could for example freeze the money. In this case you could inform the user that you are investigating the issue. > As you might not know if the user itself is responsible for the anomaly or if another user is responsible. That user could also be helpful in finding/knowing the exploit that is responsible for the anomaly.

Yes, in every resource that is receiving data from the database manager, you should add an export function with the name dbResponse. (it is important that the name 'dbResponse' is used consistent)

A - Resource requesting data B - Database manager A > B The first export function is db_query, located in resource B, which you have already created. -- Resource A makes this call to resource B exports.database_connection:db_query(id, "SELECT * FROM `players`") <!-- Resource B --> <export function="db_query" type="server" /> B > A The second one is dbResponse, located in resource A, which is where the response is returned to, with: -- Resource B makes this call to resource A call( theSourceResource, "dbResponse", id, result, num_affected_rows, last_insert_id ) <!-- Resource A --> <export function="dbResponse" type="server" /> -- Resource A function dbResponse (id, ...) if not callbacks[id] then return end callbacks[id](...) end Not sure if you want to keep your function naming style, else it will be db_response ofcourse.

The following examples are part of a project I have build before. You will have to set-up: 2 export function (one each resource) For sending (as you have now) And for receiving You will have to generate an unique identifier for each query, so that each request can be wired back to where you want the data. -- Resource A Identifier = {} function Identifier:newGenerator() return setmetatable( { index = 0 }, { __index = Identifier } ) end function Identifier:generate() local index = self.index + 1 self.index = index return "id:" .. getTickCount() .. "|" .. index end -- For new ID's local identifierGenerator = Identifier:newGenerator() -- function () local id = identifierGenerator:generate() -- end Before you send a request you make sure that there is a destination: -- Resource A callbacks = {} -- function () local id = identifierGenerator:generate() -- Set-up the callback destination, anonymous func if you want to keep going where you left of. callbacks[id] = function (...) iprint(...) end exports.database_connection:db_query(id, "SELECT * FROM `players`") -- end Add wiring for receiving and calling back your callback function: -- Resource A function dbResponse (id, ...) if not callbacks[id] then return end callbacks[id](...) end Keep the wiring going in the db resource, so that the ID goes ping pong: -- Resource B function db_query(id, ...) -- The source resource that made this call (important to rename the pre-defined variable, else it will be lost) local theSourceResource = sourceResource if (db_settings.db_connection) then dbQuery(function(query_handle) local result, num_affected_rows, last_insert_id = dbPoll(query_handle, 0) call( theSourceResource, "dbResponse", id, result, num_affected_rows, last_insert_id ) end, db_settings.db_connection, ...) end end

Not sure about replacing it without affecting the original fire. But if you look closely at the fire animations, you can see that it exist out of 2x > 2D animations. Each of them starts at one of the feet. Which you could draw with: dxDrawMaterialLine3D (that is if you have the frames or a shader) Note: Too much of those calls can be demanding, make sure to optimise the textures. Please consider replying on your other topic.

Just move the text by 1 pixel: local borderSize = 1 dxDrawText(v.text, sx - (0.5 * width) - borderSize, yPos, sx - (0.5 * width) - borderSize, yPos - (i * fontHeight), tocolor(0,0,0), 1, font, "left", "top", false, false, false) dxDrawText(v.text, sx - (0.5 * width) + borderSize, yPos, sx - (0.5 * width) + borderSize, yPos - (i * fontHeight), tocolor(0,0,0), 1, font, "left", "top", false, false, false) dxDrawText(v.text, sx - (0.5 * width) - borderSize, yPos, sx - (0.5 * width) + borderSize, yPos - (i * fontHeight), tocolor(0,0,0), 1, font, "left", "top", false, false, false) dxDrawText(v.text, sx - (0.5 * width) + borderSize, yPos, sx - (0.5 * width) - borderSize, yPos - (i * fontHeight), tocolor(0,0,0), 1, font, "left", "top", false, false, false) dxDrawText(v.text, sx - (0.5 * width), yPos, sx - (0.5 * width), yPos - (i * fontHeight), tocolor(unpack(v.color)), 1, font, "left", "top", false, false, false)

Yes, you use the event system for that. --[[ Ⓒ FLUSHBICEPS ]] addEventHandler("onClientKey", root, function(button, press) if not press then return end if button == "mouse_wheel_up" then selectedIndex = selectedIndex - 1 if selectedIndex < 1 then selectedIndex = #nearbyPlayers end elseif button == "mouse_wheel_down" then selectedIndex = selectedIndex + 1 if selectedIndex > #nearbyPlayers then selectedIndex = 1 end else return end local selectedPlayer = nearbyPlayers[selectedIndex] if not isElement(selectedPlayer) then return end triggerEvent("onClientSelectPlayer", selectedPlayer, selectedIndex) end ) addEvent('onClientSelectPlayer', false) addEventHandler('onClientSelectPlayer', root, function (selectedIndex) iprint('Player-element:', source, ', index:', selectedIndex) end)

It is not possible at the moment with the help of gravity functions, because there is only a gravity function for vertical for non vehicle elements. That being said, you might be able to fake it. With some inspiration from the superman resource. But it will not be easy.

-- Run this one time local fuelImage = dxCreateTexture ("fuel.png", "argb", true, "clamp") And: dxDrawImageSection(screenX - ScaleY(289), screenY - ScaleY(19), ScaleY(47), ScaleY(-(123*(fuel/100))), 0, 0, ScaleY(47), ScaleY(-(123*(fuel/100))), fuelImage , 0, 0, 0, tocolor(2,153,0,255), false)

This is fine. You could transform it in 1 query. But that basically means that you will have to split them up later with Lua. SELECT name, 'time' AS type, time, NULL AS kills FROM general ORDER BY time DESC LIMIT 20 UNION ALL SELECT name, 'kills' AS type, NULL AS time, kills FROM general ORDER BY kills DESC LIMIT 20

To solve this problem, you have to use debug lines(iprint) to get to the problem. I fixed here a logic issue, where the player is not removed from the database when he is not ingame. function unmutePlayer(serial, punisherName, ruleNumber, ruleDescription) local player = getPlayerFromSerial(serial) iprint( "<unmutePlayer> mutedPlayers[serial]:", mutedPlayers[serial], ", player:", player ) if mutedPlayers[serial] then if mutedPlayers[serial].unmuteTimer then killTimer(mutedPlayers[serial].unmuteTimer) end mutedPlayers[serial] = nil iprint("<unmutePlayer> remove from database") executeSQLQuery("DELETE FROM punishments WHERE serial = ?", serial) if player then local playerName = getPlayerName(player) setPlayerMuted(player, false) outputChatBox("#00FF00" .. playerName .. " has been unmuted by #FFFFFF" .. punisherName .. " #006600[#FFFFFFReason: Manual unmute#006600]", getRootElement(), 255, 255, 255, true) end elseif player then local playerName = getPlayerName(player) outputChatBox(playerName .. " is not currently muted.", getRootElement(), 255, 255, 255, true) end end And here I added some debug lines, tweaked the select query and removed the loop. addEventHandler("onPlayerJoin", root, function() local player = source local playerName = getPlayerName(player) local playerSerial = getPlayerSerial(player) local query = executeSQLQuery("SELECT * FROM punishments WHERE serial = ? LIMIT 1", playerSerial) iprint('<onPlayerJoin> query:', query) if query and #query > 0 then local row = query[1] local totalDuration = tonumber(row.duration) local ruleNumber = row.reason local ruleDescription = rulesTable[ruleNumber] iprint('<onPlayerJoin>', "totalDuration:", totalDuration, ", difference:", (getRealTime().timestamp - row.timestamp), ", remaining:", totalDuration - (getRealTime().timestamp - row.timestamp)) local remainingDuration = totalDuration - (getRealTime().timestamp - row.timestamp) if remainingDuration <= 0 then executeSQLQuery("DELETE FROM punishments WHERE serial = ?", playerSerial) else setPlayerMuted(player, true) mutedPlayers[playerSerial] = { duration = remainingDuration, startTime = row.timestamp } mutedPlayers[playerSerial].unmuteTimer = setTimer(unmutePlayer, remainingDuration * 1000, 1, playerSerial, "Console", ruleNumber, ruleDescription) outputChatBox("#FFFFFF".. playerName .. " has been muted by #FFFFFFConsole. Reason: RULE #" .. ruleNumber .. ": " .. ruleDescription .. ". Duration: " .. formatTime(remainingDuration), getRootElement(), 255, 255, 255, true) end end end)

Don't use playername, use serial. And don't pass the player to this function: function unmutePlayer(player, punisherName, ruleNumber, ruleDescription) Pass over it's serial function unmutePlayer(serial, punisherName, ruleNumber, ruleDescription) local player = getPlayerFromSerial ( serial ) -- utility function copy from: https://wiki.multitheftauto.com/wiki/GetPlayerFromSerial if player then -- is the player in the server? -- inform the player that he has been unmuted end

How does the data looks like? And what type does it have?