multitheftauto / mtasa-blue

Multi Theft Auto is a game engine that incorporates an extendable network play element into a proprietary commercial single-player game.
https://multitheftauto.com
GNU General Public License v3.0
1.38k stars 424 forks source link

Move hardcoded functionality to resources #2949

Open CrosRoad95 opened 1 year ago

CrosRoad95 commented 1 year ago

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

as we are slowly transition to mta 1.6 i want to bring back topic of mta hardcoded functionality such a chat, map, nametags, fadeCamera, and other. The problem is people want to add, change, remove some hardcoded features what lead mta to add even MORE functionaltiy that let you do this. An idea is to change mta policy to move support for previously mention features to mtasa-resources repository, remove function and events from mta, instead add functions to add custom settings section to "native mta settings window".

On wiki we have a section with "Useful Functions" meanwhile in mta we have some useful functions hardcoded, why we (can) have "getDistanceBetweenPoints2D" but not "getDistanceBetweenPointAndSegment2D" build in mta?? Could we have a some repository where we will keep all utility functions and once you start a server, compile it they will be downloaded and installed on the server. it will be like "global lua code".

Doing scripts like "onPlayerMessage -> cancelEvent -> do your stuff" to replace chat is kinda silly, most of the servers has custom chats anyway ( logic of who should receive your message )

It will benefit both mta team - less code to maintain, code will be written in lua so more people can contribute. End users - i can add "new function" to my server ( and server clients ) without any external tools, tricks with exports.

Because if you take a look at some leaked gamemode you will notice people are often doing patterns like: first line of code in every resource being: loadstring(exports.core:getGlobalCode())() what seems to be fine, but the one of the biggest issue is that i can't for security reason disable "loadstring" function, but if mta could just inject arbitrary code to any resource both client and server side ignoring all acl restrictions i could do it. I know it sounds dangerous too but remember this scripts will most likely outside resources folder so even if you install mailicious resource it won't be able to do anything regarding global code.

My idea was to make 3 folders: "client", "shared" and "server" where you put all your scripts you want to have to be included in every resource. That way i can have one file "math.lua" with GetDistanceBetweenPointAndSegment2D function, "database.lua" with utilities regarding database and more. People will be able to public and share their "new functions" to mta what will make botder and rest of mta team obsolete :)

Then if mta get rid of all of these functions that are not worth time of mta core team, then they will have more time to focus on features and bug fixes that can't be/are hard to do in lua.

Describe the solution you'd like

/

Describe alternatives you've considered

/

Additional context

/

Security Policy

PlatinMTA commented 1 year ago

I agree that having a global folder or a global way to just make utility functions available without needing to import them or change every file of every resource could be useful.

Removing hardcoded functionality like the chat does not seem like a good idea.

dmi7ry commented 1 year ago

There is one important thing here. The core you mentioned can automatically update such modules if the file has changed. Thus, all resources that use it will also automatically "pick up" the changes, without the need to restart the resource.

CrosRoad95 commented 1 year ago

2970

PlatinMTA commented 1 year ago

2970

You can already make your own implementation of the chat via lua. Its going to be slower but you can. I doubt anybody would want to move the chat to lua, at least I would hate that change.

Even if the chat is limited, it does run pretty smooth.

quiret commented 1 year ago

Good idea, but still not justifiable by the current technicalities.