DiSaMe

If you want to blame MTA, then the problem is not even related to relative positioning. The problem is that MTA doesn't have a scripting function readMyMindAndDoWhatIWantAutomatically().

In the game files, I guess?

Well, the only instruction I can give to you for now is learning to script and trying to make something yourself. Although I've had an idea to make some video player for a long time, I haven't done anything like that.

I said and I'm going to repeat it again: it's simple and perfect. Maybe you messed something up with text alignment, I'm not sure, but the fact is, the relative coordinate is always at the same position of the screen with any resolution. That makes it relative. There are no problems with them. If you tried to use them to solve some problem whom relative coordinates are not meant to solve, then it's your problem. You cannot blame the shovel just because it's very hard to chop down a tree using it.

You can, and it's easy, unless you use a narrow and very specific meaning of the word "video" (though I suspect that's what Akam is after too). In its general meaning, "video" is a sequence of images shown one after another to create an effect of gradual changes, such as movement. That is possible and plausible. If you use a narrow meaning, such as video of some particular format, then you need to make a decoder in a client-side script and it may be lots of work if you want to play a video of some existing complex format.

What "bad system"? Who failed? I've been scripting on MTA since 2008 (about a month after the release of MTA SA DM development preview) and haven't got any problems related to this. Relative coordinates are simple. Multiply them by screen size and you get absolute coordinates. That's not "disastrous" or "bad". That is clear and perfect. If that's not what you need to do some specific task, then calculate the absolute coordinates yourself, like I've done a few times.

Why would MTA deal with gameplay-specific functionality? There's no reason to do that. MTA allows the server owners to do what they want themselves and that is enough. If server owners don't make it themselves, they don't want it, and if they don't want it, implementing it directly into MTA is useless. MTA allows a more flexible approach than SA-MP does and that makes it superior. While SA-MP has a limited set of models, MTA allows replacing an object with a custom one, what means no limits. While SA-MP has a function for creating objects attached to player's bones, MTA has the function to get the position of the bone, which lets you do much more than limited specific function does. While SA-MP allows NPCs to replay previously recorded actions, MTA provides you with basic functions to control peds, making both recordings and proper interaction with physical world possible. So please, don't ask MTA developers to copy the worse multiplayer mod because not copying it is what made MTA better.

IIYAMA, I don't know what you're talking about. The size of the camera is 0 because camera is at one definite point. It doesn't have a size. megaman54, it's simple to figure out logically. When you are further from the object, it looks smaller. That means, if the distance is bigger, the observable size is smaller. The arithmetic operation whose result is closer to zero with bigger operand is division. So you need to divide the size by distance to get the visible size.

You use different indices for storing and retrieving the elements to/from the table: HouseID[row.id] = pickup local hx, hy, hz = getElementPosition(HouseID[i]) You use row.id in one place and i in another.

getElementMatrix getElementBoundingBox These two functions are enough to get the position where the top of the car is.

Since you add a and b (which you got from getCameraMatrix) to nAx and nAy and then pass these values as arguments to setCameraMatrix, you are basically adding the previous position to the new one. I guess you were going to add the player coordinates instead, something like this: nAx = math.sin ( newAngle ) * 0.2 + px nAy = math.cos ( newAngle ) * 0.2 + py By the way, math.rad(360) means a full turn, so the camera doesn't actually get turned. You need to put some smaller value instead of 360. And last, you pass 0 as the last argument (FOV) to setCameraMatrix. It's not a valid value and it's 70 by default. 0 means that you infinitely zoom in.

It's fine to think about that. Learning a programming language may take hours (or even minutes, if you're only after the basics). If you have some programming experience, learning new languages is easy. To learn Lua you can read this manual: http://www.lua.org/manual/5.1/ . The "Language" section describes the syntax and the features and the "Standard Libraries" section documents functions which come with Lua. If you are experienced enough in programming, you will be able to learn it fast.

It's not like we are going to believe you. First, why do you choose a script which, apart from being leaked, is more advanced than many other scripts you could learn from? And second, how can you learn by having someone else fix something that you didn't make? Seriously, I don't understand why you are doing this. Why do you want to make a server with leaked scripts instead of making your own? What's the point of opening an art exhibition if you have nothing of your own to show?

Of course this is not "intended", it's simply what physical elements are limited to. They cannot just move "on their own", they must have a syncer, because MTA server, being completely separate from GTA engine, does not have physics. It has to rely on the client it sets as the syncer to sync the information about the element, such as position. Since the objects far away from the player are not loaded, physics don't work properly there, so if there are no players near the element, it won't have anyone to sync it, resulting in element staying in the same position, no matter what the players see. The easiest approach to the solution for this problem is using setElementPosition server-side to simulate the movement of the ped. That's how I made it in NPC HLC to keep the peds synced when they go out of client-side sync range.

playSound

Since the script is client-side and the clients are not aware of commands typed in by other clients, client-side command handlers don't have the player argument: function drawTag( cmd, size, font, colorCode, teamColor, cR, cG, cB ) I don't agree. For a scripting beginner, it's good to experiment with many different things before focusing on a single project.

fileOpen fileRead fileWrite triggerClientEvent

Unless specified otherwise, string.find uses patterns rather than plain strings. Dot is one of the special characters and it means any character. You either have to disable the pattern matching a , e = string.find (zahl, ".", 1, true) Or escape the magic character a , e = string.find (zahl, "%.")

https://wiki.multitheftauto.com/wiki/Sh ... ture_names ?

This: local distance = 9999999 And this: if ( dist < distance ) then Since distance is always 9999999, you keep checking distance to every hospital against 9999999, which will always be true, therefore the result will be the one which is the last on the list.

It shows what the table looks like in the examples of dbPoll page. The value is in table[row_number]["column_name"]. In your case, it's probably like this: result[row]["LAST_INSERT_ID()"] To give the column another name (so that the expression string would not be used for it), execute a query with explicitly specified column name: local query = dbQuery(connection, "SELECT LAST_INSERT_ID() AS id") And the result will be: result[row].id

Of course it does, that means 10 ms isn't enough to get the result. In theory, no amount of time can guarantee that the result will be ready. If you want the result to be always returned, make the waiting time unlimited: local result = dbPoll(query, -1)

http://dev.mysql.com/doc/refman/5.7/en/ ... -insert-id

dbQuery dbPoll

You could attach them: attachElements And the cars will move as the plane does instead of colliding.