local.conf, editor.conf and editor_acl.xml is bad design
Closed this issue · 2 comments
Is your feature request related to a problem? Please describe.
local.conf, editor.conf and editor_acl.xml are bad design.
Why do these files exist? They are packaged in every MTA server! Nobody edits editor.conf or editor_acl.xml manually, they are just polluting the file system.
editor.conf sets a custom server name "Map Editor Server", different ports "22010" and "22011", etc, and define some resources for startup:
<resource src="editor" startup="1" protected="0"/>
<resource src="defaultstats" startup="1" protected="0"/>
<resource src="joinquit" startup="1" protected="0"/>
<resource src="mapmanager" startup="1" protected="0"/>
<resource src="ipb" startup="1" protected="0"/>
<resource src="parachute" startup="1" protected="0"/>local.conf contains a bunch of duplicate settings from mtaserver.conf and defines some resources for startup.
Describe the solution you'd like
I don't think this system is good practice. MTA resources are maintained in a separate repository (mtasa-resources). Ideally, there should not be any hardcoding of resource names or ACL rights in mtasa-blue. This data belongs in mtasa-resources.
However MTA has a Map Editor and Host Game features that depend on the existence of official resources packaged in the user's MTA server installation... So it is what it is.
First, what differs Map Editor server from a Host Game server? Almost nothing, just the startup resources and custom ACL config. They are both just host game flavors.
So, I suggest getting rid of all .conf files and hardcoding editor_acl.xml in the code for now.
My feature suggestion, which is an enhancement of how Host Game is configured, merging logic with Map Editor:
- Create "host game" presets (Default Freeroam preset, Map Editor preset).
- Host Game button loads the Default Freeroam preset for you to customize in the GUI and launch
- Map Editor button loads the Map Editor preset and launches immediately
- Optionally more presets could be created for players to choose in Host Game to quickly launch different themed servers (so not just freeroam)
Describe alternatives you've considered
No response
Additional context
No response
Security Policy
- I have read and understood the Security Policy and this issue is not about a cheat or security vulnerability.
I'm not convinced this is actually a design problem. Looking at the specific concerns:
"Polluting the file system"
In relation to which specific clean filesystem? This seems more like a preference than a technical issue.
"Nobody edits these files manually"
If folder cleanliness is the goal, users can delete them. Especially in "public server" contexts.
"How does MTA decide which config to use?"
The logic exists in the codebase for anyone who needs to understand it. TL;DR: Two of them are actually for the Client to consume on local client-server installations (opposed to standalone server installations).
There's an inconsistency here:
"Ideally, there should not be any hardcoding of resource names or ACL rights in mtasa-blue"
Yet you suggest:
"getting rid of all .conf files and hardcoding editor_acl.xml in the code for now"
How does moving the same problem to a different location solve anything?
Configuration fragmentation:
"local.conf contains a bunch of duplicate settings from mtaserver.conf"
These are convenience templates for different use cases. What actual issues does this cause? Are there bugs? Maintenance problems that prevent functionality? Or do you just prefer having fewer files?
The "coupling" isn't a problem:
"MTA resources are maintained in a separate repository (mtasa-resources). Ideally, there should not be any hardcoding of resource names"
This is baseless. MTA intentionally bundles server functionality to enable Host Game and Map Editor. Of course it needs to know which resources to start - that's literally the feature working as intended. That's a complaint about a core design decision, not identifying a flaw.
Your preset solution:
"Create 'host game' presets (Default Freeroam preset, Map Editor preset)"
Why are GUI presets architecturally better than file-based presets? You haven't explained the technical advantage beyond "fewer files." The configuration data has to be stored somewhere, and adding a new data structure (preset) is just creating the same configuration system with different packaging. So we are just moving the "problem" (which hasn't been identified yet). What specific problems would this solve that aren't just preferences?
I'd show concrete examples of how the current system breaks functionality or causes real maintenance issues.
Or even better, actionable ones.
For me, the preset solution doesn't solve any identified technical problem. It just moves configuration data from files to GUI structures, creating the same maintenance burden with different packaging.
Yeah now that I think about it I didn't really propose a solution, and the problem is just coz I was mad these files existed while they could be a few arrays 😆