[highlight]FuzzyDIYCE Core Loading[/highlight]
As promised, here's a run down of how the core works and how it all hangs together. As this is an explanation based on the current state of the core (currently at the alpha stage), future versions may be a little different, but I don't envision any drastic changes. It may be beneficial to download and examine the code while reading this tour of FuzzyDIYCE.
FuzzyDIYCE Core uses so many advanced features not normally seen in your typical add-on, that an explanation is in order. Some of these features I've not seen anywhere else, though it isn't like I've examined many add-ons to find out.
The FuzzyDIYCE Add-on Loading Scheme
Probably the best place to start our tour is in the way FuzzyDIYCE actually loads up in the game. It is by no means standard but as we'll see, it gives us a lot of flexibility that FuzzyDIYCE takes advantage of.
When RoM loads an add-on, it actually scans inside the add-on's folder and all sub-folders for any .toc file it can find and will load and use them as it finds them. Since scanning a folder will make the game find the files in lexicographic order, we can use these facts to load the .toc files, when we want them loaded. We just need to name them correctly and we are good to go.
For this reason, the main add-on folder has a .toc file with a name that starts with a exclamation mark (!) which will be the first thing the game will encouter while scanning for .toc files. This "!FuzzyDIYCE.toc" file contains most of the files the core is composed of. This ensures that all that is required to be loaded prior to any custom user code and/or plug-ins is in fact loaded by the game.
There is another .toc file in the main add-on folder called "~FD_FinalizeLoad.toc". Note that this one has a tilde (~) as its first character making it the last thing the game will find here. This .toc file is responsible for ensuring that all the plug-ins are initialized and the scripts registered with the core.
Now comes the sneaky part. Since the game will also scan any and all sub-folders for .toc files, FuzzyDIYCE uses this as the means by which the plug-ins can be loaded up. The advantage here is that the game itself finds and loads the plug-in .toc files. Since by the time it encounters the plug-in .toc files the core is already loaded due to our sneaky naming scheme, the plug-ins will be able to register themselves with the core.
For plug-ins, FuzzyDIYCE implements a priority scheme. That is, a plug-in can set a load priority so that it can be loaded before other plug-ins. There is no guaranteed loading order for plug-ins of the same priority value. The registration of the plug-ins with FuzzyDIYCE must be done in a slightly special way, but this is an effect of the priority scheme. Apart from this, creating a FuzzyDIYCE plug-in is very similar to how add-ons are made.
The FuzzyDIYCE Core Files
Now that we've seen an overview of how the game loads FuzzyDIYCE, lets look at the files it actually loads, starting with the files in !FuzzyDIYCE.toc.
The first file to be loaded is FD_Plugins_Manager.lua. This file is responsible for maintaining a list of plug-ins that have registered themselves with the core, and is also responsible for actually initializing each plug-in. The code here was originally going to be an independent module add-on, hence why the code is not actually part of the main API. Now that this is no longer required, this file will likely be refactored into the main API.
Next is FD_Apartment.lua. This defines the main namespace that the rest of FuzzyDIYCE uses. All other files refer back to this object, so it must be loaded very early. It also defines the main environment space that all scripts will execute in. Most of the entries in the table defined here will be filled in later parts of the code, but those modules assume that the table defined here already exists.
FD_Locale is a simple module that adds a few helper API functions to allow adding strings to the localized string tables. These functions are mainly so that plug-ins can add their own strings to FuzzyDIYCE.
The next two files to be loaded by the game are the default and localized language message strings. Though currently there aren't any files for the localized strings, the game will simply ignore this fact and continue loading the add-on anyway. Having a default locale that is always loaded is useful to have because then not all strings actually need to be translated. Any missing strings will merely be taken from the default strings. Though not yet present, help and tooltip files will also be loaded at this time.
FD_Timers is responsible for defining the API functions for handling the FuzzyDIYCE timers. The code here is almost identical to that which I wrote for DIYCE 2. It also create a frame in order to handle the OnUpdate events required to update the timers.
FD_CachedVars.lua is next to be loaded and it is responsible for the internal workings of the cached variables, as well as a few helper API functions. The workings of the cached data variables has been discussed previously, though this file also implements the cached template variables which are a new beast and will be discussed in another post.
The next file to be loaded is FD_Commands.lua and despite its rather small size (it only defines one table and one API function) it is quite important. The function allows registering a command for use with FuzzyScript, while the table is used in order to allow a registered command to be skipped when a skill has been triggered. This table then is the key to how the try and perform commands can do their magic. The functioning of this table has already been discussed in previous posts.
The game will now load FD_Scripts.lua which defines an API for adding/compiling FuzzyScript scripts. It also defines the default code script apartment and defines some API functions for creating new script apartments. These code apartments are the key to allowing FuzzyScript to be used as an extension to Lua itself and the magic behind this is worthy of its own post. Some refactoring still needs to be done to this file however since it has undergone quite a few changes.
Finally we get to the last file in !FuzzyDIYCE.toc. FD_SlashCmd.lua defines the slash command handler for FuzzyDIYCE allowing convenient use in macros. This is what kick starts a script when the user runs the macro with this slash command.
Plug-in Loading
Once all of the core is loaded up, the game will continue scanning the add-on folder for .toc files and as mentioned already, will find some in the plugins folder. The process of loading a plug-in is pretty much the same for all plug-ins so I'll just describe the Base Commands plug-in.
For FuzzyDIYCE plug-ins, the .toc file for the plug-in only has one file in it. For Base Commands, this file is RegisterPlugin.lua. This file defines an initialization function to manually load all the files of the plug-in and then registers this function, along with a plug-in name and loading priority, with the FuzzyDIYCE plug-in manager.
The plug-in loading priority system requires this method so that the plug-ins get initialized in the correct order. If we didn't have the requirement, we could simply list the files directly in the .toc and we'd be done.
The plug-in initilization function will, when it gets run, load the remainder (in fact all) of the plug-in itself. For the Base Commands plug-in, this involves loading Commands.lua which registers the base FuzzyScript commands and Vars.lua which registers the FuzzyDIYCE cached data variables.
The Last TOC
After loading the core and registering the plug-ins, the game finally gets around to loading ~FD_FinalizeLoad.toc which, as the name implies, finalizes the loading of the Core.
The first file this .toc loads is FD_Plugins.lua which has only one task. Tell the plug-in manager to initialize all the registered plug-ins. The plug-in manager in turn is what actually calls all the plug-in initialization functions which as we've seen is what actually loads the plug-in files. Since these initialization calls are sorted based on the priority values the plug-ins registered with, they will always load in the correct order.
The next file in this .toc is FD_ScriptApt.lua which registers all scripts defined in the default FuzzyScript code apartment with the core. Note that this is only done for the default code apartment. Custom code apartments must be registered manually, though this can be done where the apartment is defined.
Lastly, the game loads FD_Ready.lua which only has one small task. To tell the user that FuzzyDIYCE is loaded and ready.
Runes of Magic US / AU »
Runes of Magic - (US) »
GAMEPLAY »
Quoted from "Fishtale;594567"
Hope you're doing well Peryl, never talked to you directly much but your forum posts have been immensely helpful in the past. Looking forward to this project, and I know good things take time. =D
, too much for only one person to handle. Thanks for all that work being done. 
