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)
Just a follow up to my previuous post...now updated to the newest patch 1765....Apparently Tani is no longer supporting this file or maybe not reading this forum any more...anyway, this seemed like a good set of scripts...I will look elsewhere...thanks for the start of something wonderful. Perhaps someone else will carry on with this...Cheers !
Dan
Hi Tani...
Just so you know, your link does not work...lol...anyway I only have nwn2 with 1.0.1763.0 patch and I would really like to use this neat script set. I can see where this would be sooooo handy.....anyone have the csftool.dll compiled for my version?
Thanks
Dan
For those with no or little programming experience...at least with C#. File links in C# can be done choosing Project > Add Reference. Reference linking (pointing) most likely refers to driver (.dll) files in NWN2 root game directory...although you can can try compilation to see what link errors are generated otherwise to see what needs reference.
I have not had much time for NwN2 lately and I am starting uni studies this year. At this point I don't think I will be doing any further updates to my NwN2 Vault submissions. Thank you all for the suggestions and support you have given.
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.
Posted by mobiusrit at 2007-10-11 19:13:16 Voted 10.00 on 09/27/07
I believe I have resolved the issue. I had a single script that executed off an item AND dealt with the feedback from the conversation it launched. Every so often, it would crash the server.
Separating it into two scripts (one that launched the conversation from the item and one that dealt with the output from the conversation) has seemed to cure the problem -- no crashes after a week of use.
Thanks for the feedback. I have updated the plugin for NwN 1.10. Thanks for the detailed info on the problem you are having with item on activate scripts. I will look into this, but probably not until I finish uni exams on the 9th of November.
Posted by mobiusrit at 2007-09-27 07:03:16 Voted 10.00 on 09/27/07
I'd like to echo Accerak's post (well, at least mostly). I too am having trouble with my tag-based item activate. I created a NEW mod, then immediately imported the CSF. I created my one test area and dropped down the default waypoint (that does indeed have all the @ events on it). My item is called cph_i_pcwidget and my script is thusly i_cph_i_pcwidget_ac. I have put PrintString and SendMessage lines in the activate script.
As soon as the PC activates the item, the module crashes. I can watch the nwn2server process on the server. The INSTANT I hit activate, the process dies (and then NWNx launches it again). It happens every time. I switched scripts to something incredibly simple (like just a SendMessage) and it still crashes.
As a note, the waypoints are being read correctly (at least a new one I put in for a NWNx onClientEnter module event, because it fires correctly).
Any thoughts?
Posted by ladydesire at 2007-09-09 15:19:18 Voted 10.00 on 09/09/07
Thanks for posting the source. :)
Posted by indio at 2007-08-13 02:01:10 Voted 10.00 on 08/13/07
Love this system, and that you've decided to maintain it for us charlievale. Much obliged.
Hi charlievale. I tried sending you an email, but never got an answer. I'm doing update to the codebase - a rather large one. Namely, separating the event queue into several named ones, to which each object can subscribe independantly. I hope it can integrate seamlessly into what you are doing. Can't promise any delivery date, though, but I'm 70% finished. You can contact me through the nwvault form.
Yes, I will keep the source code up to date as/when I make changes to it. I am also happy (more than) to manage any code additions others might want included here. So far I have a few ideas of things I would like to add / improve, and I am working on a tool to 'export systems' for upload to the vault (as that is a big time sink for me). However I haven't officially added anything to the code yet - just re-pluged it. The big need at the moment is to create some systems and convert others to use the csf, and make the components / packages available here, so non scripters can begin to see the potential of this.
My development mod uses the csf and I have a number of systems under development that use it. I also have made quite a few on activate items. I did however have the csf installed first. Here are a few things you should check if your tag based on activate isn't working:
1. Have you placed the CSF Default Scripts way-point/placeable. This attaches the standard nwn2 event scripts, which includes the OnActivate event code that enables tag based scripting. Check its variables and make sure there is an entry for the OnActivate event.
2. According to the tool-set documentation your on-activate script should be prefixed with an "i_", i.e. it should be "i__ac". I believe it is possible to change those requirements by editing the tag base scripting launch code in the OnActivate event. Unlikely you did that though as you would remember it...
3. Put a SendMessageToPC(GetFirstPC(), "My script is running!"); line at the beginning of your code. If you are using csf as a builder, I am probably telling you what you already know by now...
Posted by Accerak at 2007-07-21 06:28:42 Voted 10.00 on 07/21/07
This is a 10. It really is ground breaking. A couple of questions though charlie.
1. Will you be continuing in EP's footsteps with also releasing the updated source code?
2. Have you experienced any issues in the modules on activate event? I am working on a script that has a custom widget for the pc. It's tag based, and works 100% until I put in the new CSF. Then the script doesn't seem to fire any longer. Basically the item's tag is "value", the script it's supposed to fire is "value_ac". I even tried the ol' NWN non-tag based approach and modified the default x2 default activate script, specifically calling the script if the item is used... no dice with the CSF, works fine without it. Are you seeing anything like this? Any ideas (or did I just not read the docs well enough :) _________________________ "Victory is built from the ashes of your enemies." - unknown
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
at 2009-10-22 04:47:51
at 2007-09-09 15:19:18
