• Content count

  • Joined

  • Last visited

Community Reputation

14 Decent


About Noki

  • Rank
  • Birthday 12/04/00


  • Location
  • Occupation

Recent Profile Visitors

539 profile views
  1. It took me a second to realise that they weren't your words, and you were quoting someone. Numerical incremental loops (for i = 1, 100 do, while i < 100 do) are generally speaking the fastest. For tables with numerical indexes larger than 100 items, pairs was faster than ipairs, but lower than 100 ipairs was faster. And when it comes to tables with non-perfect keys (strings, not sequential, etc) pairs is the only way to go. @John Smith, you can't really say it's X amount faster without providing context to that answer. How big was the table? Were you running any operations within the loop? As I said in the last paragraph, it all depends on what you're doing. It really comes down to what you're doing. In most other languages, there are arrays, which have numerical indexes and there are lists, which can have non-numerical indexes. Terminology differs between language, but you get what I mean. Each has a different use scenario. However, in Lua, we're given just a table, which can be seen both as a curse and as a blessing. We can use numerical indexes and treat tables like an array, or use non-numerical indexes and treat tables like a list, or we can do both! Personally, I don't usually iterate over tables with non-numerical indexes unless I have to. I prefer to use my tables (with non-numerical indexes) as a lookup, as opposed to something that needs to be iterated over. This guy has no idea what he's talking about. I mean, he says "medium scripter". What the hell is that supposed to mean? He's most likely just read some statistics on a StackOverflow answer and is going around parading his newfound knowledge. This isn't a black and white issue and really depends on what you want to achieve. Yes, incremental loops are faster in every way, but sometimes it can be cleaner to use ipairs/pairs (not having to access the original table's index to lookup, breaking on the first nil pair, etc).
  2. Those functions are baked into MTA and aren't contained within any resource. To disable it, you need to edit your acl.xml. Simply go to where it says '<acl name="Default">' and add the following underneath: <right name="command.login" access="false"></right> <right name="command.register" access="false"></right>
  3. It's been a thing since August. I don't see it getting taken down anytime soon. The reason FiveM got taken down was because it used GTA:O code (the sync). GTA Network uses their own sync.
  4. That's a terrible security measure and I strongly advise that you don't do that. I recommend setting up ACL permissions for each individual resource that requires them. Kinda off-topic but a strong disclaimer for anyone using these resources. It's not my fault, or the fault of these resources, if your server is insecure.
  5. Over the past year a lot of people have been migrating from TeamSpeak, Skype and IRC to Discord, myself included. Some great features are that you don't need to host it yourself, setup is very quick, easy and painless and there is support for both voice and text transmission.
  6. Yes @RyuMaster. You need to give UCDaccounts permission to use function.addAccount. I should put that on the setup instructions.
  7. script security

    I do recall hearing from someone on MTA's IRC server that MTA uses element data for things like position, entering a car etc. But I don't think you're able to set those values through setElementData, for obvious reasons. So to answer your question, yes. Well, as far as I'm concerned anyway. You'll need to look at the source code or ask a developer for absolute confirmation.
  8. script security

    The best way to secure your server from "rogue clients" is to not use element data at all. Or at least don't allow it to be set client-side. But you would be safer not using element data at all. As stated in that wiki page, "don't trust anything from the client". Write your scripts as if you're trying to break them (ie putting strings in where integers are supposed to be, use newlines in input, don't submit any input, spam buttons and commands, etc). Validate every piece of data extensively. You're right, I don't think there's a way to fully test that as it seems to be faking events. So unless you injected some code into the client (which is a job in itself nowadays) you can't really test it. But if you did manage to inject into MTA, you would probably be finding more important security flaws.
  9. Reminds me of Arma 3 Wasteland. Looks good. I'll check it out after Christmas sometime.
  10. I'm not fully convinced your copy of UCDlogging is entirely original. Please clone the repo again and try again.
  11. UCD is now being actively developed again. Alright, I feel as though it was lazy of me to release it in the state it was in. I definitely care more about FOSS than that. So I've decided to make UCD open-source under the MIT License. It will continue to be maintained and actively developed by Risk and myself. I will also be officially launching the server sometime within the next few months. I have also included instructions on how to set the server up on both Linux and Windows, and they're view able in
  12. Check your PMs. We'll sort it out there.
  13. I'll admit it's a bit half-assed, but this was never intended to be released and I never organised it properly to be released.
  14. Glad to hear it. Giving it a fork or starring on GitHub it is a good way to express your appreciation too. Select the punishments for an account > Send them to the client > Display them in a GUI.
  15. There isn't a command for that. However it's straightforward to create as all that's needed is the punishments table.