IIYAMA

Both can be used. if type(value) == "number" then end Just tonumber is more forgiving, as you can also accept strings by converting them to numbers. local value = "123" value = tonumber(value) if value then end It just depends how forgiving you want to be. Do not do this: (2 function calls) if tonumber(c_buffer) and tonumber(c_buffer) >= 0 then end But do this: (1 function call) c_buffer = tonumber(c_buffer) if c_buffer and c_buffer >= 0 then end If you can reduce function calls, by just writing it a bit different without messing with the programming flow, you should take it.

Also if you solve this issue, your bandwidth should technically go up:

? Afk you do not have to modify anything. Copy > past > run

No the one from mrtasty his code.

Can you show me the results?

At first yes you would expect that. But there is one thing that isn't taken in account. If one of the other clients does this: setElementData(root, ":O", false, false) In that case, even if the value doesn't change, the value of this specific client must be updated. With other words it does not matter if the value is the same. All clients their value must be forced to set to the last known value. I don't know if the event is fired or not. But it is just as bad for the network.

The event DNL:Reparar didn't trigger that much. Are you sure this is the code that called the setElementData so much? It is about the execution quantity after all. Make sure to run @MrTasty his code to figure out if where it is actually located.

@dener189 It looks like the fuel system has changed the value to a string. At least not within the code you are currently showing. local fuel = tonumber(getElementData(v, "fuel")) or math.random(10,25) Oh and btw, using this code will ruin your network. So use with caution. You do not want this to happen: So, my recommendation: if getElementData(v, "fuel") ~= fuel then setElementData(v, "fuel", fuel) end

I know this is it because: Most people do not know that synchronize is enabled by default. bool setElementData ( element theElement, string key, var value [, bool synchronize = true ] ) When the synchronize argument is enabled, each function call represents data that is transferring between all clients and the server. And your server said: Those are network messages. Isn't a coincidence? And if I were guessing what so much messages is producing, then this code would look a bit like this situation: addEventHandler("onClientRender", root, function () setElementData(root, ":O", true) end)

Add some debug lines to your code and debug it, else you will get nowhere. And we will not be able to help you... You don't know how to do that? There is a tutorial just for that.

local container = createElement("bots") function spawnBot(...) local bot = exports.slothbot:spawnBot(...) setElementParent(bot, container) end addEventHandler ( "onResourceStart", getResourceRootElement(), function () spawnBot(4845.0258789063, -1713.5711669922, 59.668750762939, 0, 108, 0, 0, teamLV, 31, "guarding", true) end) addEventHandler( "onBotWasted", container, function() setTimer( spawnBot, 5000, 1 , 4845.0258789063, -1713.5711669922, 59.668750762939, 0, 108, 0, 0, teamLV, 31, "guarding", true ) end ) Something like that. @bencskrisz

Yes, this is what is killing your server [19-08-03 23:39:35] INFO: { ["DNL:Reparar"] = 1, GGbindMouseRoll = 11, SirenSinc = 2, addVoice = 2, onChatMessage = 1, onColShapeLeave = 5, onConsole = 8, onElementClicked = 2, onElementColShapeLeave = 5, onElementDataChange = 20232, onElementDestroy = 7, onElementStartSync = 1, onElementStopSync = 1, onMarkerHit = 9, onMarkerLeave = 5, onPlayerClick = 6, onPlayerCommand = 8, onPlayerContact = 8, onPlayerMarkerHit = 8, onPlayerMarkerLeave = 5, onPlayerMoneyChange = 2, onPlayerTarget = 33, onPlayerVoiceStart = 2, onPlayerVoiceStop = 2, onPlayerWeaponSwitch = 2, removeAnimation = 17, removeVoice = 2 } As in elementdata changes. So check that out.

Tell me the result of this code: (serverside) Note: Untested code local eventList = {} setTimer(function () if next(eventList) then outputDebugString(inspect(eventList)) eventList = {} end end, 10000, 0) addDebugHook( "preEvent", function ( sourceResource, eventName, eventSource, eventClient, luaFilename, luaLineNumber, ... ) eventList[eventName] = (eventList[eventName] and eventList[eventName] + 1) or 1 end) Test what the first output is in the log files. (because this is the first time I am using this event) If everything is working then: Test with a low amount of players. Test with a high amount of players.

Either a bad resource (< check that) or a DDOS attack if somebody doesn't like you.

@majqq A 1.5sec delay between chat messages, is not very user friendly. It better to accept messages with a burst rate. Because sometimes you wrote something, but it is not complete or incorrect. There are 3 things you can do to make it more user friendly. (And spammers user unfriendly) 1. Each message has a message rate value of 1. When the rate value becomes greater than 3. Disable the input. Each message represents 500ms. So in total you have 1500ms of burst power. So you can send 3 messages after each other without delay. The messages rate value will decrease with 1, every 500ms. (So +1 message every 500ms) Before you have your 3 burst messages back, it will take 1.5sec. 2. After writing your first message, you wait 400ms. Every message that is typed within that 400ms is included in your first trigger. Then the 400ms timer is over and you push all the messages that have been written within that timelimit. (which is just another buffer) 3 Warn people when spamming. (warn the user 1 time, but still send the message) After the warning and still spamming > Punish people when spamming. Mute for X amount of time. Note: Do not disable the input, because if somebody is using macro's/bingkeys or something like that, you need to punish them extra hard. Every time they spam when muted. Multiply the mute time by 1.2. (of the previous +20% mute time, which becomes even more punishing over time) 60 sec > 72 sec > 86,4 sec > 103,68 sec > 124,42 sec > 149,30 sec On the server You also also need a buffer. This is just a timer that waits for an amount of ms when there is input. - New message - Start buffer timer. (0.5s) - New message - New message - New message etc. - Buffer timer is over. > Send messages to the other clients.

No, I mean in this case a RAM buffer. As in waiting for enough data before processing it. This indeed is also something which can be compared to a network buffers, but I was not talking about that in my last reply. I was talking about how your server is writing logs intern. If you are going to collect player debug information and send it to the server. Then yes you might very well consider using a buffer for preventing the network from being overloaded. A latent event will make sure the messages will not block your regular output. (even though it can still happen if there is too much going on) https://wiki.multitheftauto.com/wiki/TriggerLatentServerEvent https://wiki.multitheftauto.com/wiki/GetLatentEventStatus

@majqq There is a buffer, it will only start writing when the buffer reached an amount of data it will start writing. So by default it should be fine. Just what are you going to log? That is the real question. Slots do not tell you how much performance your server has. In some cases I would even consider slots a scam, as the player count is just a performance-usage multiplier X the resources. But there should be a few good deals out there... at least I hope so. The thing that matter: CPU RAM (1GB should be enough but better to have 2 in case of a memory leak) SWAP (when you run out of ram, you will be using your storage as ram, this is called SWAP. It is very slow.) Storage (SSD recommended, especially when you are not having enough RAM while doing heavy workloads) You do not need a lot of storage for MTA. With how many other clients are using the server. Network speed and bandwidth.

So what is your point ALBANDER? Even if you detect the software or hardware, then I wouldn't be able to play MTA any more because you want to punish me as well for having logitech software installed. It is not like the software is made just for macro's, it more or less a feature of it. If you want to block macro's, then do it based on key pressing. Record in your server which key combinations players use and block the once that are not allowed. Note: It is not ethical when you do not inform your players beforehand about this type of data collection.

Updated the topic to latest version. P.s. if you are interested in always receive notifications when the newest version comes out. There is a feature on the forum called: following. This allows you to keep track of updates from a selected topic. It is located on the right + top corner of where the topic starts.

Ah yea, did send you it.

You are talking about having encoded files on the client his hard drive? Probably there is no way of avoiding that. It might be possible to request the keys from the server, but that also means that you will have to encode and decode the keys while this is being transferred over the network. Even so the risk is more in the client editing the files, so you still have to compare hash strings before loading it. When 1 of the edited files have been loaded, all other files are being at risk. Even the eventhandlers on serverside and all the elementdata.

If the money is stored on for example the column money then you could access it like this: local money = tonumber(result_account.money) if money then else -- something went really bad ;[ end If your mysql "money" column is not correctly set-up to already fill in the money as a 0. Then this is also an option: local money = tonumber(result_account.money) or 0

It seems like you copied some wrong (invisible) characters in to your code. (can happen with the forum text editor, not sure what the issue is) I cleaned it for you. addEvent("PlayerCheck", true) function PlayerCheck(player, username, password) if type(username) == "string" and type(password) == "string" then local qh_account = dbQuery(db, "SELECT * FROM accounts WHERE username=? LIMIT 1", username) local result_account = dbPoll(qh_account, -1)[1] if result_account then if result_account.password == password then else end else end end end addEventHandler("PlayerCheck", root, PlayerCheck)

@Mr. Maxilian Afaik yes, but you still need to (manually) debug it in order to figure out it is 100% working. As being a human I can overlook things after all.

Ah yea. (and I also wrote a wrong example. ops sorry) How about something like this? if type(username) == "string" and type(password) == "string" then local qh_account = dbQuery(db, "SELECT * FROM accounts WHERE username=? LIMIT 1", username) local result_account = dbPoll(qh_account, -1)[1] if result_account then if result_account.password == password then -- success else -- wrong password end else -- wrong username end end