IIYAMA

@Turbesz I can see that you are confused by my reply. These are the fragments of a decompiled script: I am not going to start a discussion with you about how those slipped in to your code. When I see reverse-engineered variable names, the topic is locked. (Not the end of the world...)

Your current code contains fragments from a decompiled script. Locked

Moved to here: https://forum.multitheftauto.com/forum/127-programação-em-lua/

Moved to here: https://forum.multitheftauto.com/forum/127-programação-em-lua/

Clientside The dangerous part of elementdata is that the programmer might forget that each time it is set (on clientside), it will synchronize with the server and after that it will also synchronize with all other players. The following code is in my opinion to be considered dangerous: addEventHandler("onClientRender", root, function () setElementData(localPlayer, "test", getTickCount()) end) No synchronization steps are skipped (even if the same is the same), therefore if can stack up until no other messages can be send and network error occurs after the buffer is filled for too long. Same goes for serverside: setTimer(function () setElementData(root, "test", getTickCount()) end, 50, 0) --------- Elementdata are be replace-able by tables, that will excluding the synchronization part as well as the event system. You can also disable synchronization: setElementData(root, "test", getTickCount(), false) -- false = disable

Timers in general can become never ending, if not programmed correctly. That is why you should use them with care. It is not as if timers are dangerous by themself. But when they become never ending, there is a risk that your code might create a new infinity timer with the same task. Which leads up to creating a memory leak in the form of infinity amount of timers. Each timer uses CPU and memory. But that ain't the biggest issue. The tasks/functions attached to the timers are also becoming infinity. So for example if the task is `setElementData(vehicle, "fuel", <some value>)`, this function is using bandwidth (and CPU) for all clients/players. When this becomes infinity, there is no bandwidth for other things and a network error occurs. (server will die at a given moment if it continues for too long) getTickCount is something passive, you need to combine that with an timer/onClientRender, to make it active. Active (timer + getTickCount) https://gitlab.com/IIYAMA12/draw-distance/-/blob/master/scripts/timer_c.lua Passive (getTickCount) https://wiki.multitheftauto.com/wiki/CheckPassiveTimer

That was already a given, all Lua executions are on a single core afaik. If you know which resource is responsible, then through manually debugging: - Enable/disable code - Tracing chains of function calls - Measuring execution times = getTickCount() - Check meta-tables, that have functions attached to them. - Check for functions that are suppose to be a-sync. - Check the amount of timers (they are CPU hungry), if you use too many, stack them. And use passive timers where possible. You can also measure function executions, maybe you find something there: addDebugHook( "preFunction", onPreFunction) https://wiki.multitheftauto.com/wiki/AddDebugHook

You could check if there is a player who thinks it is funny to spam a command, so that your server starts to lag (no joke, when no limit is applied, it is an absolute vulnerability.): https://wiki.multitheftauto.com/wiki/OnPlayerCommand You could rent another VPS and see if that one performs better. Since it is a VPS and not a dedicated server, you will not be able to monitor the global statistics. If your neighbour uses a lot of data,CPU etc., you might not be able to notice that through your own server statistics, while still receiving bad performance.

Database Are all database requests a-synced? < (check that) Experiment with indexes: https://www.youtube.com/watch?v=uyLy462Fmk8 At limits for search queries: LIMIT 1 triggerClientEvent - personalize the data Combine those related to the group system and only trigger over 1 event name. Combine all triggered events that are executed within 1 function -> In that 1 event, you can give all kinds of instructions that have to be done with the group system. You probably have to create a new file for how that is going to work.

The database can also be an factor. Which fields have you already optimised through applying indexes?

What is the quantity? You can queue it (buffering it). ------------------------ Is there a request? Wait 0,3/0.5 seconds + put the requests in a table. Then send it. While putting it in the table, make sure to only send the latest groups-list to each player.

Something like this: (untested) local eventUsage = {} function onPreEvent( sourceResource, eventName, eventSource, eventClient, luaFilename, luaLineNumber, ... ) local args = { ... } local srctype = eventSource and getElementType(eventSource) local resname = sourceResource and getResourceName(sourceResource) local plrname = eventClient and getPlayerName(eventClient) if not eventUsage[eventName] then eventUsage[eventName] = {} end eventUsage[eventName][#eventUsage[eventName] + 1] = "preEvent" .. " " .. tostring(resname) .. " " .. tostring(eventName) .. " source:" .. tostring(srctype) .. " player:" .. tostring(plrname) .. " file:" .. tostring(luaFilename) .. "(" .. tostring(luaLineNumber) .. ")" .. " numArgs:" .. tostring(#args) .. " arg1:" .. tostring(args[1]); end addDebugHook( "preEvent", onPreEvent ) setTimer(function () { local eventUsageSorted = {} for eventName, eventData in pairs (eventUsage) do eventUsageSorted[#eventUsageSorted + 1] = {eventName = eventName, eventData = eventData} end table.sort(eventUsageSorted, function(a, b) return #a.eventData > #b.eventData end) iprint("1 = ", eventUsageSorted[1].eventName, "\n2 = ",eventUsageSorted[2].eventName, "\n3 = ", eventUsageSorted[3].eventName) eventUsage = {} }, 60000, 0) https://wiki.multitheftauto.com/wiki/AddDebugHook

Caching on clientside is important, that way serverside doesn't have to send data twice or send large amount of data. Yes, it takes longer to send the data and therefore other messages have to wait longer. (like opening a panel)

Have you considered to send only the groupID and let the client remove the data by itself?

Some data doesn't have to be updated every time. Like: playTime Server sends it to the client 1x (or maybe once per 30 mins). Then each client keeps per player the following data: { [player] = { serverPlayTime = 1453436465, clientPlayTimeStart = getTickCount() } } With that, at any moment the client can compute the playTime of itself and other players, without the need of a continuous synchronization rate with the server. local playTime = serverPlayTime + (getTickCount() - clientPlayTimeStart) There might occur some small differences over an amount of time (0.1 > 1 seconds ???), because the operation and execution time may differ: client VS server But that is just a little sacrifice for an enormous performance boost. This can also be applied to values like: "hunger", "time cycles", "health restore". (some values require a correction from serverside) Every update that has a continuous value change without randomization, can be optimised like that.

- It requires a lot of management. - Missing documentation, examples and benchmarks. (So I can't you all of them yet, but maybe you can give them to us by trying the functions out) You probably have to unsubscribe all the other players to make that work.

Using triggerClientEvent/triggerServerEvent instead of elementdata doesn't reduce network usage while using them the exact same way. In some cases it will be come worse or it might also improve depending on the context. trigger(Client/Server)Event is like an 1 way trip. That starts at 1 side and stops at 1 side. This trip uses more data than element data, for each client and server. But when some clients are excluded from this trip, data reduction can occur. Like triggerServerEvent(1 client to server) or triggerClientEvent(send to a % of clients, instead of all) When using elementData, you are enhancing an element with a specific property. The best practice of using this is to inform all clients about this specific property. This trip uses less data than trigger(client/server)Event, for each client and server. Before the latest update there was no data reduction possible, now there is: https://wiki.multitheftauto.com/wiki/AddElementDataSubscriber Before the addElementDataSubscriber, we had no way to stop the data from spreading to all clients and server. Each time the data was set on either side, all clients and the server were busy receive and process the data. It has a benefit of auto sharing the information new joiners. (this can also be seen as a downside) Nice to know, but it is not just picking the right tool for the right job. You need to reduce your data rate. A double player count shouldn't double the activity of the triggerClientEvent function. The data may scale, but the rate should remain the same.

There is. You can add a debug hook. https://wiki.multitheftauto.com/wiki/AddDebugHook This can be used to monitor the activity of MTA functions and events. Attach the hook to (in the voice resource): https://wiki.multitheftauto.com/wiki/SetPlayerVoiceBroadcastTo https://wiki.multitheftauto.com/wiki/SetPlayerVoiceIgnoreFrom Monitor the activity of all functions every 1min. Then log the result and restart counting. Do this for 30 mins. If the activity is for example around than 100 (per 1 min). Then you need to monitor a bit more. If the activity is higher than 1000 (per 1 min), you know something is wrong. Your developer must be able to do this.

ah sorry, I forgot to reply to your previous topic. It is not very complex to test that assumption, just disable voice and check if the problem still occurs. (fastest way would be out-comment all export functions in the meta.xml of the voice resource, you will see a lot of errors, but it will do it's job) <!-- --> --- If your assumption is correct, then still that doesn't mean that the resource is fully responsible. Since voice is just an API, that receive instructions from another resource. That will be a second objective in that case.

Please ask for support in your language section, for a higher chance of success. (because of language barrier) https://forum.multitheftauto.com/forum/94-other-languages/ Topic locked

no, each resource has it's own unique environment. But you can use export functions to retrieve variable values from other resources. https://wiki.multitheftauto.com/wiki/Call Keep in mind that: Tables are deep-copied. (loaded) Functions can't be past over. There is also elementdata, that can be act as an in-between storage place, but that has the same restrictions as exports.

Every line of code can be validated, if it does what it is suppose to do. By only looking at the end result will only give you one type of answer, which is: success or failure. Note, this ain't a lecture. But telling me that something isn't working, without actually trying to figure out what went wrong through various debug techniques doesn't sit right with me. I know that it can be a pain to debug everything (that ain't death staring at a debug console), but now it feels more like unwillingness. Please learn it, for your own sake.

In that case, swap these 2 lines: setTimer(function() local thePlayer = source local thePlayer = source setTimer(function() And then start working on the other functions. Like this one: function JAIL(thePlayer,commandName,sendToName,ido,...) And add a debug command: addCommandHandler("idozito", function () iprint("idozito:",idozito) end) So that you can monitor your table: idozito

Removing code is not the same as fixing code. You need to fix your first iteration.

This is still old. Source is not available in async functions (created by setTimer). Therefore you need to redefine it before using the async functions. local thePlayer = source There is no timer saved here.