Campaigns

The OC uses a campaign system where there is a central umbrella that connects all the different parts (modules). It would seem that this is a great tool for builders who want to publish a series of modules. So far that has not been a lot of talk about this (I think a lot of people are still getting used to the Toolset), but I think it will become more important as time passes. Here's a thread on the official forum talking about campaigns: http://nwn2forums.bioware.com/forums/viewtopic.html?topic=527622&forum=1...

A success story with some suggestions from Quoll.

My campaign is working smoothly. I also had a hitch getting it to load at first, and it was all simply a naming issue. Make sure your campaign start module is named the same as a real module in your campaign... then I think it was either adding the ".mod" or removing it. I'd check for sure but I'm not near my editor, but if what you have doesn't work, try the other way.

On the campaign vs module resources, so far it seems to me to simply be a cool way to manage resources. If you know you only use scripts, characters, etc for a short time, only load them for that period, then never again. Those would be the module resources. If you have a companion or scripts you use all the time, make them campaign based. It's sort of a global vs local concept (but only sort of).

I've set a personal rule of thumb to never make one of my areas bigger than any of the official campaign modules. That seems the smartest route unless you want to do a lot of testing.

Another benefit of campaigns that nobody seems to realize yet is how well it fits into group workflow! Several people can all be working on different "modules" at the same time, then just import the updates to a master campaign. Pretty cool.

Good luck all!

And more from flem1

Actually, here's a cool thing: campaign resources, AFAIK, aren't stored in savegames. So for a SP mod you could upload anything that might be changed in an "expansion" (i.e. adding another mod to the campaign) as a campaign dialog/script/whatnot, and then allow players to pick off right where their final save from the last mod left off, including revisiting old areas for new content as well as remembering what happened...

And from Max Gamer

There's only one way I managed to solve the unpacking module hang when starting a new campaign:

1) Close down your starting module in the toolset. For some odd reason the toolset is fussy about having it open when making it the starting module.

2) Make a new campaign in the campaign editor and type in the starter module name to be exactly the same as the filename without the .mod extension.

3) Hit the save campaign button.

4) Lastly add your starter module to the list of modules the campaign will use. This last step may not be essential to get the starter mod loading but will definitely be needed later on.

Step-by-step guide to creating a campaign

NWN2 uses a campaign system where there is a central umbrella that can connect a group of modules. It would seem that this is a great tool for builders who want to publish a series of modules.

This assumed you have a module that you are working on. I'm going to do this with my SKS series, so SKS01 will be my starting module.

  1. Open the Toolset without loading a module. Apparently there is an issue with having your starting module open while you do this.
  2. Click on "Plugins" > "Campaign Editor" to open the CampaignEditorForm
  3. Click "Add Campaign" in the upper right hand corner.
  4. You should see a new entry appear called "New Campaign." Click on this and the properties window will fill in with our blank campaign.
  5. Edit the fields in the properties window, giving your campaign a name, description and display name. Feel free to go through the other options to see how they work. Remember that you can also come back and edit your campaign options, so for now let's move on once you have the basic "Appearance" information.
  6. In the section below the properties window, click the "Add Files" button and choose your starting module.
  7. This part I'm not too sure about: click on the module you just added and click the "Set Module to use Selected Campaign" button. I missed this part and had to go back and forth a few times in order to get the campaign options to light up in the Toolset. As a result, I can't say for certain if it is the selected module that you are setting to use the campaign, or the currently open menu. If someone could comment on that point, it would be much appreciated.
  8. Finally, choose "Save Campaign," again in the upper right hand corner. Now you can close dialog window.
  9. Open your module that you added above and test to see if it is using the campaign by right clicking on a blueprint and making sure that "Copy Blueprint" > "Campaign" is a working option. If not, see the point above.
  10. Once you get it working, save your module. You should now have a module file in your My Document's modules folder and a campaign in your My Document's Campaign folder. Start up the Toolset and try to launch your new campaign via the New Game > Campaign choices.

Thanks to all who contributed to this thread in the official forums, which is where I learned how to do this. I've pulled some great excerpts in the page above this.

Naming Conventions

The Official Campaign uses the following conventions in regards to keeping track of modules and areas across the whole campaign. All of this seems to allow a convenient way of tracking where things are in the campaign.

Modules

Each module has a number in the tens of hundreds, followed by an underscore and the name of the module (eg. "1300_Old_Owl_Well.mod").

Areas

Each area in that module has a number within that hundred, followed by a short name of the area (eg. "1302_oldowlwell").

The display name for the area has the area id number in curly brackets preceding it (eg. "{1302}Old Owl Well").

The tag of the area seems to vary between the display name without the number and without spaces, but still capitalized (eg. "OldOwlWell") or the area id with the name (eg. "1304Bonegnasher"). Best practice for module builders would seem to be to always include the area id in the tag.

Scripts

Scripts specifically attached to this area, and this area only, are in the form of the area id and the script type (eg. "1302_enter").

Waypoints

Waypoints seem to use the area id as well. For instance, the initial entrance to the area 1304Bonegnasher is a waypoint with the tag "1304_enter." Note that this is the localized name for the waypoint, as well, which allows for easy reference.

Doors

Doors with transitions can also follow this convention in the form of:
plc_dr_ < id of the current area > _to_ < id of the target area >

For example, if you were setting up a transition between areas 1304 and 1305, they could be tagged as "plc_dr_1304_to_1305" and "plc_dr_1305_to_1304". Unlike waypoints, doors display their localized names to the players. This means that you will want to wrap your localized names in curly brackets.

Versioning control in a campaign

Note: There's a version control option under the Options menu, but at this time I don't know how one would hook into it. This is a poor man's solution that is easy to use.

I like to save multiple version of my modules just in case something happens. It's also nice to be able to test out something crazy, and roll it back to a previous version if you have to.

A simple way to do this with modules in a campaign is choose the "Save As" option, but I'm always afraid I'm going to continue working on a saved version instead of the one in the campaign. Nothing is worse than testing your module than suddenly realizing you've just wasted 20 minutes in the wrong version. A better way I've found is to simply copy the module and change the name. This allows your named (without version numbers) module to be the latest and greatest that shows up in your campaign.

As an example, I use a system where the first number is the release status, and the second number is the version. The release status is "0" for development and "1" for released. If I need to make large changes, I increment it from there, so if I were to totally redo something I'd change it to a "2." So my first module is the name of the module + "_0_001" and every time I increment it I increase that last number by 1. The first released version is "_1_001." As I fix bugs and update for patches, I continue to increment the last number.

Usually, for me a version is a day's of work or a major change that I don't want to screw up. As I progress with more and more versions, I usually burn them off to a disk... or just delete them. ;)

Use whatever system you want, but some sort of version control is a great idea. So is backing up your files.