IIYAMA

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?

Keep it simple: local hit = processLineOfSight(pedX, pedY, pedZ + distanceOfStart, lineEndX, lineEndY, pedZ+ distanceOfStart, true, false, false) local colorSet = hit and 1 or 2 dxDrawLine3D(pedX, pedY, pedZ + distanceOfStart, lineEndX, lineEndY, pedZ+ distanceOfStart, tocolor(color[colorSet][1], color[colorSet][2], color[colorSet][3]), 2)

Normally this combination should be working. But there is one thing that is incorrect, and that is where the event is triggered. Currently it should trigger for all players, but multiplied by the amount of players. Since there is no player target set to where the event is sending to. triggerClientEvent("raceCevent", thePlayer) My recommendations: Serverside triggerClientEvent( thePlayer, -- send to this player "raceCevent", resourceRoot -- source is resourceRoot ) Clientside addEvent("raceCevent", true) addEventHandler("raceCevent", resourceRoot, -- activate the event based on the source resourceRoot function () end, false) -- disable propagate for security reasons