Event partitioning

From NWNWiki

Event partitioning is the term this feature applies to the dividing and separation of all module events into three distinct time phases: pre-event, during-event, and post-event.

One of the overhead prices a module pays for using OSRS is to accept the overhead management layer of capturing and controlling every event in the entire module. A module developer can always write their own scripts that are specific to your module. OSRS hopes that the code you write specifically for your module is also not generic enough to be used by the rest of the module.

Promote your module-specific code to management-specific code. If it is generic enough, please submit it! When you submit your code to OSRS you are committing your work to adhere to additional restrictions that may be intolerable to you. The users will review your code and include it in the OSRS if it meets our requirements. Once you adhere to OSRS rules, OSRS will provide a consistent playing platform for your module. To achieve this level of multiple features, your coding style will have to exhibit such safe, friendly, play ground rules applied to your scoping.

For example, all of your scripts must be executable only via "ExecuteScript("myscript", OBJECT_SELF);". OSRS merely manages which features will operate and which ones will not, based upon the module designers decision. Out-of-the-box, the OSRS provides [b]no[/b] functionality because [b]none[/b] of the features are enabled.

At the OSRS feature management level, this functionality allows a programmer to execute custom procedures before or after NWN actually processes the event.

• Pre-event functionality allows a programmer to test conditions and abort the rest of the event from being handled before the other two phases occur.

• Post-event functionality allows a programmer to clean up or otherwise perform customized house-keeping tasks after the NWN game engine has processed the events.

Each phase of each event is handled with a scripted function.

All non-post-phase scripts return TRUE or FALSE to indicate success or failure and give the caller an option to bail out from executing undesired code after it's subphase in that event.

Pre- and post- phase event functions are the property of the Users. All pre- and post-events are owned by the user. The during event is reserved for OSRS. OSRS respects your actions in your functions, while you respect all programming in OSRS functions.

[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.

A module designer is a person or team of people that is writing the final content for release to their server.

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 and remain compatible for future upgrades of either rules.

The OSRS rules can be upgraded by the OSRS rules team contributors without interfering in individual module functionality.

The designers can upgrade their module-specific rules without interfering with OSRS rules functionality.

The OSRS rules asks that as the team designers examine and refine their code, that code that they identify to be generic enough for future versions of OSRS rules should be forwarded back to the NWNWiki.org website.

In return, The OSRS rules scripters will see to it that code that is module-specific is kept out of the OSRS rules.

"Generic" code means code that can apply to almost anyone's module; for example, realistic torches.

"Specific" code means code that in particular applies only to a certain module; for example, referencing the waypoint "vrm_wp_rune_master" probably doesn't exist in everyone's module.