Jump to content

Dealman

Members
  • Posts

    1,421
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Dealman

  1. You're misusing the playSound function, first parameter is the filepath. Make sure you read the wiki thoroughly.
  2. You're trying to execute a client-side event that is called onBotSpawn. While in your client-side script, you have added an event and a handler for that event, but it's called onBotSpawn1.
  3. The 404 means the host was not found - make sure you've filled the necessary arguments properly. Did you export the function? If no, you may have to do that. On my phone atm so can't really review the code
  4. DX drawings return no element, so you have to use variables and then change these when needed.
  5. There is the server-sided getAllElementData but whether or not it gets data added natively I don't know. If it returns a table simply loop through it and output the key and value.
  6. This is a forum for help with scripting, what you're doing is asking us to make it all for you without doing anything yourself. You won't learn anything if you rely on others making it for you. You can't expect to have everything served on a silver platter. What you're asking for is simple stuff, look up some tutorials and use the MTA Wiki as marty also suggested. There you can find Team related functions.
  7. You should be able to get it via using getElementData. I'm not sure what the data is called but try "sizeX", "width" or "fWidth" I suppose.
  8. Can't you just use a simple bool? For example isShiftingUp. If it's true, start reducing soundSpeed to simulate the RPM dropping. If applicable you can also play some gear shifting sound here. Then once the shifting is done, set the bool back to false to resume the sound simulation?
  9. If you want the data to be "permanent", in other words - persist even if the resource is restarted you'll need to save it to a file. Alternatively using account data could work, but I personally would with storing it in a file. You could store them locally on every client and if an admin wants to access it you can always send it to them (client 1 -> server -> client 2). Data stored in a table would be lost when the resource is restarted.
  10. Please be respectful towards the people that play on your server and offer a secure method of storing their passwords. A lot of people use the same password for a lot of stuff which is a problem(and partially their fault). Making sure it's hashed and at least somewhat protected really is not hard, but shows that you respect their privacy.
  11. That is true, though if someone gets access to your database the salt is pretty useless. There are other ways obviously, you just need to find a solution that suit your needs. At work atm so can't really post in-depth replies - sorry.
  12. Nicely put @pa3ck. I think that's a bit over the top, but if you want to - go for it. Also remember you need the salt to be unique but the same for every player. So you'll probably want to generate the salt based on their serial or something similar. I believe the serial is dependent on your hardware so it can potentially change which could be a ptoblem.
  13. Not quite sure if I'm on the same page, but being able to finally modify dynamic objectsv(the .dat settings) would be a sweet implementation.
  14. Aye, just make sure you keep the salt on the server. Don't ever send it to any client.
  15. Don't ever use MD5. You don't decode it, you store the hashed password and preferably use a salt for added security(server-sided salt). For example: ABC123 then concatenate it with a salt(usually a random string). "ABC123blgvlkhxb743j" < example. Then you hash that. You hash the entered password BEFORE you try to log in and compare it. Same password will yield the same hash.
  16. You've made an infinite loop, the function createPostos() triggers itself over and over. Remove it from the timer and set the number of executions to 0 instead of 1.
  17. Interesting point, might be something the MTA devs could take a look at? I think you misunderstood him entirely
  18. Well, I guess, but that would result in a very choppy experience and wouldn't look all that great. By all means download the rear-view mirror script from the community and check out how he did it. Play around with it.
  19. Pretty much yes. Since you'll be switching to another camera matrix every consecutive frame. For example; Frame 1: Car Frame 2: Overtop view Frame 3: Car Frame 4: Overtop view And so on...
  20. Pretty sure it's based on the rear-view mirror script. Basically, you switch the camera every frame back and forth - effectively cutting your FPS in half(hence the awkward flickering of objects as well, another side effect). You then render the other camera on a render target. It's not efficient and not a very good solution, but as of now it's the only way to do it.
  21. Use triggerLatentClientEvent to transfer data(see fileOpen, fileRead, fileWrite, fileClose), since this is a latent event handler - it will not pause other traffic. Use getLatentEventStatus to get the progress, and then use dxDrawText and/or dxDrawRectangle as you please. You can probably find some already made on the community, but I sincerely doubt you'll learn much if you try and salvage those for code. Start simple, go from there.
  22. Good job, personally though I would've used collision spheres instead of markers. It would make it feel a bit more dynamic.
  23. Dealman

    a function

    And you expect us to help you? Not only are you being rude to someone trying to help you, you're outright lying to us. It's literally on the page he linked you, in bold text. It's described in detail how it works. Next time try and be a bit mature and appreciate the fact people are taking their time helping you.
  24. Dealman

    a function

    Well if you had actually read the wiki page, you would have seen that. So it's rather obvious you didn't look at it at all. With an attitude like that you're quite frankly not worth the time and effort to try and help, so good luck.
×
×
  • Create New...