Dealman

You're misusing the playSound function, first parameter is the filepath. Make sure you read the wiki thoroughly.

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.

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

DX drawings return no element, so you have to use variables and then change these when needed.

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.

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.

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.

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?

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.

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.

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.

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.

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.

Aye, just make sure you keep the salt on the server. Don't ever send it to any client.

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.