mtasa-blue

mtasa-blue copied to clipboard

This is an attempt to add a new Lua version along with the default one. In this PR you can find an implementation of an interface allows to switch between Lua 5.1 and Luau in runtime. Can be considered as stable but due to the complexity can potentially contain issues that are expected to be revealed after the release.

lua5.1 and luau libraries are shared now for all build configurations. But Lua_Server and Lua_Client are static. It makes the system flexible on the one hand and resolves the name conflict on the other.

You can enable Luau for a specific resource for client, server or both.

<meta>	
	<lua client="luau" server="luau" both="luau" />	
</meta>

Due to the flexibility of the interface new versions of Lua can be added in the future.

One thing from my side: if possible, download vendor files from luau repository to do not bloat mta codebase and make future updates easier, example how you can do this you can find in mta bulletphysics pr :) it contains example for client and server side download of 3-rd party files https://github.com/multitheftauto/mtasa-blue/pull/1246

Unfortunately, we cannot use the default Luau code in the future. Some adjustments required in the code.

Unfortunately, we cannot use the default Luau code in the future. Some adjustments required in the code.

you can download luau and make a folder with patched files you copy onto luau files

This pr just show how much the mta team doesn't give a damn about this project

Instead of < lua > could be better to set lua version per script. Just like < script src="server.lua" type="server" lang="luau"/ > If lang is not set script uses 5.1 as default.

Instead of < lua > could be better to set lua version per script. Just like < script src="server.lua" type="server" lang="luau"/ > If lang is not set script uses 5.1 as default.

This goes against the current implementation whereby each resource has its own Lua VM (on client and server)

Instead of < lua > could be better to set lua version per script. Just like < script src="server.lua" type="server" lang="luau"/ > If lang is not set script uses 5.1 as default.

Disagree, if you have a need to mix Lua versions you should split it up in multiple resources.

Thanks

IMHO pros and cons:

Pros:

1. Good syntax and language
2. It is really popular and developed version or Roblox's lua. Maybe we can use their tools in future
3. Knowing developers made this (this user account hide people which we work many years)

Cons:

1. It won't work for our luac.mtasa (but you can cache scripts)
2. Diffrent VMs, like you can't write on Lua and Lualu in one resource (but i think exports for multiple resources are working)

My opinion - lgtm.

Not finished, but already usable https://github.com/dmi7ry/Luau-definition-for-MTA

Any ETA for merging?

I don't think it will ever be merged.

As elders of mta said: if will work, it will be merged.

Sometimes i don't know why TF is mta open-source if you can't do some improvements to codebase /:

You can, as long as the improvement makes sense and follows the guidelines. Testing and approval might just take a while. I personally do hope this makes it into the codebase as this will help with some of my projects.

Rather than complaining, you need to actually contribute if you want to see significant changes in MTA.

Yes, it's an open source project. No, this does not mean you can push things out on a whim without proper discussion or testing.

The details of this PR are rather vague and we don't know the implications of accepting this. Actual testing (and more importantly, evidence of such testing) needs to be shown in order to advance this. You could do this yourself, if you really want to help!

The person(s) who will ultimately decide whether this gets accepted will be much more willing to spend time reviewing, if you provide sufficient details; help them to help you.

Sometimes i don't know why TF is mta open-source if you can't do some improvements to codebase /:

Mta team can merge everything, but later someone need to care about it

From my own experience i see how people are unlikely to test for example BP, feature does not implement risky features but still require testing that almost noobody ddid

The problem lies in the lack of discussion from the maintainers. To date, there was not a single question or a remark about the PR from authorized members. Just terrifying and cold silence. And that is the reason why this PR is still just a draft.

Do you genuinely believe there is enough information in the initial pull request for a maintainer to want to consider picking this up? Why must the reviewer put in all the work for something you are wanting to implement?

Maybe because there is a noticeable community request for support for other versions of Lua, at least?

Maybe because there is a noticeable community request for support for other versions of Lua, at least?

Result: people are starting reimplement server, create custom forks to get what they want

Result: people are starting reimplement server, create custom forks to get what they want

Yep. Therefore, I doubt that we will contribute anything else from ReflectRP to MTA, but MTA's bugfixes. Because it's just a waste of time.

Result: people are starting reimplement server, create custom forks to get what they want

Yep. Therefore, I doubt that we will contribute anything else from ReflectRP to MTA, but MTA's bugfixes. Because it's just a waste of time.

I understand most of core devs are busy, but really? they didn't give feedback even for pull requests created YEARS ago

According to my observations, contribution (PR in particular) in MTA is considered as something that needed exclusively to the contributor. But this manner of posing the question is destructive.

Just food for thought. But try submitting a PR like this with such lack of documentation or testing in the "real world" and see if it doesn't get closed almost instantly

Just food for thought. But try submitting a PR like this with such lack of documentation or testing in the "real world" and see if it doesn't get closed almost instantly

1. What kind of documentation do you mean?
2. We initially created it as a draft so that anyone can try it or test it.
3. We actively use it on ReflectRP.
4. It's easy to test. Just take any existing project and enable Luau for each resource. It will work without any problems.

Documentation could cover almost anything, but in this instance I'd be referring to any notable changes (considering the size of the PR, regardless of whether most changes come from vendor) or regressions that may occur due to tests carried out; of which there are currently none.

Unfortunately your final point doesn't really add up considering the following note by the author:

It can be unstable and tests required.

As I've said, proper documentation and testing would be best. At this point it doesn't really matter who does that, but if you want this in MTA it's certainly beneficial. Reviewers rely upon tests to ensure they're actually testing things properly/consistently compared to others - this is how it works pretty much everywhere.

I want to admit that we don't really have any "test branch" which mta should have. we could use huge playerbase to test features, make in main menu so kind of information to switch to "testing" version of mta if you want to help mta bla bla bla. There we could put not properly tested features, features that require more tests. Because mta have some servers in its disposals, they could be used to get at least approximite estimation of how much time people had spent testing them, what crashed ect. I know someone might want to help mta, he plays mta but he is not aware of people pr's

I want to admit that we don't really have any "test branch" which mta should have. we could use huge playerbase to test features, make in main menu so kind of information to switch to "testing" version of mta if you want to help mta bla bla bla. There we could put not properly tested features, features that require more tests. Because mta have some servers in its disposals, they could be used to get at least approximite estimation of how much time people had spent testing them, what crashed ect. I know someone might want to help mta, he plays mta but he is not aware of people pr's

Nightly?

Unfortunately, we cannot use the default Luau code in the future. Some adjustments required in the code.

you can download luau and make a folder with patched files you copy onto luau files

This. Making manual patches all the time is not a great idea. And I'm sure keeping Luau up-to-date is preferred. Also, what are the changes made? Are they really necessary? Maybe we can do some workaround to avoid having to modify it.

I want to admit that we don't really have any "test branch" which mta should have. we could use huge playerbase to test >? features, make in main menu so kind of information to switch to "testing" version of mta if you want to help mta bla bla bla.

I guess there are nightlies, but even for that the PR has to be tested (and be somewhat stable).

---

So anyways, let's get the ball rolling.

I'd like this to be merged, unlike my attempt at LuaJIT (Also, Luau is better maintained, so it's superior anyways). My idea for testing is as simple as taking some opensource mta mod, running it, and testing if it works. If it does, then we can make a nightly out of it, and encourage a few servers to start using it (I'm pretty sure there'd be people willing to help, there always are, shoutout to them!).

On another note...

Before we do all of that, we need some netcode stuff too for checking if luau scripts are signed, until then compiled scripts are a no-go, executing untrusted bytecode is dangerous (Same reason why currently Lua scripts go thru MTA's site, they get signed too)

At the moment there is one inconvenience. The analyzer knows nothing about MTA meta files, so it throws errors on functions or variables declared in other files of the same resource. We plan to add such support a bit later. Most likely in March or April.

BTW, about testing. We've been using it for five months now. And during this time there was not a single error or problem with it.

I'd be more than happy to merge this once Luau is made into a submodule [or something we agree on, because I see we still don't use submodules....], because making changes to something that is regularly updated is just a bad idea [Why?.... CEGUI]. @botder [or not sure who to tag] any ideas on what should be done here? I guess we could go with the approach of creating a fork of Luau in the mta org, and downloading it directly [as we do with the fonts for example]