• Content Count

  • Joined

  • Last visited

Community Reputation

23 Decent


About Noki

  • Rank
  • Birthday 12/04/2000


  • Location

Recent Profile Visitors

2,144 profile views
  1. Noki


    I have a job and I study at university full time. I barely have time to work on side projects, let alone think about gaming or even MTA. UCD is open source and if you want to make a contribution, go ahead.
  2. Noki


    You will most likely need to check your client's debug log. Check `C:\Program Files (x86)\MTA San Andreas 1.5\MTA\logs\clientscript.log` and scroll to the bottom. The registration button relies on the colour of the labels (which check if what you entered is valid). So make sure you fill it out properly and that the appropriate labels are green, not red or plain. In the server console, just use `aclrequest` and allow. I am not providing an ACL file as you should be setting up permissions properly. You can view what rights a resource needs using `aclrequest` and adjust it accordingly. It is not my responsibility to configure your ACL as it is different for you than it might be for me.
  3. Noki


    Probably when I feel nostalgic about MTA. Give it a year or two maybe.
  4. tocolor converts a series of RGB(A) numbers into hex form. It is just another way of representing colour, like HSV, HSL or CYMK is.
  5. Those commands are built-in to MTA. If you want to remove the ability for people to use them, you can do so by adding these lines in acl.xml under the Everyone and Default groups: <right name="command.login" access="false"></right> <right name="command.register" access="false"></right> I may be wrong and you only need to add these in one of the aforementioned groups, but to be safe, add them in both.
  6. It's been a while since I've coded anything for MTA or done any math even remotely hard. I have a player in a vehicle at (0, 0). The player is facing ahead at (5, 7). I want to move the player's camera to be at (-7, 5) or (7, -5) (not facing, the origin of the camera, like an offset). The player is able to look ahead fine without problems and the vertical levelling, but I can't seem to get it to offset properly. So far, the camera rotates around in a weird way and cuts around. Sometimes even in a circular motion. I have tried offsetting the camera's X and Y positions using perpendicular vectors (as demonstrated in the above picture). That didn't work. -- forceSide is a variable between 0.5 and -0.5 toggleable by a user -- Yeah, all this is running in an onClientRender event local forceSide = 0.3 -- For example local camPosX, camPosY, camPosZ = getPedBonePosition(localPlayer, 6) local rx, ry, rz = getElementRotation(getPedOccupiedVehicle(localPlayer)) local theta = (math.atan2(camPosY, camPosX) * (180 / math.pi) + 360) % 360 local nTheta if (forceSide > 0) then nTheta = (theta + 90) % 360 elseif (forceSide < 0) then nTheta = (theta - 90) % 360 end local perp if nTheta then local lX = forceSide * math.cos(nTheta) local lY = forceSide * math.sin(nTheta) perp = Vector2(lX, lY) end if perp then local c = Vector2(camPosX, camPosY) if (forceSide > 0) then c = c + (perp * math.abs(forceSide)) elseif (forceSide < 0) then c = c + (perp * math.abs(forceSide)) end camPosX, camPosY = c.x, c.y end -- All these other variables are of no concern setCameraMatrix(camPosX, camPosY, camPosZ + forceHigh, camTargetX, camTargetY, camTargetZ, roll) This code is messy but it's what I've currently got. I have used other methods to get the vectors to be perpendicular but also to no avail. What I want to do is for the player's camera to move horizontally out of the vehicle, but stay directly beside the vehicle (this is all in a cockpit view) no matter the rotation, coordinates etc. So it's basically offsetting the player's camera, but maintaining that it's looking forward and what not. Like that view where you see the front side fender and wheel of your car. Thanks.
  7. Noki

    DFF Clumps

    I had the same problem a few years ago. To my knowledge you can only have multiple clumps with things like lighting, vehicles, or more complex objects. Even then, they need to be exported a certain way to be compatible with GTA. I think @CodyJ(L) has experience with map conversions, and may be able to help you. Otherwise you can just ask about compatibility with GTA on GTAForums, or even ask Brian from CIT. If it works in single player as a simple DFF replacement, it should work in MTA. If you need to do anything further, it can be a bit more complex, if not impossible.
  8. The earliest available version on GitHub is this. I suppose if you looked hard enough and weren't afraid to ask around you could find some earlier revisions. Good luck.
  9. Noki

    MTASA for MacOS

    Nope. The MTA client is currently written for Windows. Trying to make it compatible with macOS's version of GTA SA is a whole other beast in itself. This question has been asked multitudes of times and has received the same response every time.
  10. Noki

    Server DDoS

    Bad idea. You're no better than them if you perform silly illegal attacks. Gather proof, report it to the MTA Team and they will most likely ban that person, given sufficient evidence.
  11. Looks absolutely awesome. I think the animations could be a little faster. It'd just make it seem a little more intuitive and more friendly.
  12. Top position. Word of mouth. YouTube (abuse the tag system to gain massive views). Launch from another community. The most important one in my books, is time coupled with consistency. Keep the server consistently up and for a long time. There will be times when the server has more players than usual, and there will be times when the server has less players than usual. But it's up to the owners and players to stick through with it for a while. People love things that are reliable and consistent, look at relationships or cars. No one wants an unstable partner or an unreliable car. Or you can just get really lucky. That always helps.
  13. Noki

    This is ridiculous..

    There is never a "best' way to do things. Are you going for pure code speed, or readability? There are so many factors that impact the best course of action. No single solution fits all use cases. You're going to have a very hard time working with other people and coding in the real world if you have that perspective. No, you're not being poetic. If anything, you're being pathetic. Part of programming is having an open mind to new solutions and different ways of approaching a problem. You're not doing either of those.
  14. You could implement it yourself in a number of ways. 1. Git hook. Write your own module that restarts the resource (using a folder name) for each file in a Git commit (filter out files from the same resource etc). It would be a bit tedious and require some hacky fixes to work. But it would work well with source control and keep things relatively neat. 2. HTTP uploading. Every time you upload a file (through HTTP), it calls the PHP SDK which calls a resource in-game that restarts another resource (resolving it from a folder name, or something). This is a very disgusting (also insecure and flawed) method and if anyone does it, I would be appalled yet impressed. 3. Constant scanning. Creating an application that constantly scans the resources folder for changes (using hash sums, for example) and restarts a resource (using a module or something that attaches to the server) every time a file changes. Note this is a terrible idea and would be cumbersome on server resources. 4. Create some sort of devilsh Node.js contraption that would do this for you. I don't want to write anything else because I'm scared someone might actually do this. But my favourite way is to just restart them when needed, at developer discretion, like what @Bonsai said. Any of these ways could introduce bugs (restart looping, restarting wrong resources, using too many system resources, etc) which could potentially create more problems than taking the time to write "/restart totallynotabuggyresource" in the console.
  15. Noki

    This is ridiculous..

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