Delete lua5.1 DLL

[G-Moris]

This will make it difficult to reversing the fork code and use multi-cheats for forks with Lua injectors.

[DmitriyColeman]

It's useless..
The official version of MTA is always built with Lua as a static library, not a shared library.

Cheaters can find all the functions they need for their dirty work only by signatures, so the problem of protecting these functions lies directly with the fork.

[G-Moris]

It's useless.. The official version of MTA is always built with Lua as a static library, not a shared library.

Cheaters can find all the functions they need for their dirty work only by signatures, so the problem of protecting these functions lies directly with the fork.

It's useless to compile as a separate library on forks

[DmitriyColeman]

I agree, but it seems to me that this is already a direct problem of a specific fork if its developers are not able to do such a trivial thing.

Also, as I know, MTA doesn't support forks.

[G-Moris]

I agree, but it seems to me that this is already a direct problem of a specific fork if its developers are not able to do such a trivial thing.

Also, as I know, MTA doesn't support forks.

If MTA didn't support forks, it wouldn't have created a Full AC for forks.

This PR is not a problem, as we both know that the official version of MTA is always built using Lua as a static library.

This will remove support for the old, Lua injectors. Which used this DLL in 90% of cases.
Which somehow still work.

[AlexTMjugador]

If MTA didn't support forks, it wouldn't have created a Full AC for forks.

Indeed, as far as I can tell, MTA doesn't support using its AC in forks, in the strong meanings of that word. From the MTA Wiki (see also this other article):

AC is generally unsupported for forked projects and may be dropped entirely in the future. This means that you generally cannot rely on the MTA anti-cheat for your fork. We strongly advise that you write and implement your own AC.

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects.

Out of the box AC capabilities in forks are thus best viewed as a courtesy the MTA team gives without strong guarantees rather than some sort of actual support.

[G-Moris]

If MTA didn't support forks, it wouldn't have created a Full AC for forks.

Indeed, as far as I can tell, MTA doesn't support using its AC in forks, in the strong meanings of that word. From the MTA Wiki (see also this other article):

AC is generally unsupported for forked projects and may be dropped entirely in the future. This means that you generally cannot rely on the MTA anti-cheat for your fork. We strongly advise that you write and implement your own AC.

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects.

Out of the box AC capabilities in forks are thus best viewed as a courtesy the MTA team gives without strong guarantees rather than some sort of actual support.

Ok.
This does not affect the of this PR

[AlexTMjugador]

This does not affect the of this PR

Yes, that's right. Removing this DLL may or may not be a good idea, regardless of the status of AC support in forks. I simply wanted to clarify what that status is.

[G-Moris]

This does not affect the of this PR

Yes, that's right. Removing this DLL may or may not be a good idea, regardless of the status of AC support in forks. I simply wanted to clarify what that status is.

I think this is a good idea, as the official MTA shows

[qaisjp]

The only hesitance I have with this change is that, as part of updates, people will have to always re-download the Lua stuff even though it never changes. How big is the Lua DLL?

[G-Moris]

The only hesitance I have with this change is that, as part of updates, people will have to always re-download the Lua stuff even though it never changes. How big is the Lua DLL?

~400 KB
This is already used in the official MTA.

[qaisjp]

Oh, are you saying the official builds are already statically linking Lua but the GitHub code doesn't have that?

[G-Moris]

Oh, are you saying the official builds are already statically linking Lua but the GitHub code doesn't have that?

Yes

[qaisjp]

Then I'm onboard - let's match it here.

I'll take a look at this on the weekend if I remember. Before merging, I'd just like to compare this change against the official build server, to make sure we're not missing anything

[G-Moris]

Then I'm onboard - let's match it here.

I'll take a look at this on the weekend if I remember. Before merging, I'd just like to compare this change against the official build server, to make sure we're not missing anything

@qaisjp

[qaisjp]

We would only want this change to apply to Client and not Server, since it looks like Server is dynamically linked today?

E.g. Custom modules depend on separate Lua DLL

[AlexTMjugador]

E.g. Custom modules depend on separate Lua DLL

The Lua library situation on the server is, to me at least, a bit counterintuitive. When I was working on a proof-of-concept Rust SDK for server modules, I had to link against deathmatch.so on Linux for the module to use the MTA Lua library symbols, but on Windows those symbols are indeed provided by a separate lua5.1.dll.

So the placement of Lua symbols on the server libraries has never been entirely consistent across platforms. That said, I agree that it's probably best to keep the currently observable server interfaces intact in this regard, as breaking already compiled modules for either platform is quite a steep ask.