Open Source Rule Set

(http://www.opensource.org/docs/definition.php) --

Introduction
The NWNWiki Rule Set is also known as the "NWN Open Source Rule Set", the "Wiki Rule Set", the "Wiki Rules", "NRS", and "OSRS".

OSRS applies the "power of the public" to a source code base that will yield a much more dynamic product than a managed rule set, in much the same way that Wikipedia has triumphed over standard encyclopedias. The Open Source Rule Set (OSRS) is published by Users who contribute.

To the Player:
The Player is just the average guy who just wants to play NWN games off the internet with something that works. He has probably arrived here by clicking on an OSRS logo advertised on a website somewhere. This logo means that the module you were looking at was built with OSRS. The player is not interested in designing modules, just playing them.

OSRS is an add-on to someone else's NWN module. If you download that module off the internet to play it, OSRS made that module better by providing standard scripts. OSRS has many features. The module you play might not use all of them.

To the single-player NWN Module Developer:
The single-player NWN Module developer feels comfortable towards creating his own NWN module through the toolset and might be competent with manipulating scripts but not scripting itself.

OSRS provides a set of public domain functionality for scripting your NWN modules. OSRS will provide a basic set of features for your module as an ERF}} file. [[OSRS exhibits several module features that are updated and improved by interested users. OSRS provides an ERF for you to import into your module. The source code for OSRS is open and developed COLLECTIVELY with other developers. Each feature is switchable ON or OFF at compile time. The OSRS ERF attempts to collect generic software code from Users and publish them as an ERF file.  Each OSRS developer tasks himself with what he is particularly interested in, on his own schedule, and on his own terms.  The interests of those developers will determine the success of OSRS.  Subject areas that are of concern to the public will be addressed by the public, without having to go through any particular approval process.  OSRS is not managed by a single person nor even a group of select persons.  OSRS is managed by the public, and everyone who uses it has an interest in combing the code and reviewing it.  In effect, everyone becomes a manager of everything they see.  If a graffiti artist arrives to deface some code, the hordes of public reviewers will be more effective than any single manager can be.  OSRS represents a new way of obtaining a stable, accepted, working base module or ERFs and coding platform for designers to create new modules and update existing OSRS modules.  OSRS will post releases of it's ERF to NWVault.  All users edit and add code they see, and in general the code will become better used over time.

OSRS is a new type of code management system. If you find some cool code on the NWVault that you desire in your module, you have to integrate it yourself, as well as debug it. You have to do this every time you find one NWVault item you find that you want. There are a LOT of people that do this over and over. OSRS provides a better way of doing things.

To the multi-player NWN Module Developer running a single server:
The Multi-player NWN module Developer designs and operates within a single-server system. He may be a single developer, or one of many who manage the same set of module code.

OSRS provides a base platform on which you can build your world separately, and rely upon upgrades from a public source that will not interfere with your module development. OSRS can be updated from prior versions and will not interfere with your own specific updates. Your development on your module will not interfere with OSRS updates. You can update your own team's work separately from OSRS. OSRS encourages public involvement which creates a more stable platform. There are more specific restrictions on your code than you would find while working on a standard NWN module. Each developer must provide all his input code as completely dependent upon being called by ExecuteScript("MyScript", OBJECT_SELF); Each feature may independently support custom content. Each feature must not RELY upon custom content. That is, it must not cause system crashing. The vision of OSRS is to guide the scripting community into such a CEP-standard for scripting content. The OSRS accesses an on-line code repository in the form of NWNWiki.org, which allows concurrent development throughout the world. Other coders will be working on it at the same time. NWNWiki manages the changes.

To the multi-player NWN Module Developer running a multi-server system:
The Multi-player NWN module developer designs and operates within a multi-server system. He is usually a member of team of people working to keep the system interesting and alive.

Not much operational experience is known in the public community sector of multi-server systems. In general, all single-server knowledge applies. Please consider updating OSRS knowledge to our public-domain base of code, or in the forums.

Advantages of using OSRS

 * OSRS is a management system. It manages features so you don't have to.
 * The module designer either turns ON a feature, or turns OFF a distinct feature.
 * When a feature is "not desired" during play, the module designer sets a switch that enables the effect of that feature to take place.
 * When a feature "breaks" during development, or is later on discovered to have a bug, module designers can just disable that section of code.
 * OSRS provides scripters with a generic base code of preconditional scripts (StartingConditional) for use in your conversations.
 * OSRS is configurable: With all features turned OFF, the player should not notice any difference from a normal NWN Toolset generated module that does not use OSRS.
 * No ONE person owns the code. Anyone can change the code.
 * No longer will a module designer be left to integrating NWVault code into his own toolset.
 * OSRS manages different code contributions as NRS Features, so that you don't have to spend time integrating the code yourself.

Disadvantages of using OSRS

 * OSRS is a management system. It incurs an extra overhead upon a module team that a normal module team might not experience.
 * There is overhead in the management of these switches, and the fact that it has to hook into every event in order to become effective.
 * The operational effect of this extra overhead is not yet known at this time (the base initial module is still under development).
 * OSRS imposes a "layer" of management code upon your module.
 * It has to hook every possible script involved on all the events under it's management.

Features
OSRS provides a list of NRS Features. Features start out as text descriptions of desired functionality, and evolve over time into fully coded scripts and objects. Anyone can add these features, modify them, or improve them. features that have little interest from the public will probably remain as ideas, while features that have great interest by the public will go through many changes and eventually morph into fully independent systems. The NRS Features are where the code is.

OSRS Philosophy and Objectives
OSRS follows the following philosophy:
 * 1) OSRS will respect the NWN EULA.
 * 2) Provide a reliable set of pre-scripted features for your NWN module to serve as the base platform with which you can write your story.
 * 3) Follow the open source philosophy.
 * 4) OSRS will strive to treat all users like developers.
 * 5) OSRS must allow free redistribution.
 * 6) OSRS must allow modifications and derived works. (No HAK PAK distributions).
 * 7) OSRS must preserve the integrity of of the author's source code.
 * 8) OSRS will not discriminate against persons, groups, nor fields of endeavor.
 * 9) All OSRS rights are granted to all recipients of the Open Source Rule Set.
 * 10) The license to use OSRS must not be specific to a product.  In this sense, it must not be specific to any non-Bioware products.  This means that OSRS cannot require other Hak Paks or ERFs to be in use.
 * 11) The license to use OSRS must not restrict other software.  This means that OSRS should not attempt to restrict other types of software from working successfully.
 * 12) OSRS will attempt to collect and reconcile interesting scripts into a standard open-source MOD or ERF distribution.
 * 13) OSRS will attempt to secure the source code of other authors for inclusion.
 * 14) All non-PC activity within a NWN module occurs as the result of scripts being executed in response an event firing on an object that can recognize them, or in the pre-conditional or post-conditional scripts present for each node of a conversation. Therefore, OSRS base code will "wrap" each event in the module, using one script for each event.
 * 15) All scripts submitted for inclusion in the OSRS must be executable only by calling ExecuteScript("MyScript",OBJECT_SELF);  For example, consider that you wish to integrate a feature script set into OSRS that has 14 scripts.  Each of these scripts must be capable of being added into OSRS in the appropriate place by only adding the ExecuteScript command in the appropriate event.
 * 16) All scripts in OSRS will be summarily documented with a single sentence description on a single page on the Wiki site. A feature submission should acknowledge the Open Source license in the Feature Summary.
 * 17) OSRS will strive to produce and expand a set of generic features.  Generic features are those features that are anticipated to be used by a sizable number of designers in almost "every" module.
 * 18) All generic features should be switchable via toggle so that module designers can disable or enable specific features.  Developers should strive to make as many settings of the feature submission to be switchable.  The more configurable the system, the more desirable it will be to module designers who wish to use a "generic" solution.
 * 19) All features must have at least one toggle: the ability to completely turn that feature on or off in a module.  Using OSRS with all features toggled off should have the same functionality as a standard NWN/SOU/HOTU module created with the toolset.  Besides the flexibility this allows module designers, it also provides OSRS testers an easy way to verify the functionality of a single feature.
 * 20) Features which are too specific to a module should be removed from the OSRS code. Specific features are those features which may only apply to specific settings and probably do not apply to any general module.
 * 21) All submitted scripts should have ample commenting.
 * 22) A single file that summarizes your package submission in the form of one large comment, should also be submitted. Expect this document to be the initial posting of your NRS Features on NWNWiki.org.
 * 23) OSRS will only accept script submissions, consisting of standard scripts, conversation pre-conditional scripts, or include files that are used by one of these two.  Standard scripts are those scripts that have a main function. Conversation pre-conditional scripts are those scripts that have a StartingConditional function.
 * 24) An OSRS package submission must not contain any non-scripting files.  All scripts should assume to be operating upon NWN/SOU/HOTU combination and should only rely upon objects/resources in such an installation.
 * 25) Submitted scripts should handle all errors and digest them without crashing the module. Any external non-scripting material MAY be used in a particular implementation, but it MUST work properly without that particular implementation.  This will allow OSRS to quickly disable/remove features that are troublesome.
 * 26) The submission settings for a feature must execute in the Module's OnModuleLoad event.
 * 27) A feature submission should not contain any non-scripting custom content, such as music, graphics, hak paks, or conversations. OSRS focuses on building a general set of scripts for any module.  Scripts enforce rules that a Designer would desire in his module.
 * 28) A feature submission must be [general] in nature and not [specific].
 * 29) A feature submission should be commented so that others can improve upon it.

Naming Rules

 * 1) All submitted scripts must have script names that do not overwrite any other existing script within the OSRS, unless they are specifically an upgrade or update of that file.  Authors that find themselves editing the functionality of OSRS-owned scripts should alert the developers upon the forum.
 * 2) All OSRS "management" scripts will have the prefix "osrs_". Submitted scripts with these prefixes will not be accepted.

Partitioning
One of the overhead prices you have to pay for using OSRS is to accept the overhead management layer of capturing and controlling every event in the entire module. You can always write your own scripts too of course, 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 " ". 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 NO functionality because NONE of the features are enabled.

How you can get involved

 * 1) NWNWiki Rule Set FAQs
 * 2) Add your ideas to be implemented by others.
 * 3) Add your code that you have implemented yourself.
 * 4) Declare yourself as an interested contributor to the Wiki Rules.  On your User page, add this following line of code at the bottom:

OSRS event scripts
Review the Event-Class matrix to see which objects handle which events.