Overview:
Neoloader provides a number of benefits to the Vendetta Online modding environment. These include:
- a system that introduces dependency-based load ordering
- in-game toolset for enabling and disabling mods loaded through Neoloader
- an API that promotes inter-mod communication and expandability, including with Neoloader itself
Currently, no alternative exists for Vendetta Online. Plugins could be (and historically have been) designed for the ASCII-betical plugin loader. Neoloader doesn't replace this, but runs before it using built-in game mechanics to provide its extended functionality without need for exploits.
LME and NPLME (Neoloader):
It is important for plugin developers to note that Neoloader itself is an implementation of a "Library Management Engine". The public-facing API could be seen as LME, where how that API is implemented is Neoloader. This distinction is important in the event that a new tool supercedes Neoloader in the future while providing the same features. For a game like Vendetta Online, which is undergoing active development to this day, this distinction helps future-proof plugins as the game changes. Indeed, as long as the API itself remains untouched, how that API is implemented should not matter.
Startup Process:
Neoloader loads itself as Vendetta Online's interface, using the if= option in config.ini. As such, it will always be the first plugin to be loaded. Neoloader first sets up basic functionality and builds the API in the public "lib" table, before entering "Init", or loader phase. This is the phase that handles loading and executing existing compatible mods. This Init process is described in the image below.
When sorting mods into their dependent orders, it is important to note a few exceptions to this rule due to how the process works. When a plugin is registered in Neoloader, it is given a "Load State" which determines whether the plugin should be allowed to load or not, and under what circumstances.
| Possible Load States for plugins: | |
| NO |
This plugin will not load |
| YES |
This plugin will load using normal rules |
| FORCE |
This plugin will load even if its dependencies are not met |
| AUTH |
This plugin will be given Neoloader's auth key when it loads |
Normally, the YES/NO load states will be the only ones available; the FORCE and AUTH load states are intended for plugin developers to use.
Once the Init phase is complete, it assigns a few events and commands, before completing. At this point, the standard client takes back over and begins the normal mod loading procedure.
Checking for Neoloader's existence:
Before executing any LME functions, mods should check for the existence of Neoloader. This can be done with two various bits of code.
The first option is to check for the public boolean "NEO_EXISTS". When Neoloader starts, it assigns this boolean value. However, this is not the preferred method for checking for Neoloader's existence; your plugin would become reliant on Neoloader specifically. The API is designed to be 'generic' - that is, an alternative resource could provide the same API. As such, the preferred method is to check for both 'lib' and 'lib[0]', as defined below:
| if (type(lib) == "table") and (lib[0] == "LME")) then --LME API functions here end |
You can explore how this used in some of the plugins located in the examples folder provided with this documentation (todo; see previously made examples with the old documentation here). The Design page also describes how to set up specific files to make your plugin ready for management through Neoloader.