The last couple of months we have been developing a new way of distributing content from server to clients. We do this by so called resources, a new way of thinking about your MTA mods. We will try to explain how this benefits you as user, and as potential developer.

Every developer that wants to make scripts or maps, includes his/her files inside a (zip) archive. This archive contains everything needed for the resource to load. For example, someone could develop an "RPG gameplay" resource that could include the following:

• a server-side script file that runs on the server and provides the server-side gameplay and communicates with a SQL server. Check out the Tutorials section for more information on how to script this way. This is done by the Lua scripting language.
• a client-side script file that runs on each client, providing a user interface for e.g. logging in or an inventory of items (using the well-known MTA GUI which is now scriptable!). This is done by the Lua scripting language.
• a webserver file that runs on the server. Our dedicated server contains an embedded webserver which allows access to all currently loaded resources on the server (using Ajax, XML and Lua scripting support, similar to how PHP works). This would allow developers to put settings, status, and gameplay functions on the webserver so anyone can access them (without using the server's console or being in-game).

Our resources are compatible with custom files as well (as it allows downloading all files to each client). This means that in the future you may be able to send your own custom .dff or .x models, textures, images, sounds, etc. through a resource.. thus providing a complete "package" for your gamemode very much like Carmack's .pk3 and .wad formats you may know from Quake III and Doom I/II/III.

Resources are not necessarily bound to gameplay modes. For example, we have a drive-by resource that adds drive-by functionality, a simple tank-aim resource that adds a crosshair for tanks, a spawn manager resource that takes care of player spawning, a logger resource that logs server activity to a MySQL server, a death messages resource that displays all death messages, etc.

See, by moving as much of the functionality to resources (that are open-source) instead of baking everything into our DLL files, we are encouraging you to modify and extend the basic scripts we provide.

Gameplay examples can be found in the Tutorials section, but here's an example of a server-related resource:

This is our resourcebrowser resource. As the name says it provides a frontend for our embedded webserver, allowing access to all other resources. This is an example of what can be done with resources, not just on the gameplay.. but on virtually everything you want.

I hope you found this an interesting read. In any case, thanks for reading. We will be posting some more in-depth info on this in a next post.