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

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,