The Common Scripting Framework (CSF) addresses the problems that designers encounter when incorporating various packaged systems into their 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. It is essentially a simple way to manage queues of scripts for various module events.
The CSF was based on ideas, discussions and examples from many people in the NWN scripting community, including Pentane, Demetrious, rdjparadis, futurewavecs, Sunjammer and many other. All of the bugs in the CSF code are strictly mine (EPOlson)
The CSF code and documentation has been updated for NWN2 and includes a toolset plugin that simplifies installation and configuration.
Source code for csf toolset plugin (in case I don't update quickly enough after a patch) Feel free to rip off any of the code if you make your own plugins. (requires C#)
Minor updates (nwnx4 chat plugin support) & plugin updated for Link. (the '1.2a' version is a slight patch of 1.2 - somehow the csf waypoint that gets used everywhere got it's blueprint name changed)
Posted by morikahn at 2008-02-28 21:40:25 Voted 10.00 on 02/28/08
Great idea.
Did HCR2 basically rip this system off and call it their own?
Posted by jallaix at 2007-06-15 04:38:19 Voted 9.50 on 05/07/07
@charlivale : Thanks for the plugin !
@DomFada : It looks great, I hope EPOlson will see this post, but it seems he hasn't looked at this page for a long time. _________________________ Spellcasting Framework Wild/Dead Magic Zone (Spellcasting Framework add-on)
Posted by DomFada at 2007-06-13 09:09:33 Voted 10.00 on 06/03/07
EPOlson, I tried contacting you by email, but got no reply - if you're too busy, no prob, but I'm posting here in case your contact adress is not up-to-date.
I've made some modifications / bugfixes to the CSF platform, and created a working "custom rest" architecture.
Short list of changes (some you might have already implemented in 1.03, haven't checked yet) :
- added capability for a component to register several scripts to a single event, with same or differing priorities
- streamlined / separated in different components the base framework, and its module / area / creatures / placeables parts
- implemented base "custom rest" architecture, bypassing default rest system and allowing plugin modification.
- I've also created a few plugins to test this last system : a time limit condition, a visual effect similar to NWN2 default, and two "rest effects" plugins - NWN2 default and pen-and-paper style.
- streamlined / separated the listener component into 3 diff ones : base listen system, xchat provider and spawned provider. IMHO, makes for cleaner integration.
If you're interested, I'd be happy to send you the code (once I've merged it with patch 1.06 revision).
Posted by DomFada at 2007-06-03 15:01:09 Voted 10.00 on 06/03/07
Same comment here as jallaix - I have a deadly allergy to C#, and so very sadly cannot recompile the plugin. Otherwise, splendid work.
Posted by jallaix at 2007-05-07 11:18:16 Voted 9.50 on 05/07/07
Any chance to see the plugin updated to 1.05 ?
I don't know anything about C# _________________________ Spellcasting Framework Wild/Dead Magic Zone (Spellcasting Framework add-on)
For HCR2, you would just need a few waypoints containing the scripts/events. Plus one or two extra script (if I remember). Give me a few days and I will post an erf with a the scripts and waypoints that glue it together. You will be able to use the HCR2 systems with or without HCR's event framework.
Listen scripts that got renamed:
dmfi_inc_listen => csf__inc_listen (CSF's onListen API)
csf_list_activate => csf_list_init ("activate" happens too soon, it needs to do the init onModuleLoad)
FYI, the component's onActivate event fires before the queues are setup, while the onModuleLoad event fires after the queues are set up. (And just the onActivate events fires when a component is "activated" while the module is already running)
Just patched the toolset for 1.04 - 870 (and released the source code in case I don't patch quickly enough for you) I moved all the OnListen event code to a separate erf and added support for the NWNX4 chat plugin (a csf component will dynamically choose between spawned listeners or the NWNX4). [sorry I changed a few script names, but it should be obvious). It needs a little bit more testing. Next I will add a GUI input (or support for the DMFI GUI input), but if you use the csf onListen API, your code should work well with any of the 3 listening schemes.
oops. You can find "dmfi_inc_listener" in the demo module. (about 4 lines of real code) Since listeners in NWN2 seem to cause a bit of overhead, I'm working to get OnListen "event generators" working for the nwnx-chat plugin and for text entry/UI box. But the API in dmfi_inc_listener will be identical, so your application code won't care what system you use.
Posted by warpath98 at 2007-02-04 04:08:16 Voted 9.50 on 02/01/07
While compiling scripts there was an error with csf_e_onlisten. It used #include "dmfi_inc_listen" which doesn't exist. Apparently GetLastHeardSpeaker() is part of that include. I installed the lastest DMFI package, hoping it would be included but no such luck.
Posted by warpath98 at 2007-02-01 04:31:44 Voted 9.50 on 02/01/07
Very Good Tool that saves some time. Documentation was a bit confusing, as I think there were some references from the NWN version.
I do have some plans for extending this to creature and other events (the NWN version had that). As you said, it is pretty easy to do: Just add the event to the list and create the scripts. You can just as easily have more than one set of events/scripts for different creatures (NPC set, monster set, etc). What is really missing from the toolset is the ability to assign sets of scripts to a creature like you could in NWN. So that is on my list. Here is the rest of my list:
1. general cleanup, bug fixes, clean up demo mod
2. add extensions (and script assignment tool) for creature & other events
3. include a persistence (PW) framework like I have for the NWN version
4. write a set of components for some existing systems
5. write an install script interpreter, so you fully automate system instalation. So you can write an install file like:
> copy contextmenu.xml /UI/default
> import HCR2_core_system.erf
> import HCR2_csf_components.erf
> instance waypoint:HRC2_core
> if "Install Rest System?" install "HCR_rest.csf"
I hope I can get a few of these done this weekend. (I'ts been a way busy month)
Posted by GreenDragon5000 at 2007-01-22 15:32:11 Voted 10.00 on 01/21/07
Any plans to extend this to other events? In particular I am looking at the creature events, for a custom xp script component. I have made it work in my mod by making a new csf_e_ondeath event and adding it to the initialization process, which was amazingly simple to do. This saved me from changing the default scripts which caused me headaches with NWN1 updates. Just wondering if this is likely to be supported? _________________________ Charlie's UI | Charlie's Item Modifier | Charlie's Starter Scripts
Posted by ViaConDiablos at 2007-01-21 23:37:59 Voted 10.00 on 01/21/07
Amazingly slick!
Really really nice to add systems _________________________ Come with me...
Posted by GreenDragon5000 at 2007-01-21 12:19:11 Voted 10.00 on 01/21/07
I wanted a way to separate my PW sub-systems and make them more accessible when they are ready to share on the vault. I considered using CSF, HCR or neither. After looking at both I think that CSF will make sub-system integration much easier for module builders and scripters.
CSF was easy to install, and it was easy to make a component for my sub-systems, which then worked first time.
Using CSF will make in-house management of my PW sub-systems easier by allowing them to be separated where they would have been forced to be merged at the module events, allowing easier integration of the work from several builders. If nothing else it was worth the time taken looking at CSF for that alone.
CSF sets a standard, based on community consultation, which will greatly improve the ease with which scripted content is shared.
Posted by MyHouse at 2007-01-14 14:08:55 Voted 10.00 on 01/14/07
This sure will limit my bioware posts! Incredible concept and easy to use. Thanks for the work.
Posted by Abraxas77 at 2007-01-01 19:04:40 Voted 10.00 on 01/01/07
True CORE foundation is right ... this framework is slick. I love the priority concept for event scripts. The plugin makes integration and maintaince a snap--not just for the CSF, but for any CSF plugin you might install.
Converting old systems to CSF plugins is honestly a cinch ... worth all 60min (max) of your time! _________________________ Lead Script Design The World of Palladium II DMFI GUI Guru
Granted I've done minimal testing, but looking at the framework side alone of this (this is really only a framework) vs. the framework side of HCR, I think this is a ahead of the HCR with the inclusion of the plugin to do the work for you.
For me, the plugin inclusion is really the highpoint to this scripting package where a complex set of instructions is made simple via the plugin.
If you are building a PW or a campaign where you will consistently be altering the base rules, any builder would benefit from having a core foundation to build their module upon. Right now my suggestions are to look at this package and the HCR as base systems. Each seem to be very solid efforts at addressing a fundamental problem for builders who use multiple systems.
This one is cleaner with less peripheral stuff. No conversation, no subsystems - a true CORE foundation - whereas even the CORE HCR comes with some extra stuff.
Note: I should state I worked with EPOlson in discussions leading to this package being developed but I really did little to nothing except give ideas and discussion. For that reason, I'm not going to vote but if I choose one system for my campaign, I *think* it will be this one because it is strictly a building foundation with nothing else but hooks for doing what needs to be done.
You must be Logged In to post comments in this section.
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 2008-02-28 21:40:25
