patrikjuvonen
commented
1 year ago 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.
MegadreamsBE
CrosRoad95
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
getElementDataetc... functions can accept a generic input parameter as the VM that wants to call it, for example if you callgetElementDatafrom 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 1Additional 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