eAi

I guess that's possible. MTA 0.5's code is probably some of the worst you've ever seen. It's held together with sticky tape....

Yes, I use this method: spawnpoint={{0,0,3}, {500,500,30}, {-500,-500,30}} --creates table/array spawnpoint with a few spawnpoints. (between { and }, xyz) function spawnThePlayerOfWhoIDontKnowTheNameYouSee(player) local spawnNo=math.random(1,#spawnpoint) -- this will draw a random ROUND number, starting at 1 and ending at how much spawnpoints the table contains. local a=spawnpoint[spawnNo] -- put the chosen spawnpoint in a local variable. Makes it a bit easier spawnPlayer(player,a[1],a[2],a[3]) -- spawn the player at the given spawnpoint end addCommandHandler("spawn",spawnThePlayerOfWhoIDontKnowTheNameYouSee) -- usually, I don't use command handlers in these cases So it might still have some bugs/typo's, but this is how I do it. You should pull the spawn points from a map file, don't specify them in lua. Use getElementsByType.

You can't fade half way, no. You can fade half way then fade back again, which has been used to give the camera a red tint from damage...

Don't sound so defensive! It's a perfectly good example, I was just making sure he didn't waste time reinventing the wheel when there's code out there already.

You can actually directly export MTA internal functions, you don't even need to add any code to your resource. Purely a meta that exports getServerPort to http would be enough. http://development.mtasa.com/index.php?title=PHP_SDK provides some code that will make this pretty much painless, if you know basic PHP.

You need to use a combination of client and server scripting. Client scripts, as a rule, can't change anything on the server. They can communicate with server scripts using events though. Client scripts should be used as little as possible, as they're more open to abuse.

The shaking will be caused by precision errors in the vectors used for player positions. There's nothing you can do about that without rewriting GTA from scratch.

DP3 has an option for this in the settings, until then, use the SP setting.

http://development.mtasa.com/index.php?title=Event gives an overview of the event system. As I said, I can't see anything in your code that would cause this error. Do you have more code than this?

Use XML if you wish the data to be persistent or editable by administrators, otherwise use tables.

This error happens when you try to transfer data between client and server (or vice versa), i.e. using triggerClientEvent or triggerServerEvent. This happens when you try to send something that the client won't be able to understand - e.g. an xmlnode (the client hasn't got the server's xml files loaded, and vice versa) or a client-side element being sent to the server (the server doesn't know about client-side elements). I can't see anywhere in your code snippet that does that - is there more code? It is only a warning though, the rest of the data will be sent, you'll just receive nil (or maybe 0) instead.

Please don't abuse the ACL like that Add your own 'resource.YourResourceName.infinitehealth' ACL right, don't check for kickplayer etc. This allows the admin to configure it so that any group could have infinite health without giving them kickplayer access...

No Yes Yes

We may be able to make the event triggered for bullets vs the tank.

I hate to be annoying, but both your questions could be answered by quickly reading the wiki... onServerResourceStart doesn't exit - onResourceStart does though.

Spatial data (i.e. locations) should be stored in .map files so that they can be edited using a map editor.

Off the top of my head: x2 = x + cos(rotation) * distance y2 = y + sin(rotation) * distance

What?

What makes you think MTA supports rar files for resources? MTA supports resources as zip files and as folders. The latter is easier to work with while developing, the former is easier to distribute.

The server has a built in sqlite server, you don't need to connect to it - just use it.

Why do you want to use it?

Well, it's always worked. So someone must have been misinformed

setAccountData is fixed in DP3. Not that that helps you now...

Of course that will work! Why don't you try it (or read the documentation)? http://development.mtasa.com/index.php? ... andHandler "Multiple command handlers can be attached to a single command, and they will be called in the order that the handlers were attached." Sure, it doesn't explicitly say that it works with multiple resources, but you can assume that's the case with anything in MTA. Resources have no exclusive rights to anything (except things they might be given exclusive rights to in the ACL, but that's a bit different). That said, using helpmanager's GUI might be a better way to provide info to the user. We try discourage people outputting anything in the chat box that isn't chat.

No.