Event partitioning
From NWNWiki
Event partitioning is the OSRS feature that divides and separates all module events into three distinct phases: pre-event, during-event, and post-event. In the pre-event phase, a programmer can prevent the other phases of the event handler from occurring, if conditions warrant such a measure. In the post-event phase, a programmer can clean up or otherwise perform customized house-keeping tasks after the NWN game engine has processed the event. The during-event phase is reserved for the Open Source Rule Set (OSRS), and it handles the actual event.
Some of the overhead a module must pay for using OSRS is to accept this management layer that captures and controls every event in the module. A module developer can always write scripts that are specific to a module. All pre- and post-event phases are owned by the user. The during-event phase is reserved for OSRS. OSRS respects the actions in the pre- and post- event functions, with the expectation that module builders respect all programming in OSRS functions.
All scripts used by this feature must be functional when executed via the call ExecuteScript("myscript", OBJECT_SELF); within the intended event.
OSRS manages which features will operate (hence which scripts will be executed) and which ones will not, based upon the module designer's decision.
By default, all features are disabled, so OSRS provides no extra functionality without action on the builder's part.
At the feature-management level, this functionality allows a programmer to execute custom procedures before or after NWN processes the main event handler. Each phase of each event is handled with a scripted function. The functions for the first two phases return TRUE or FALSE, indicating success or failure, hence whether or not the next phase should be executed.
[edit] Mutually exclusive demands
Each script set references two include files. Each include file partitions the ownership of code into "OSRS-owned" scripts and "module designer-owned" scripts. OSRS-owned scripts are those scripts that only the OSRS rules contributors will touch. Designer-owned scripts are those scripts that only the module owners will touch.
Designers have the final say in their module and of course can do whatever they wish with all the code there. However, if both teams, OSRS and designers, do not step on each other's code, then each team can contribute to the success of and remain compatible for future upgrades of either set of scripts. Thus, the OSRS scripts can be upgraded by the OSRS team contributors without interfering in individual module functionality, and the designers can upgrade their module-specific scripts without interfering with OSRS functionality.
As OSRS examines and refines its code, any code that is generic enough should be submitted for inclusion in future releases of OSRS; code that is module-specific will be kept out of OSRS. ("Generic" code means code that can be used in almost any module; for example, realistic torches. "Specific" code means code that applies only to a certain module; for example, code that references a specific waypoint or other object.)
