|DomtronVox 205536d595 Added dependancy resolution code and tests for the new code. It takes a list of loaded mod ConfigStores. Based on each mod's id, depends, and opt depends the code creates a new lists that will load mods in an order that any dependant mod will show up before it's dependancy. It has only been lightly tested and could use better error handeling especially for mods that cannot be loaded due to a missing hard dependancy. However its' basic functionality is good for now.||2 months ago|
|examples/1_minimal||8 months ago|
|src||2 months ago|
|tests||2 months ago|
|.gitignore||8 months ago|
|CMakeLists.txt||4 months ago|
|LICENSE||4 months ago|
|README.md||4 months ago|
Very pre-alpha, not usable yet.
ModEasy is a small, customizable library that provides easy modding support to any project. A Mod can stand for module or modification and is a package of data and/or code that adds onto or overrides the original data and/or code.
MIT, see LICENSE file for details or https://choosealicense.com/licenses/mit/.
To build you need cmake, and a c++ 11 capable compiler.
sudo apt install build-essential cmake
mkdir build && cd build && cmake .. && make -j2
You can make the -j# be “number of core” - 1 for faster build times.
If you want to run the unit tests, after the above commands run: make test
As stated above the library tries to function out of the box. Once you install the library using it in your code is fairly simple.
std::unique_ptr modding; modding = std::make_unique(“mods”); //the modding folder relative to your executable.
//register your core API functions modding->regiserAPI(“MyFunction”, funct_ptr); //etc
//initiate all mods modding->initiateMods();
Library is broken into 6 parts:
The Configuration sub-system is based around recursive key/value objects and file parsers. These two aspects are handled by the ConfigStore and ConfigLoader classes respectively.
The ConfigLoader base class forces derivatives to implement the validate, parse, and serialize functions. By default we include a ConfigLoaderINI class that loads .ini style config files.
In the ModFrameworkCore, you can set the default ConfigLoader. There is also a function to register new formates and associate them with a ConfigLoader child class.
The ConfigStore class allows storing string values and nested ConfigStore objects in key/value pairs. ConfigStore has the getStr, getNested, and set functions that return and take string and ConfigStore variables. There are no customizable parts to the ConfigStore.
Just a note, ConfigStore uses unordered_maps for the two type of data stored. You can get their iterators with the beginStr, endStr, beginNested, and endNested functions. Unordered_maps use forward iterators so you can only test equivalence (==) and non-equivalence (!=) when using them in a for loop. Trying to use less then greater then or the variants will fail. http://www.cplusplus.com/reference/iterator/ForwardIterator/
The Dependency sub-system makes sure that mods will be loaded in the correct order. This is a self-contained sub-system and doesn’t need any user extensions.
The Implementation sub-system deals with actually loading the meat of the Mod. By default there are 3 implementation mod types:
New mod types are defined by creating a new derivative of the ModHandler. ModHandler derivatives need to implement the load function.
The load function is given the directory path and ConfigStore object for the mod and is supposed to do everything needed to get a mod loaded and working.