IIYAMA

Hey DiGiTal Summary: Y axis: Y axis position & compute pixel density(scale) X axis: X axis position drawText("$123456789", 140*sx, 648*sy, 0*sx, 0*sy, tocolor(0,0,0,255), 0.8*sy,"bankgothic") drawText("$123456789", <start position>, <start position>, <end position>, <end position>, tocolor(0,0,0,255), <scale>,"bankgothic") Take a look at your code. There are 3 types of arguments. start position (boundingbox) x y end position (boundingbox) x y scale (text) And an `invisible` one, which is the boundingbox size: boundingbox width = (end position x) - (start position x) boundingbox height = (end position y) - (start position y) You are currently not using the boundingbox. But that is something you could scale as well. When scaling and positioning, there is 1 important thing to keep in mind and that is to look at both of them differently. Because for some cases you want to scale position over the X and Y axis at the same time. X axis is used for the raw position. Y axis is used for the offset. local scaleValueY = sy_/900 local startPositionX = x_ -- right side of the screen local offsetX = scaleValueY * 30 -- calculate an scaled offset value local positionX = startPositionX - offsetX Your code drawText("$123456789", 140*sx, 648*sy, 0*sx, 0*sy, tocolor(0,0,0,255), 0.8*sy,"bankgothic") = drawText("$123456789", <10.2%>, <72%>, <0%>, <0%>, tocolor(0,0,0,255), <80% * 100%>,"bankgothic") I assume this is text placed above the radar. Now how to figure out the difference in methods? The only way is actually to see it for yourself. I made the following changes to reproduce your situation: Argument 2: Scaling the left offset over the Y axis. Argument 3: Starting from bottom to top, to improves `value` readability. (but doesn't change the outcome) Changed the text color to red. local scaleValueY = sy_/900 drawText("$123456789", scaleValueY * 140, sy_ - (scaleValueY * 252), 0, 0, tocolor(255,0,0,255), 0.8 * scaleValueY,"bankgothic") Your development resolution is: 1440 x 900 Check if both of them are aligned properly. If yes, then: Run both of examples at the same time with different resolutions and ratio aspects. Check the X position of both methods and see how those behave. Make some screenshots, which we can discus here.

@Bekao Nice first attempt. You are currently skipping: screen-ratio It might something to take a look at, since your UI will be stretched(in all directions) when other players have a different ratio. In some cases that is fine, but when you do that with an image, it will not look very nice. You are also skipping: "How to create a User Interface" An image is not a User Interface, but it can be come one with the right methods (which are not explained). Either edit the title or add the missing information.

@Tekken Not sure if you already have discovered it, but there is the DxTex tool that can be used to build texture files and compress them with the format you need. https://wiki.multitheftauto.com/wiki/DxCreateTexture Download link

I don't see this function guiGridListSetItemData (not Get), belonging to the following warning/error: In the code you just showed.

Both lines were already inside of your code, at the correct location (before I replied). You only had to change the column id. I have no idea how you managed to get that error.

Try to pass the data on column 0, instead of 1. Maybe that solves the problem. ? -- IN guiGridListSetItemData(transportGUI.locationgrid, row, 0, Data) -- -- OUT local DestinationData = guiGridListGetItemData(transportGUI.locationgrid, selected, 0)

You can check the variable value type. if type(DestinationData) == "table" then if (getPlayerMoney() >= DestinationData[5]) then --ERROR --[[ ... ]] end end

@[N]inja Moved your topic again to here https://forum.multitheftauto.com/forum/127-programação-em-lua/

@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.