Jump to content

IIYAMA

Scripting Moderators
  • Content Count

    5,495
  • Joined

  • Last visited

  • Days Won

    119

Everything posted by IIYAMA

  1. I don't see this function guiGridListSetItemData (not Get), belonging to the following warning/error: In the code you just showed.
  2. 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.
  3. 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)
  4. You can check the variable value type. if type(DestinationData) == "table" then if (getPlayerMoney() >= DestinationData[5]) then --ERROR --[[ ... ]] end end
  5. @[N]inja Moved your topic again to here https://forum.mtasa.com/forum/127-programação-em-lua/
  6. @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...)
  7. Your current code contains fragments from a decompiled script. Locked
  8. Moved to here: https://forum.mtasa.com/forum/127-programação-em-lua/
  9. Moved to here: https://forum.mtasa.com/forum/127-programação-em-lua/
  10. 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
  11. 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 val
  12. IIYAMA

    Lag issues

    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,
  13. IIYAMA

    Lag issues

    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.
  14. IIYAMA

    Lag issues

    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.
  15. IIYAMA

    Lag issues

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

    Lag issues

    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.
  17. IIYAMA

    Lag issues

    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) .. " sou
  18. IIYAMA

    Lag issues

    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)
  19. IIYAMA

    Lag issues

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

    Lag issues

    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
  21. IIYAMA

    Lag issues

    - 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.
  22. IIYAMA

    Lag issues

    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
  23. IIYAMA

    Lag issues

    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.
  24. IIYAMA

    Lag issues

    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.
  25. IIYAMA

    help in code

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