DiSaMe

setPedCameraRotation setPedAimTarget setPedControlState

Oh, didn't notice that. Anyway, did you try outputting messages to see which parts of the code are executed when they should?

It doesn't work because the the order in which the code is executed is relevant. You use addEventHandler on functions which have not been created at the top of the script.

MTA map editor is for MTA, not for SA-MP or whatever else you could think of. Such questions completely unrelated to the intended usage of MTA clearly don't fit in MTA forums. Using the best multiplayer with almost unlimited possibilities just to get rid of all advantages later by converting the map to the inferior program's format is a big fail, after all.

I have a simple idea for script multithreading on both server and client: a Lua state for every thread. In addition to the main thread which runs MTA/GTA SA and Lua scripts, there could be 'secondary' threads running separate Lua states on different CPU cores. So one thread would still run synchronously with the game, while other threads run in parallel. A thread could be created from another thread using some scripting function. However, I'm not sure how much the performance would be improved. Since Lua states do not share the variables, the data would have to be sent from one thread to another using signals (another scripting function) and that means copying as much data as there is sent. If lots of calculations are done on small amount of data, then it's fine. But if you do very simple operations on lots of data, it will be useless, since the time spent on sending data from one thread to another could be used by performing the operation on one thread. In conclusion, script multithreading could be done, but it would have limited functionality, resulting in reduction of performance gain.

We don't need them. MTA has scripting for a reason. Seriously, we've had enough of this. First, bone attachments, then NPC traffic, and now, video player. If you are given powerful scripting capabilities, make use of them before asking for more.

addEvent addEventHandler triggerServerEvent

I didn't say I would release it, did I?

Actually, csmit195 tells the truth. Learning a programming language is one of the easiest and shortest, but also the least meaningful processes. For example, I learned PHP in a few hours (could have done even faster) and even though I have only done basic things with it, I know I could do something not so basic (such as forum). The point is, the programming language is just a tool. The tool doesn't make an artist. Experience does. It's not a few hours of learning PHP that makes me capable of scripting a forum. It's programming experience gained in years of programming and logical thinking. So if you just need to learn Lua, go to http://www.lua.org and read the manual. If that doesn't make the Lua scripting simple for you, then the problem is not about Lua. It means you need practice. Like many other activities, programming is not something you can "learn". It's something that gives you experience without reaching a point where everything possible is already done, since there are no limits. You can always go further.

Ratio of HUD element and screen widths is always the same. Ratio of heights is proportional to the aspect ratio. There's no direct way to get the aspect ratio setting, but you can workaround this with a function: getWorldFromScreenPosition

Cancelling onPlayerDamage has no effect. Use onClientPlayerDamage in a client-side script instead.

If you reload every full frame, then it will lag, there's nothing surprising about that. I've attempted to make a video player and even though it didn't come out well, there are many things to optimize. You see, the code works faster when you make optimizations rather than asking someone else to make them.

Well, if you provide some screenshots which clearly show how "disastrous" the coordinates are, I may change my opinion. But as for now, I don't see what's wrong, since I have been scripting on MTA for more than 5 years and have never had any problems with that, nor I have any idea how an error in the relative-to-absolute calculations could be made, so I view the system of relative coordinates as simple and perfect with no possibility of some point being in different positions on different resolutions.

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.