DiSaMe

"Much faster" how? "More stable" how? And what capabilities are you talking about? Lua is Turing complete language, therefore it is capable of solving any computational problem, just like Python. If you're talking about stuff in Python standard library which should not be allowed to be freely executed by scripts downloaded from servers, then they would have to be reimplemented anyway for security reasons. It's like with file functions, Lua has them but MTA disables them and instead provides its own file functions to prevent the scripts from messing with files anywhere outside resources directory. That said, I like both Lua and Python. They're my favorite scripting languages, but I still prefer Lua for its simplicity. I don't remember encountering stability problems and because of variety of criteria for performance, I can't see Python as "much faster" than Lua. Personally, I would like to see both Lua and Python in MTA, but since one language can already be used to do all the stuff, second one would provide little benefit, especially since potential security issues would need to be taken care of. I agree that ad populum is a bad argument though. "People say so" has never been an accurate way to determine the objective reality. That's why I don't use popularity as an argument except as a troll response to opponents who use the same fallacy

setElementPosition setElementRotation setElementVelocity setVehicleTurnVelocity Not saying the suggestion is useless, I'm just saying it can already be scripted.

This function has to be used for exactly what it does, sorting. It sorts the values in array (table with numerical keys starting at 1) in a particular order determined by the function passed as the second argument, or in increasing order if no function is given.

https://wiki.multitheftauto.com/wiki/Event

It sorts the values in the table. Isn't the name self-explanatory?

As a workaround, you can use either of these functions: isLineOfSightClear getGroundPosition Ped's center is 1 unit above the ground.

Exactly. Unlike SA-MP, MTA doesn't do this kind of stuff for scripters - instead, it gives them flexibility to do it themselves. That allows you to have your own models, your own GUI and lots of other things which you can't have in SA-MP.

MTA Lua and programming is NOT the same thing. C/C++/x86 assembly and programming aren't the same things either. Not a single programming language or scripting engine is the same thing as "programming".

Shader is a program for graphics processing, typically executed by graphics card. In MTA, shaders can be applied to specific elements. Which means different elements with the same model IDs may look different. Shaders make it possible to change the texture or reposition the vertices but I'm not sure about geometry shaders, the ones that generate new primitives, which is needed for full flexibility of this kind of model replacement.

some_table.i is the same as some_table["i"], not some_table

Call the function from client-side script and the object will be created for the client. But I think it's better to create server-side objects in different dimensions and put the player in dimension depending on gamemode choice.

Values of variables don't change themselves, so condition evaluates to true. Using getElementType will help, but it will still output a warning message if passed element does not exist. To avoid warnings, check element's existence with isElement before checking its type. However, even then the code is not guaranteed to work fine. If element gets destroyed and another one gets created, it's possible for new element to get the same ID (or memory address, I'm not sure what it is, but it doesn't matter) which the previous element had. If that happens, variables which held the value of previous element will start referring to the new element. So if one player quits and another one joins when the timer is still running, it's not impossible for the timer to do stuff with the new player. To guarantee that it won't happen, you need to kill the timer with killTimer when player quits instead of checking player's existence in the timer.

Resource cannot "run for 1 player" because resources don't "run for players". Resources run globally, and it's not clear what "running for player" is supposed to mean. For example, if chatbox message appears for one player and not for others, it means outputChatBox was called with that player as argument. It was not called "for player", it was just called, and player was passed a an argument. As you can see, there's no magic, just logic.

If you need the server to start the movement of ped for everyone, then yes, you need to trigger the event for everyone. MTA does not sync control states, and that's why server does not have ped control state functions.

You're probably only triggering the event for syncer.

First of all, it won't crash anything, second, it won't cause the stack overflow, and third, it doesn't have to do anything with server apart from file contents being read and sent to client. Last, but not least, while it's much more inefficient than it could be done, the code is still far from making noticeable performance decrease on its own. The problem is the way the camera fading is controlled. It's not a good thing to reverse the effect of fadeCamera(true) with fadeCamera(false). Instead, you should simply not call fadeCamera(true). Since this particular case is related to compiled script, the closest thing would be replacing fadeCamera function in that resource with the one that doesn't do anything. function fadeCamera() end You can add this script into that resource (preferably before other files in meta.xml, though that might not be necessary, depending on what compiled scripts do inside). Then, whenever that resource calls fadeCamera, it will call this empty function rather than the real one, which will prevent the resource from fading camera in/out.

https://wiki.multitheftauto.com/wiki/DownloadFile

There is no magical way to make everything work the way you want. If you want server-side physics to keep all things working outside client sync range, you need to script them. Updating the position in the way I suggested prevents something what makes look sync worse, something that makes peds appear in positions where they're actually not. It prevents peds from being shown moving when they're not moving. Does it prevent peds from moving? No, because they're not actually moving in the first place.

Using setElementPosition...

They cannot be given a syncer if they're too far away, but if you keep them visible in their true position, you will avoid the situation when ped is near the player but still doesn't take damage. If you want them to take damage in any case, then you should sync it yourself when onClientPedDamage event is triggered.

I use getElementSyncer (to find out if ped is unsynced) and setElementPosition, it puts the ped at specified position, updating it for all clients. Unfortunately, it also includes the clients that are far away and should not care, which is the waste of bandwidth when many peds are present, but inefficient is still better than broken.

I think this might be the result of lack of updates for unsynced elements. The ped that is too far from all players to have a syncer will not be updated. Its AI might cause it to approach the player and they will be seen nearby client-side, despite the fact that they're actually further. When I make peds, I take care of unsynced ones by updating their position via script.

local addCommandHandler_real = addCommandHandler function addCommandHandler(...) local added = addCommandHandler_real(...) if added then local commandName = ... outputChatBox("Added command: "..commandName) end return added end

Taking care of things instead of leaving them to programmer is one of the purposes of high-level programming languages. So it doesn't feel right when the program that uses Lua for scripting doesn't do that. Programmer is responsible to make sure that invalid arguments are not passed to the functions. But failure to do so doesn't crash MTA - instead, an error or warning message is produced. Similarly, it should also take care of other programmer errors it is capable of detecting. I don't even see the destruction of element without removing the event handlers as a mistake. I see event handlers as a part of element they're attached to, similar to element data. When element is destroyed, everything that's part of it should be destroyed. As for reuse of element identifiers, I wrote about it a few days ago in this forum. Failure to remove all references to element upon its destruction is definitely a programmer's mistake. However, it is possible for a host program that uses Lua scripting to avoid the reuse of element identifiers and reduce the negative consequences of that mistake. My own program that uses Lua for scripting uses full userdata wrappers (whose lifetime is managed by Lua) to point to data allocated in C. When C data is destroyed, pointer in the wrapper is set to NULL to indicate nonexsistence of that data. As a result, no data with a particular identifier will ever get created until the last reference to this identifier is destroyed. Therefore failure to clean up the variables might not be different from memory leak (data structures allow access of those values but algorithms might not do anything about it), while in MTA it affects newly created elements and causes incorrect results to be silently produced.

If they still use memory, isn't that a problem of MTA itself? It doesn't make much sense for MTA to destroy elements without cleaning up the information which will never be used again.