Don't combine event scripts to add new systems to your mod. The CSF does it for you!
Common Scripting Framework for NNW2
The Common Scripting Framework (CSF) simplifies the process for adding scripted systems to a module. Many modules will use several systems (e.g. DMFI, HABD, HCR, NESS, etc). Most require the editing/merging of module or area event scripts and demand the designer follow detailed instructions to install and update the systems. CSF allows the module designer to easily install, remove and configure any number of packaged systems.
* CSF allows plug-n-play installation of scripted packages.
* No scripting is required to install the CSF or CSF enabled components to a module.
* Component instances act as functional documentation for a system's requirements and configuration. They may double as in-game documentation for PCs or DMs.
* CSF supports installation and reconfiguration while the module is running
* Simple to use, but powerful enough to do what you need.
The CSF replaces all the event scripts for the module. It uses CSF Components to determine what events a system needs to be linked to. These components are placeables or waypoints with variables listing the required events and which script to run. The CSF then manages a list of all the system scripts that need to be called when any event script is fired.
The CSF is not just for builders who dislike scripting. It is a better way to maintain scripted systems. Using the CSF when making your own systems will simplify your event scripts, and make it easier to share your work with others.
For the full documentation see readme.html in the download.
Frequently Asked Questions Q: What kind of object should I use as an instance for my component? A waypoint? A placeable?
A: The framework does not care. It searches for a "CSF" tag on any object. It would be very bad to use anything that could get killed or destroyed.
* Waypoints objects have the smallest data structure, so it uses the minimal resources. It also can't be seen or touched by players.
* Placeables can provide extra functionality through their OnUse event and the Description could be used to provide in-game documentation to the players or DMs. Placeables are not much larger than waypoint (unless they contain inventory). Inventory could be utilized to configure a csf object.
[Reading variables from a placeable and reading variables from a waypoint seem to take about the same amount of time, the performance difference happens when the object is repeatedly passed as a parameter to a subroutine.]
Q: Something does not seem to be working right. What is wrong?
A: Did you check your server log? Csf prints errors and warning to that file. Did you make a typo in the variable or script name? Does the debug object help?
Q: You said the [local] event scripts run with priority 7 by default, how do I change that?
A: You could change it in the source code, but you don't really want to do that. The simple thing to do is just assign "[local]:priority" for an event the module object. For example setting: @OnSpellhook = "[local]:first" on GetModule(), will give the local event script "first" priority for the OnSpellhook event queue. (any csf component, it does not matter which one - it can not be controlled per object - think about it)
Q: Why did you overwrite the gui_death_respawn_self script?
A: The module's OnPlayerRespawn event is never called in NWN2. When the "Respawn" button is pressed on the respawn GUI, it calls gui_death_respawn_self. Therefore, the CSF Framework needs that code to call the onPlayerRespawn script so that respawn events can get processes. (the gui_death_respawn_self_orig script contains the original resurrect code that was replaced.)
Q: My OnPlayerRespawn still does not work
A: As explained in the previous question, the OnPlayerRespawn event is never actually called, it gets called by "gui_death_respawn_self".
So first turn on debugging and check if the csf OnPlayerRespawn event is getting called. If you are not using the default death script (nw_o0_death) which creates a GUI called "SCREEN_DEATH_DEFAULT" (death_default.xml), then the button press might not call "gui_death_respawn_self". (also check to see if any other script has overwritten "gui_death_respawn_self"
For example, an OnPlayerDeath script like k_mod_death in the OC (and anything using the "ginc_death" functions) opens a different GUI called "SCREEN_PARTY_DEATH" (partydeath.xml). When respawn is pressed in that GUI, it called "gui_death_respawn" instead. So to use this, you will need to modify "gui_death_respawn" so it calls the csf OnPlayerRespawn event like the modified "gui_death_respawn_self".
If your script is getting called, it might not work because it uses GetLastRespawnButtonPresser() to get the spawner. Unfortunately, that function value never gets set, since the true "OnPlayerRespawn" event is never called. Since the gui respawn scripts are called with OBJECT_SELF set as the button presser, I wrote store that and wrote a function to access it: csfGetLastRespawnButtonPresser(). (so use that instead)
Credits
CSF Framework 1.2 for NWN2
By EPOlson
The CFS framework is a merging of ideas from members of the NWN community. An initial prototype was written by futurewavecs and the HRC team built a similar system into their new HCR package. The details of framework were based on discussions between Demetrious, Pentane, Sunjammer, EPOlson, and others. The first version was scripted by EPOlson. (with nwnx2 chat scripts by virusman/dumbo and listen scripts by Deva/Demetrious & the dmfi team) rdjparadis added extensions to support all events for all types of objects, as well as add the idea of [local] scripts.
Changes 1.2 * Cleaned up onListen events (created a seperate erf for the listen scripts)
* Updated and cleaned up some documentation
* Added a few functions to the event api (for getting and setting component variables)
1.1 * Added OnPCStart event (first time PC start the module)
* Cleaned up OnPlayerRespawn. (see notes, but instead of passing the respawner as OBJECT_SELF, like the respawn GUI scripts do, I wrote a function:
csfGetLastRespawnButtonPresser()
* Cleaned up the demo mod
* Fixed bugs in the plugin (and updated for 1.04)
MotB finally hit Australia, and so now I am back. _________________________ Charlie's Pages | Fournoi Forum | Charlie's UI | Charlie's Item Modifier | Charlie's Item Appearance Changer
Posted by charlievale at 2007-10-3100:59:08
I am moving on to other projects and will no longer be making updates here. Thanks to all of you who have supported these projects with testing and feedback. Should anyone wish to take over one or more of my projects, contact charlievale at gmail dot com and I will have the project transfered to your vault account. All the best. _________________________ Charlie's Pages | Fournoi Forum | Charlie's UI | Charlie's Item Modifier | Charlie's Item Appearance Changer
10 - A Masterpiece, Genuinely Groundbreaking 9 - Outstanding, a Must Have 8 - Excellent, Recommended to Anyone 7 - Very Good, Deserves a Look 6 - Good, Qualified Recommendation 5 - Fair, Solid yet Unremarkable 4 - Some Merit, Requires Improvements 3 - Poor Execution, Potential Unrealized 2 - Very Little Appeal 1 - Not Recommended to Anyone
Site
