Repository navigation
new resource: map_loader #697
Description
Is your feature request related to a problem? Please describe.
In short, MTA Map Loading system (through meta.xml <map/> nodes or loadMapData (probably nobody uses this feature) has limitations:
- It's server-side and uses element data (inefficient)
- Maps exported by map editor even require a
mapEditorScriptingExtension_c.luascript to do removeWorldObject and LODs!!! This duplicates a lot of code. - It doesn't support
createBuilding - It doesn't support new models, which are incredibly popular since the addition of
engineRequestModel - It doesn't support custom textures, which servers since shaders were invented
- ...
Describe the solution you'd like
I believe the solution is not to expand the MTA Map Loader in C++ (mtasa-blue code), but instead to remove it (deprecate nodes etc) and create a map loader resource (official) that does everything the current system does + all the nice fun features we can add.
The idea is that new official resource will be included in the default resources pack, allowing any server to use it to load their maps through:
- File drag & drop
- Custom exported functions
- etc
Additional context
Honestly I've already created a map loader for fun and for several servers in the past, it's pretty simple.
A map is just a list of elements to spawn at certain positions with certain properties.
The list can be stored on any popular format like JSON, then just use Lua functions to spawn the elements and set their properties.
We can even use the new glob features (<file src="maps/**/*.json"/>) if useful.
Tell us your opinion about this.
Activity
misterquestions commentedon Nov 15, 2025
Another thing to consider here is that this should involve some kind of sandbox that allows map scripts to be loaded only for those players who have this map loaded avoiding the issue of getting music played globaly or effects applied when you're not in such map (like in race servers with multi-modes).
Fernando-A-Rocha commentedon Nov 15, 2025
Nice idea: client side scripts associated with maps....
Fernando-A-Rocha commentedon Apr 11, 2026
@ArranTuna what is your opinion on this?
ArranTuna commentedon Apr 11, 2026
But how would it work? If someone or a game-mode starts a map, MTA automatically loads the map data, how would your resource do it?
Only way I can see this working is that there's:
qaisjp commentedon Apr 12, 2026
The benefit of MTA's map loader is that when server owners and clients upgrade, it works.
The drawback of a separate resource is that now people have to reason about a new version number to associate map compatibility with.
There's no guarantee what version of default resources servers have. "This map is only compatible with map_loader v1.2.3"
For that reason I don't think it'd be wise to implement this. Please can you explain why the problems you've outlined can't be addressed by MTA itself?
ArranTuna commentedon Apr 12, 2026
IMO the only reason it can't be addressed by MTA itself is that if someone added a new map editor feature, they'd have to make a request for someone to modify loadMapData to even just test their new feature. Or even if they made a PR, that PR may never get added. Looking at the pending PRs there are many that have been waiting years to get merged.
I feel that the delay in merging PRs really holds MTA back (because these contributors may have made more PRs if their original PRs got merged) and I would be willing to help with this. I already do test some PRs, if I knew that my testing of a PR would help a PR get merged then I would test whichever PR is requested.
misterquestions commentedon Sep 11, 2026
One way I've seen its done in various multi-mode servers in race community is to support foundational elements within map building:
Else than that is either just kept in memory or treated as a generic element, adding all attributes as element data.
An event could be introduced as "callback" to notify any resource creator that a map as built given the base data (settings, elements), they can opt in to listen to it and handle it as they best see fit on their game mode.
So then we should not be the ones supporting each and every mode or new element (unless core thing e.g. worth considering Light)