DiSaMe

Client-side elements do not exist in the server. You can't use the client-side elements as valid element values on the server.

Accounts used to be stored in XML files, but now the database is used. They are identified by name. If you want to have the two systems of accounts connected, then you need to use addAccount/removeAccount alongside the query which creates/destroys the account record in your MySQL database, and then you can modify your logPlayer function in such way that the player would be logged into the account of built-in system and also linked to the account of your database in some way. But to me, connecting the systems seems messy. Why would you do that? You could either use one system to store the data or two systems for different purposes. For example, I'm making a gamemode with a custom account system which stores the data of the players (weapons, money, etc.) and I will also be using the built-in account system to log in as admin. The two systems used for different purposes aren't linked to each other in any way (for example, I can log in/out as admin while still using the same game account) and that is much better than having the gameplay achievements tied to the admin or moderator status.

They are separate resources. Just unzip them like Freddy said. Then start lavafl_ctrl and it will start lavaflood too. I made them separate because someone may want to do something more than lava simply rising (such as gamemode where you have to escape the flood).

function draw3DText() local x, y = getScreenFromWorldPosition(xpos, ypos, zpos) dxDrawText("Text", x, y) end addEventHandler("onClientRender", root, draw3DText) This draws the 3D text at position xpos, ypos, zpos (you have to replace them with actual coordinates).

Why don't you just use the account functions then? It doesn't really look well with two systems of accounts mixed that way. There's no such thing as "account element", and all accounts of MTA account system are stored into the built-in database of MTA server.

fileOpen fileClose fileRead fileWrite string.byte string.char

If cars table is {{411}, {412}}, then v will be {411} and {412} and getVehicleNameFromModel only accepts numbers, not tables.

getScreenFromWorldPosition dxDrawText

All scripts of the same resource on the same side (server or client) share the same global variables. That means you can call functions or just use variables in the whole resource as long as they are not defined as local. You can also call the exported functions of the resource from another resource. More information call

Cycle through all points using for loop, Calculate the distance to every point and get the one which has the shortest distance.

callRemote

'break' keyword escapes the loop at the point it's reached, preventing the code execution from reaching the 'return true' line.

Matrix is probably the most intuitive representation of element's position and rotation. matrix[1] (X) vector points to the right from the element. matrix[2] (Y) points to the front. matrix[3] (Z) points up. matrix[4] is the position of the element. The first example in the getElementMatrix page may help you to understand how it works.

getElementMatrix setElementMatrix

Makes no sense. Replaces destroyElement by a function which sets its own local variable to nil, therefore doing absolutely nothing.

If Ped is defined, then it probably works fine - it correctly draws the text outside the screen You use screen width as Y coordinate and that is under the bottom of the screen.

The handler will be removed.

DX drawings are not GUI elements. DX drawings do not exist. DX functions do not create anything and because of that, they do not return any element. All what DX functions do is changing the colors of pixels on the screen. Our brains receive the information about these pixels and interpret some areas as distinct objects, creating an illusion of DX drawings' existence

getVehicleTowingVehicle Isn't that what you actually need?

The X coordinate is -3000 on the edge of the western side and 3000 on the east. The Y coordinate is -3000 in the south and 3000 in the north.

According to the meta.xml page, the caching option is only for scripts. To prevent other files from being saved, you can make a script which deletes them using a function: fileDelete But whatever is not saved has to be redownloaded every time when joining the server. Not really good for vehicle mods. The best possible approach is probably encryption. You upload the encrypted files to the server, then send the key using triggerClientEvent and the client-side script uses it to decrypt the content (using the file functions). This way only the key will have to be resent every time and it's not much. Anyway, there's no 100% reliable way to prevent the client-side files from getting stolen. Whatever appears on the client must have to be downloaded by the client.

Because you're trying to get element which the player is attached to. To get the elements which are attached to the player, use this function: getAttachedElements But I'd recommend to use tables to keep information which player the blip belongs to. Then you can just take the blip value out of the table and destroy it when the player quits. In addition, you're needlessly getting the name of the player and then getting the player from name. Lines with getPlayerName and getPlayerFromName could be simplified to an expression: player = source And finally, it's better to make the variables local by using the 'local' keyword. Local variables are faster and only exist in the scope they were created in (such as function). So the code should look something like this: player_blips = {} --creating a table function playerJoin() local blip = createBlipAttachedTo(source) player_blips[source] = blip --storing the blip into the table under the player element key end addEventHandler("onPlayerJoin", root, playerJoin) function playerQuit() local blip = player_blips[source] --retrieving the blip from the table destroyElement(blip) player_blips[source] = nil --since we don't need the information about the blip in the table anymore, we remove it to free the memory end addEventHandler("onPlayerQuit", root, playerQuit)

Those "control lists" aren't even "lists". Every control is specific, most of the time only having an effect either on foot or in the vehicle. That doesn't even have much to do with MTA - it's the way GTA SA itself works. If the same controls were used, then they would have the same input bindings too. What's more important, setPedControlState function itself is for usage both on foot and in the vehicle. Universal functions are better. Having multiple different attachment functions for every combination of elements isn't as good and simple as single function attachElements is. So why make the ped aiming different?

This is so great. Incredible. I want it in MTA so much - I made a program which converts LC and VC from GTA3 and GTA VC to MTA, but since MTA keeps crashing or just working improperly with many custom models loaded, I can't test everything and until I do this, I will probably not release that program. MTA:Eir would allow us to have LC, VC and SA all in one map, right?

Oops, sorry, didn't read carefully.