IIYAMA

Because the moment of execution is aligned with your fps. (Or internal clock) I assume this decision is made in order to reduce constantly activity of the CPU and not blocking processes of other applications.

Because you are creating for each event a new gridlist. The following code will create a gridlist if it does not exist if not pedGridList then pedGridList = guiCreateGridList(0, 0, 50, 50, false) end

1 second is a lot of frames. Too many to be honest, it loses it's purpose if you do that. The whole purpose is to slowly push those peds aside, instead of blocking. NOTE: This is still a concept, there are no guarantees that it will work. You can use my callNextFrame function if you want. source --[[ -- callNextFrame function ]] local tableRemove = table.remove local serverSide = triggerClientEvent and true or false do local nextFrameCalls = {} local serverSideTimer local processing = false local function process () --[[ Do an empty check at the beginning of the function, this will make sure to make an extra run in case of heavy work load. If the timer is killed or the addEventHandler is removed, then this has to be re-attached again every frame. This is not very healthy... ]] if #nextFrameCalls == 0 then if serverSide then if serverSideTimer then if isTimer(serverSideTimer) then killTimer(serverSideTimer) end serverSideTimer = nil end else removeEventHandler("onClientRender", root, process) end processing = false return end -- In case of calling the function callNextFrame within the process, the loop type `repeat until` is required. repeat local item = nextFrameCalls[1] item.callback(unpack(item.content)) tableRemove(nextFrameCalls, 1) until #nextFrameCalls == 0 end function callNextFrame (callback, ...) if type(callback) == "function" then local newIndex = #nextFrameCalls + 1 nextFrameCalls[newIndex] = {callback = callback, content = {...}} if not processing then if serverSide then serverSideTimer = setTimer(process, 50, 0) else addEventHandler("onClientRender", root, process) end processing = true end return true end return false end end

You could disable the collision between the car and ped for 1 or 2 frames after you ram it. https://wiki.multitheftauto.com/wiki/OnClientVehicleCollision https://wiki.multitheftauto.com/wiki/SetElementCollidableWith This way it could be more easy to ran them over.

I am not sure if you can run this with dbQuery, but never the less give it a try. SHOW FULL TABLES

The very basic. local example = {} function saveExample (object, player) example[object] = player return true end function loadExample (object) return example[object] end

If synchronization is enabled, the server as well as all players have that performance penalty. If disabled, it is just the server (and exclusive network packets management). It is not bad practice, but if you could use Lua instead, it would be even better since it is a lot faster (and doesn't trigger the event system)

You have more debugging to do with debuglines.

local findGroup = xmlLoadFile(":startup/dbconfig.xml", true) local findGroup = xmlFindChild(loadConfig, "config", 0)

How does your xml file looks like? local loadConfig = xmlLoadFile(":startup/dbconfig.xml", true) btw this will give you already the rootNode. (it doesn't matter what tagname you gave it) <rootNode> <child></child> </rootNode>

By nesting them, so that you know which table belongs to which gate. local gates = { { openPosition = {x = 1023.599609375, y = -367.7001953125, z = 74.099998474121}, closePosition = {cx = 1029.3000488281, cy = -367.7001953125, cz = 74.099998474121}, colshapes = { {colX = 1021,colY = -371.5,colWidth = 5,colHeight = 8}, -- {colX = 1021,colY = -371.5,colWidth = 5,colHeight = 8} 2 colshapes? }, state = "closed", gateElement = nil }, --[[{ another gate }]] } --[[ While creating the elements, make the link between element and table. When you have access to the element, you have direct access to the data that belongs to the gate. ]] local dataByColshapes = {} local gateElement = createObject(...) local colshapeElement = createColRectangle(...) local gate = gates[i] gate.gateElement = gateElement -- save the gate element also inside of this table -- Make the link dataByColshapes[colshapeElement] = gate -- hit colshape?: local gate = dataByColshapes[source] if gate then local gateElement = gate.gateElement -- move gate! gate.openPosition, gate.closePosition end

Then you will need xml functions. If you added the file as a config file in the meta.xml, then you can get the file like this: https://wiki.multitheftauto.com/wiki/GetResourceConfig Else you will need this function https://wiki.multitheftauto.com/wiki/XmlLoadFile All of them -> https://wiki.multitheftauto.com/wiki/Xmlnode

I don't think it can be a simple example, but here you go. local bone_attach = {} local bone_attach_render = {} local queue = {} local queueProcessStatus = false local queueNextCycleTime = 0 local tableRemove = table.remove function prepareQueue () queueProcessStatus = true for i=1, #bone_attach do local item = bone_attach[i] if not item.rendered then queue[#queue + 1] = item end end end function processQueue () for i=#queue, math.max(#queue - 50, 1), -1 do local item = queue[i] local element = item.element if isElement(element) and isElementStreamedIn(element) then item.rendered = true bone_attach_render[#bone_attach_render + 1] = item end tableRemove(queue, i) end if #queue == 0 then queueProcessStatus = false end end addEventHandler("onClientRender", root, function () for i=#bone_attach_render, 1, -1 do local item = bone_attach_render[i] local element = item.element if isElement(element) and isElementStreamedIn(element) then else item.rendered = false tableRemove(bone_attach_render, i) end end -- cycle management local timeNow = getTickCount() if not queueProcessStatus then if timeNow > queueNextCycleTime then prepareQueue() queueNextCycleTime = timeNow + 3000 end else processQueue () end end)

getTickCount returns the up time of the system. https://wiki.multitheftauto.com/wiki/GetTickCount

I see you have optimised the loop cycles to the bone. But there is something you haven't tried yet, which can improve performance of 100 objects to a % of that, depending on the context. In your current code, you are making full cycles, which changes the usage of the resource by the amount of objects. But what if you could only make the necessary cycles? Prepare render cycle | | \/ bone_attach \ / Add each item to the queue, except for the once that are already in the render table, based on a state. QUEUE \ / Loop through 50 items each frame QUEUE [50 elements] \ / Is element streamed in? If YES, then add the item to the render table. If YES or NO, then table.remove. Give the item a state that it is already in the render table. bone_attach_render | | \/ Re-do the cycle after X ms This concept allows you to reduce big looping cycles. Which also allows you to even render 1000 objects, as long as the peds/players are not inside of the same area. These are not all the steps, there are some more which are related to 'destroyed' and 'streamed-out' elements.

See this tutorial. Or attach the addEventHandler on to the resourceRoot. This will trigger the eventHandler only for elements created by the same resource.

Because in the first example, login_box is not defined. So: gui_elements = {} gui_elements["login_box"] = guiCreateWindow(0.39, 0.29, 0.21, 0.43, "", true) gui_elements["user_input"] = guiCreateMemo(0.16, 0.15, 0.66, 0.13, "", true, gui_elements["login_box"]) gui_elements["password_input"] = guiCreateMemo(0.16, 0.30, 0.66, 0.13, "", true, gui_elements["login_box"]) gui_elements["big_button"] = guiCreateButton(0.17, 0.47, 0.43, 0.11, "", true, gui_elements["login_box"]) gui_elements["small_button"] = guiCreateButton(0.68, 0.47, 0.15, 0.12, "", true, gui_elements["login_box"])

Even after all those optimisations, it is still pretty high ? What is the usage of the initial version compared to the current version? Also, I might be able to squeeze even more out of it, if you want that.

You can't retrieve async data with a blocking method. Blocking/sync function _Query( ... ) if connection then local queryHandle = dbQuery( connection, ...) return dbPoll(queryHandle, -1) else outputServerLog("DB: Tried to fetch query but failed.") return false end end Non-blocking/Async function _Query(callBackFunctionName ... ) local sourceResource_ = sourceResource if connection then dbQuery( function (queryHandle) local results = dbPoll(queryHandle, 0) call ( sourceResource_, callBackFunctionName, results ) end, connection, ... ) return true else outputServerLog("DB: Tried to fetch query but failed.") return false end end

Nope, but shaders can hold other textures, and renderTargets can capture unexpected different parts of images. Combine those and it can cause exactly that problem. If there are no rendertargets in the rest of the code, then it is also a mystery for me. ?

Did you END the render target capture scope? (which is excluded in this code)

If the average total is higher than 30%, you might have a problem over time. If your server fps is much lower than the client fps, you might have a problem. If the regular operations on client/server from scripts take longer than 10/16 ms, you got a big problem.

Little example: local gameModeState = "initial" function setGameModeState (newState) gameModeState = newState end function getGameModeState () return gameModeState end addEventHandler("onResourceStart", resourceRoot, function () setGameModeState ("started") setTimer(function () setGameModeState ("lobby") end, 1000, 1) end, false) addEventHandler("onPlayerJoin", root, function () if getGameModeState () == "lobby" then -- do something end end)

The management of initiated/loaded players. Design different gamemode states. (loading/lobby/started) Making a list of resources you might need, instead of building every component from scratch. You do not have all the time of the world and you will be demotivated after a while, so make sure you will be able to finish it, else it is a waste of time. (99% of the people will be demotivated after a while...)

Using: https://wiki.multitheftauto.com/wiki/Resource:Dynamic_lighting#setLightPosition + https://wiki.multitheftauto.com/wiki/OnClientPreRender