From f078ea1f8ab6e0f49f0aaae1aa7aeb2e06a265b1 Mon Sep 17 00:00:00 2001 From: David Anderson Date: Sat, 19 Sep 2015 19:48:53 -0700 Subject: [PATCH] Remove the Illiad-length mostly-wrong comment at the top of PluginSys.h --- core/logic/PluginSys.h | 50 ------------------------------------------ 1 file changed, 50 deletions(-) diff --git a/core/logic/PluginSys.h b/core/logic/PluginSys.h index d9999abf..aeb9aed2 100644 --- a/core/logic/PluginSys.h +++ b/core/logic/PluginSys.h @@ -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,