Upgrading/Replacing Lua 5.1 with a better option

[ERAGON007]

Is your feature request related to a problem? Please describe.

It's very frustrating to write new resources for most of scripters. Lua 5.1 Is too simple to handle some kinda complex computations.

Describe the solution you'd like

There has been several releases being published by Lua (Lua 5.4) which include security patches and also performance enhancements. There should be at least a project dedicated for a Lua derivative to be worked on by developers [Lua5.4, Luau, GLua]

There are also other options such as JS, to avoid the trouble of compiling V8 project (which takes about ~4-8 hours to compile) we can also use already built V8 objects from projects like https://github.com/denoland/rusty_v8

A better solution is to use Wasm as a scripting solution, therefore developers can write their own resources in any language and then compile it to Wasm

Not updating Lua interpreter and also modules being kinda dead feature leaves some server developers to build their own fork, i pretty much most staff members are busy with their personal life etc...

maybe there can be new staff members just for reviewing PRs and issues? there are some PRs waiting for review/merge/testing for years now, and the author finally gives up on contributing

There are PRs like #2908 from @CrosRoad95 already existing for Wasm, but it needs to be as a project so other developers can take it seriously and actually contribute to it there was also an attempt to add V8 interface too which left abandoned after a while because of author being alone. By adding Wasm interface we can also get rid of Modules too

Describe alternatives you've considered

It can be 2 projects separated
1- Making an abstraction that calls the current functions like getElementData etc... functions can accept a generic input parameter as the VM that wants to call it, for example if you call getElementData from a Lua VM it could be like _getElementData(aGenericType callerEnv)
2- Adding the actual Wasm runtime and making it working on x32 too, and then adding Wasm functions based on project 1

Additional context

https://github.com/denoland/rusty_v8
https://nodejs.org/api/embedding.html
https://github.com/bytecodealliance/wasm-micro-runtime
https://github.com/bytecodealliance/wasmtime

https://blog.logrocket.com/webassembly-runtimes-compared/

Security Policy

• I have read and understood the Security Policy and this issue is not about a cheat or security vulnerability.

[patrikjuvonen]

Lua 5.1 Is too simple to handle some kinda complex computations.

Could you elaborate on these complex computations that you wish to achieve on MTA?

maybe there can be new staff members just for reviewing PRs and issues? there are some PRs waiting for review/merge/testing for years now, and the author finally gives up on contributing

This is off-topic, but I'll go at it anyway to provide some context (I could go on about this for hours, or even write a book). This may also be useful for any future issues.

It is a common misconception that the MTA team or staff (staff has actually nothing to do with our GitHub) are responsible for all work on MTA repositories. All contributors (members of the organization) are effectively soft maintainers since they have write privileges to some repositories like this one. Nothing rests on the MTA team alone; contributors can review, approve or reject, and merge pull requests to master. Testing and reviewing can also be done by anyone, quite frankly, albeit with some technical knowledge depending on the complexity of the pull request. We also have contributing guidelines which provides some information on how you can help us.

A lot of the time reasons for delays in pull request reviews or resolving issues is burnout, lack of time, interest, expertise or straight up competence. For example, we do not blindly merge pull requests and expect everything to be alright, that is not healthy for any open source project and we know that also from past experience. For example, I am not very good with C++, which limits my ability to review certain pull requests. Then there are pull requests that edit hundreds of files and there are thousands of changes to go through. That is very exhausting to even begin to work on, not to mention if you feel confident enough you've reviewed it thoroughly in the end.

Every pull request must be reviewed and tested with care to catch any obvious mistakes or issues that may complicate or break things down the line. Also, not every pull request is going to be accepted, and that can be for a number of reasons. A lot of the times when we do merge untested or unreviewed code for some odd reason, they end up being reverted quite quickly because there were issues that could have been caught by review or better understanding of the underlying code. To remind you, MTA is over 20 years old, and some of the code is as old, or at least we're getting close. MTA is not the easiest codebase to work on in the first place, which means work takes more time and reduces confidence.

It is also true that there are not enough active contributors, which stems from the fact that the MTA developer community is rather small, and many developers are growing up and have other things to do than actively maintain MTA. It is part of the lifecycle of any hobby project like MTA. From time to time we remind contributors that there are pending tasks but not many want to work on those issues which means it comes down to the MTA team members to eventually find the time, sit down and do the work for everyone. Which is also not very sustainable. This cycle leads to burnout which has been basically one of the top reasons for why maintainers have left the project in the past. It is an unfortunate situation because of the pressure contributors put maintainers in, and while maintainers try their best, it falls short in someone's expectation and then we get rants from both sides about how things are lacking.

Every now and then we come across some magicians who are able to deal with the codebase we have, and have good understanding of C++, ASM and reverse engineering in general. These people can only dedicate so much time, and they aren't invincible to bugs either, which means that sometimes when they introduce a bug, it may need more of their time, or another magician to spot and fix it. Take custom animations; it took Saml1er a long time to implement, and it requires understanding of IK, RW implementation and in depth reverse engineering. Yet there are still bugs with custom animations, which would require him to come back and fix them. That is very unlikely to happen. So those things wait for someone with equivalent proficiency to fix the issues. It is a lot to ask, and it is not the first time we've had an expert leave, and we're left to twiddle our thumbs.

I totally understand yours and others frustration with the constant delays, but I honestly have no solution to all of the above mentioned issues. I have personally accepted a lot of this as a fact of life, and that's what gets me through when I work on MTA.

As for what goes to WASM, it requires someone with equivalent understanding or time to learn to understand it, to review it and test it. It is also a risk from our perspective as it adds load for us to maintain yet another library. I would also like to point out that there are 476 bug reports in this repository alone, which would personally be my number one priority over new features, but very few actually work on bug fixes, and instead send pull requests that add new features. As nice as new features are, and we appreciate every single one of them, it is away from the time that could be spent on fixing actual bugs. I hope that someday we get more bugs fixed. But don't get me wrong, keep working on new features if you wish - just realize how much more there is to do than just features.

Also there are a number of good articles and blog posts online about the difficulties in maintaining open source projects. Might be worth searching and reading for some insight. Ultimately, none of the contributors owe you anything, so be happy with what you get.

• https://betterprogramming.pub/why-open-source-developers-are-burning-out-1a860854884c
• https://www.jeffgeerling.com/blog/2022/burden-open-source-maintainer
• https://www.jeffgeerling.com/blog/2022/just-say-no
• https://mikemcquaid.com/open-source-maintainers-owe-you-nothing/

[MegadreamsBE]

Is your feature request related to a problem? Please describe.

It's very frustrating to write new resources for most of scripters. Lua 5.1 Is too simple to handle some kinda complex computations.

Is it though? Or is it a lack of understanding how to actually optimize? A newer Lua version is not going to magically fix bad coding. I for example have been working on a GameBoy emulator for quite some time now which is playable at an acceptable frame rate. Sure, it performs a bit better in LuaJIT for example but the same bottlenecks cripple it no matter the Lua version.

Other bottlenecks are not even specific to Lua but rather the way some things are implemented in MTA with the addition of my CPU/GPU also having to run the game at the same time (I tested it in both MTA as the Love2d framework through a wrapper I wrote, thus the comparison I'm able to make).

[CrosRoad95]

i will add something to this discussion too:

• luau ( from roblox ) in my opinion most promising feature we can add to improve scripting experience, it can be just another layer ( i'm talking about type checking )
• javascript - proven to be hard to add due to lack of libraries, v8 tem does not provide prebuild binaries, your link is 64bit only, all builders on the internet are using 64bit only, compiling for 32bit is possible tho
• quickjs - i don't trust it, not supported but easy to compile and merge
• chakracore - they are providing all binaries we need, trivial to add ( already tested ), supported by community only.
• wasm - tested multiple libraries, wasm-micro-runtime is most promising because what we want is just ability to run .wasm files. It just runs them, compiles fast and is 300KB only. Other libraries such a wasmtime, wasmer ect are providing features we don't need, are taking more even 30-40MB of disk space
• we had a discussion about "mono" in mta, yet another option for scripting, forget about it :)

we have community projects

• haxe https://github.com/jushar/haxe-mtasa-typings - maybe some people like it, but i don't. it was fun project when i knew less about programming
• typescript https://typescripttolua.github.io/ - better than haxe and is supported, work simillar haxe
• slipeserver/slipelua - native c# server side, transpiled c# to lua clientside with features that make possible to eliminate .lua from client completly.

There has been several releases being published by Lua (Lua 5.4) which include security patches and also performance enhancements. There should be at least a project dedicated for a Lua derivative to be worked on by developers [Lua5.4, Luau, GLua]

security patches, performance enhancments not worth to implement, rather we should improve api so api-versioning will have bigger impact on performance and is both easy and safe to add. i don't think there is any bug in lua anymore

Summarizing, if i will be responsible for mta, i would do following things regarding programming:

1. partially integrate luau into mta, analyzer, typing part only.
2. add lua api versioning, cleanup api, take a look at vehicle functions responsible for damage, some are returning 4 ints, some asks for what index you want as number from 0, some as string, ect. this deacrese productivity
3. Add lua modules or some kind of way to add "global lua code"
4. and maybe, add wasm-micro-runtime so we can stop merging certain features for example recent gif player