UNLOZE/sourcemod
10
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Remove the Illiad-length mostly-wrong comment at the top of PluginSys.h

Browse Source
This commit is contained in:
David Anderson 2015-09-19 19:48:53 -07:00
parent ab1b915a3c
commit f078ea1f8a
1 changed files with 0 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
core/logic/PluginSys.h
View File

@ -60,56 +60,6 @@ class CPlayer;
using namespace SourceHook;
/**
* NOTES:
*
* UPDATE 2008-03-11: These comments are horribly out of date. They paint a good overall
* picture of how PluginSys works, but things like dependencies and fake natives have
* complicated things quite a bit.
*
* Currently this system needs a lot of work but it's good skeletally. Plugin creation
* is done without actually compiling anything. This is done by Load functions in the
* manager. This will need a rewrite when we add context switching.
*
* The plugin object itself has a few things to note. The most important is that it stores
* a table of function objects. The manager marshals allocation and freeing of these objects.
* The plugin object can be in erroneous states, they are:
* Plugin_Error --> Some error occurred any time during or after compilation.
* This error can be cleared since the plugin itself is valid.
* However, the state itself being set prevents any runtime action.
* Plugin_BadLoad --> The plugin failed to load entirely and nothing can be done to save it.
*
* If a plugin fails to load externally, it is never added to the internal tracker. However,
* plugins that failed to load from the internal loading mechanism are always tracked. This
* allows users to see which automatically loaded plugins failed, and makes the interface a bit
* more flexible.
*
* Once a plugin is compiled, it sets its own state to Plugin_Created. This state is still invalid
* for execution. SourceMod is a two pass system, and even though the second pass is not implemented
* yet, it is structured so Plugin_Created must be switched to Plugin_Running in the second pass. When
* implemented, a Created plugin will be switched to Error in the second pass if it not loadable.
*
* The two pass loading mechanism is described below. Modules/natives are not implemented yet.
* PASS ONE: All loadable plugins are found and have the following steps performed:
* 1. Loading and compilation is attempted.
* 2. If successful, all natives from Core are added.
* 3. OnPluginLoad() is called.
* 4. If failed, any user natives are scrapped and the process halts here.
* 5. If successful, the plugin is ready for Pass 2.
* INTERMEDIATE:
* 1. All forced modules are loaded.
* PASS TWO: All loaded plugins are found and have these steps performed:
* 1. Any modules referenced in the plugin that are not already loaded, are loaded.
* 2. If any module fails to load and the plugin requires it, load fails and jump to step 6.
* 3. If any natives are unresolved, check if they are found in the user-natives pool.
* 4. If yes, load succeeds. If not, natives are passed through a native acceptance filter.
* 5. If the filter fails, the plugin is marked as failed.
* 6. If the plugin has failed to load at this point, any dynamic natives it has added are scrapped.
* Furthermore, any plugin that referenced these natives must now have pass 2 re-ran.
* PASS THREE (not a real pass):
* 7. Once all plugins are deemed to be loaded, OnPluginStart() is called
*/
enum LoadRes
{
LoadRes_Successful,