How to Develop Chronicles With Working Scenes
by Jason VandenBerghe

The Big Idea

This tutorial is designed to give you enough information to allow you to create chronicle files for Vampire: the Masquerade - Redemption with working scenes in them. The process of doing this can be non-obvious, and can often seem like a maze of twisty little passages, all alike, but it is well-worth the effort to learn. Once the various pieces are in place, the system works very well.

Some General Words About Storytelling With the NOD Engine

Vampire is a stunningly adaptable game design. Using the tools that come with the game and that are available for download, players and storytellers can adapt the game to virtually any conceivable need for online play. The only thing standing between the storyteller and this freedom of online real-time RPG play is learning the skill of using the design tools, and the knowledge that skill is based on. In learning how to design my own online chronicle, I struggled to weave my way through the convoluted pathways of the various files, directories, and arcane structures required to assemble a playable, fun experience. I had to discover how much of it worked on my own, for lack of publicly available information, and so I seek to fill at least part of that void with these tutorials.

If you are just starting out in your career as an online Storyteller, there are a few things you should know about what you can and can't do with the NOD engine and tools, and a few things you should know about what you will need to know in order to bring your vision to full fruition.

There are basically three distinct levels of involvement available to the end user (that's you). These three levels get progressively more difficult to use, and so you will be most effective as a Storyteller if you aim your chronicle design at the level you are most comfortable with. The three levels are: the in-game ST system, The Embrace level editor, and the Codex scripting system.

The In-Game ST System

Nihilistic Software has in my opinion revolutionized online RPG play with Vampire: Redemption. Part of this revolution is the inclusion of a Storyteller (ST) mode. ST mode gives the Storyteller a huge amount of power without ever opening up a level editor, making a single patch, or modifying or creating any game configuration files.

The interface for this style of Storytelling is described to a certain extent in the documentation that came with the game (Chapter Five: Multiplayer and Storytelling). That is the best place to start with learning how to use this system.

The ST system has several key limitations that make it the least powerful option for a storyteller who wants to put on a chronicle. In order to understand these limitations, it's important to understand how building a map using this system works.

To build a chronicle using the in-game ST system, the storyteller must begin an (empty) multiplayer game, using a map file that she has downloaded or that came with the game. The Storyteller then walks physically through the level (either as a character, or as the floating ST Head of Doom), and physically places every prop, item, and enemy that they wish to have in the chronicle. She then saves the level locally on her machine, and bingo, she has a chronicle.

To play this chronicle, the Storyteller logs on (either to won.net or to her local LAN), and creates a game from this save file. Players then join in, and they are off to the races.

Because of the style of creation involved, certain types of commonly wished-for features are not possible to place using this ST system. For example:

1. Doors cannot be placed. The ST is stuck with the doors (both in-level and level exit doors) that came with the blank level. They can easily block doors with objects, but they cannot add connections to new areas.
2. Pre-scripted conversations are not possible. The Storyteller has the ability to possess any character at any time, and thus real-time conversations are straightforward (and, a heck of a lot of fun), but the scripted conversations you see in the game are not possible.
3. NPC stats cannot be altered. Although Nihilistic has provided a huge list of enemies to fight, the Storyteller does not have the option of generating new enemies, or changing the existing enemies' powers.

Using this system, Storytellers can open a blank map, populate it with whatever they wish, and let their players run amok in that map. Pretty amazing when you think about it.

But it pales in comparison with the RAW UNBRIDLED POWER offered by The Embrace, Nihilistic's editing tool.

The Embrace

The Embrace is a licensed and updated version of id software's QERadiant, the level design tool that made Quake III. Nihilistic has modified it to suit their needs.

The tool will allow you to produce new map files that suit your needs. Building maps is a very time-consuming and difficult process, but it is well worth the effort. By doing so, you will gain full control over the layout, look, and content that you are delivering to your players.

However, there are still a few surprises waiting for you. Here are the two major ones:

1. You still cannot build pre-scripted conversations using exclusively The Embrace. In order to do that, you're going to have to get your hands dirty in JAVA, which, if you can manage it, will pay off huge dividends for you.
2. You also cannot build maps that evolve automatically during play (that is, you cannot add scenes) without doing some JAVA coding. You are limited to building "one shots", that you can either update after a round of play with new bad guys, or that are just empty maps that you can populate with the ST system discussed above.

Even give these limitations, the benefits of designing your own maps is obvious. It will unlock your ability to pick whatever location you desire to set your chronicle in.

If you want to design a chronicle of the style found in the two multiplayer maps that shipped with V:tM-R (To Curse the Darkness and Leaves of Three), you are going to need to get a little bit more down and dirty.

Codex and Java

In order to make maps that change (using the system of layers found in The Embrace) or that interact with the player automatically in nearly any way will require some Java programming on the part of the Storyteller. This is a large step for some, and a small step for others. If you have no previous programming experience, Java is a good place to start, but keep in mind that you will not become a fluent Java programmer overnight. Programming is an arcane art, and one that is learned over months and years.

Codex is a set of Java classes designed by Nihilistic that make up the bulk of the in-game logic, controls, and effects that you see in both the single-player and the multi-player modes. Nearly all of the functionality you see in the game has its roots in Java development, which of course means that nearly everything you see in the game is something that a Storyteller can put in their own chronicle.

While the prospects are very exciting, the key to getting through the pile of knowledge you must have in order to create such a chronicle is to have access to good sources of information about Codex, The Embrace, and NOD development in general. These are, as of the time of this writing, unfortunately very scanty.

The Nihilistic File and Directory Structure

Regardless of what level of involvement you are interested in as a burgeoning Storyteller, you will need to have some familiarity with the structure of the Nihilistic game files and directories in order to run games effectively. Much of the structure of these files is documented in the NOD SDK, but little attempt has been made there to put the facts listed into an overall picture, leaving that to the individual developer. It is this picture that I will attempt to paint for you now.

There are several configuration files involved in assembling an online chronicle. Each has a specific purpose, and they all fit together to form a web from which the game engine can deduce the structure of your chronicle. Each is a simple text file, editable with Notepad (on Windows) or SimpleText (on the Mac). They have extensions like .NSC, NLS, etc. I will detail these files below, after a brief discussion of the directory structure.

In addition to these configuration files, there are a ton of data files, from texture files to level files to icons and more. Editing these files is a bit more complicated, but with the right software, you can generate nearly everything you could need for a new chronicle file.

Directories

Nihilistic did a clever thing with their directory structure. Their development team used a well-organized and detailed directory structure during development, and their engine was developed to use this directory structure. Files were sorted by types, and their destinations were hard-coded into the engine. Once development was completed, all of these files were gathered together into large archives (.NOB files, which are simply .ZIP files by another name), but the original path information for each file was kept inside the archives. That way, the engine looks for the files in the same directory, just inside the .NOB file. Make sense? No? Okay, it goes like this:

The "development" directory structure for Vampire looks like this:

\Vampire
	\3D
		\Anims
		\Materials
		\Models
		\Motions
\Chronicles
\Codex
\Conversations
	\Crypt
	\Extras
	\Levels
	\Maps
	\Materials
		\General
		\London
		\New_York
		\Prague
		\Vienna
	\Misc
		\AI
		\Explosions
		\Foley
	\Paths
	\SaveGames
	\Scenes
	\Sound
	\Sounds
		\Actors
		\Environment
		\Objects
		\Voice
	\Stores
	\Strings
	\UI
		\Icons
		\Materials
	\Video

You'll notice that if you look at a clean installation of Vampire, most of these directories are missing. That's because the files that were in these directories have all been combined into one of several large .NOB files, which live in the root vampire directory (codex.nob, levels.nob, lmaterials.nob, local_eng.nob, and resource.nob). However, if you open these .NOB files (with WinZip or the equivalent), you will notice that each file has its local directory information preserved in the archive. The engine uses this directory information to simplify its search through these very large files, and later, when you are generating .NOB files like this, you will do the same.

(Note: if you plan on doing much Redemption development, I highly recommend downloading the NOD SDK. In this file, you will find most of the source files that Nihilistic used to create the game as you see it, and looking at these examples is one of the best ways to learn more about how the structure actually works. Installing the SDK will create many of the directories listed above, and populate them with the appropriate data files.)

The Configuration Files

The first configuration file to concern yourself with for a new chronicle is the .NSC file, which (somehow) stands for Nihilistic Chronicle file. The engine looks for this file (along with most of the other chronicle config files) in the Chronicles directory off the vampire root.

When a user selects "Create Game" in the multiplayer interface, the engine builds its list of available multiplayer chronicles from the .NSC files it finds in this directory. If you simply add an .NSC file to the Chronicles directory, you will see that file appear in the list of available chronicle files.

As a quick aside, you may notice that the files that were shipped with the NOD SDK (if you haven't downloaded this yet, uh, download it) in the Chronicles directory have names like MP_CurseDarkness.nsc, but they show up in the pick list as "To Curse the Darkness". How is this possible? There is a file in the \strings directory called chronicles.nls (more about .NLS files can be found below). This file is simply a list of filenames, and what their "textual" equivalents are. Below is the file as it ships with the SDK:

// *****************************************************************
//
// CHRONICLES.NLS
//
// Chronicle name string table
//
// *****************************************************************

// ................................................................. 
// MP Chronicle names
// ................................................................. 

MP_CurseDarkness     To Curse the Darkness
MP_LeavesThree       Leaves of Three

MP_Prague_Null       Prague by Night (Empty)
MP_Vienna_Null       Vienna by Night (Empty)
MP_London_Null       London by Night (Empty)
MP_New_York_Null     New York by Night (Empty)

MP_DAInn             Dark Ages Inn (Empty Salon)
MP_PrinceMansion     Prince's Mansion (Empty Salon)
MP_RaveClub          Rave Club (Empty Salon)

So, the NOD engine looks in the Chronicles directory for all the .NSC files it finds there. It then compares those filenames to this list, and if any of the filenames (minus the ".NSC") match any of the first words on any of those lines, it replaces the filename in the list with rest of the text on the line. Note that the lines that begin with "//" are comments, and are ignored by the engine. So, if you want your chronicle to have a more readable name than the filename you give, you should add a line to this file. It is read-only as shipped, so you will have to change its file attributes to edit it.

So, back to the .NSC file. The .NSC file has several parts, which are detailed in the NOD SDK documentation. Go read that, and then come back here.

There are three sections to an .NSC file: the locations section, the exits section, and then a list of details that the engine needs to know.

(Note: In truth, I don't believe that you strictly must keep these sections separate. You may at any point in the file declare a "location" line or an "exit" line. It is just good organizational practice to keep the sections distinct.)

.NSC Locations

The NOD SDK documentation gives an example location line, as follows:

location OldTown P1_OLDT.nil OLDT_7_1.nsd mapPragueOT.nui mapOldTownCenter 0x0060

There is a lot going on here, so I will talk about each section in order. Because each of the configuration files are interdependent, you may want to refer back to each section as you learn how they refer to each other.

The first field in the location definition line is just a keyword ("location") that tells the engine that you are declaring a new location in your chronicle. A location is a single map.

The second field ("OldTown") is an identifier (ID, or name) that you choose for the level. You will use this identifier throughout the rest of the configuration files to refer to this level, so make it something unique that you can remember.

The third field is the name of the .NIL file to use for this location ("P1_OLDT.nil"). The Embrace level editor takes .MAP files (which are a simple and fast file format for the level editor to use), and generates .NIL files for the engine to use. .NIL files contain all of the geometry and static object data for your map. They are the "level" file.

The fourth field contains the name of the scene file that the location begins in ("OLDT_7_1.nsd"). Refer later in this document to the section on scenes for an explanation for what this means. If you do not wish the level to begin on any scene, you may simply put "null" for this field.

The fifth field gives the name of the location map to use for this location ("mapPragueOT.nui"). The "location map" is the map that the player sees when they hit the (M)ap key during game play (Prague, Old Town,. Vienna, London, etc). .NUI files are the Nihilistic User Interface format. I don't currently know what format these files are in. You can give "null" for this field if you wish.

The sixth field is the ID of the map location to activate when the player visits this location. This is the little red diamond that appears on the map itself that gives the name of the location when rolled over with the pointer. You may give "null" for this field if you do not wish this location to show up on the map.

The last field is a series of flags. These flags are described adequately in the NOD SDK documentation. Keep in mind that these are hexadecimal flags. If you don't have any experience with hexadecimal math, go and learn it. It's simple, and you're going to need it if you plan on doing any significant computer work.

Give one completed location line for each map area you wish to have active in your chronicle.

.NSC Exits

The next section in the .NSC file is the exits section. The exits section creates connections between levels in a chronicle. In order to do that, you must declare which exit number to connect to, for both the map you are leaving from and the map you are going to.

In order to understand exits, you must understand playerstarts, and know a little bit about associating scripts with template brushes in The Embrace. If you haven't read the introduction to 3D editing in the NOD SDK, this would be a good time to do that.

Playerstarts are special brushes that the user can add to a map that tell the NOD engine where to place the player when they enter a new area. There can be up to 16 different playerstart locations in a given map, and these 16 playerstarts are numbered from 0 to 15. You can have more than one of a given playerstart number, and in fact you generally should have four, because that is how many players may be arriving in them at any one time (the entire party). If you examine Nihilistic's .MAP files, you will see that generally they cluster their playerstarts in groups of four.

So, that's where the player arrives. They leave (generally) by clicking on a special brush in the map that has a "ClickExit.class" script associated with it. You can assign Java scripts to associate with special brushes (called "templatebrushes") in a map. This is how you make a door. There is an excellent description of how to do this on PlanetVampire. For now, just understand that when you associate the ClickExit script with the exit door, you give the door an exit number. This is how the game knows which exit you are leaving from.

So, now the Storyteller knows the number of the exit to leaving from, and the number of the playerstart to arrive to. He would associate these exits with a line like this in the .NSC file:

exit OldTown, 3 EastGateNight,2

This will associate exit 3 in the Oldtown location (which has been declared earlier in the chronicle file) with exit 2 in the EastGateNight location (which has also been declared earlier). Simple.

Note that this connection is two-way. That is, if you want your players to be able to travel back and forth through this portal, you will need to insure that the exit has playerstarts near it that has the same number as the exit. So, in the above example, the OldTown exit #3 (which will be, say, a door templatebrush with the ClickExit script associated with it) should have four playerstart3's nearby to insure that players returning from EastGateNight end up near the door they expect to appear from.

Other Details

Lastly in the .NSC file is a list of details that is the grease in the wheels of your chronicle: script, metafile, portal, reviveloc, and flags.

The script line tells the engine which Java class to use as the primary handler to "run" this chronicle. This can be used for a whole variety of things, but is critical if you intend to have scenes that change the nature of your map. Advancing through scenes is handled by the "advance" handler in this chronicle script, and with it, any layers you may have associated with scenes (see the section on scenes below) will be inert.

Read that again. In order to make scenes work in the NOD engine, you must do a very little bit of Java coding. You will likely be able to get away with mostly cut-and-paste (and if you have downloaded the NOD SDK you already have several good examples of what the code should look like), but you will need to download a Java compiler, set it up, and compile your new chronicle script.

Do not append ".class" to your chronicle script declaration. Simply give the name of the class, like:

script MPCTDChronicle

The metafile line simply gives the name of the .NMF file to use for this chronicle. Keep your names consistent. If you are building DarkWorld.NSC, use DarkWorld.NMF, like this:

metafile DarkWorld.NMF

The portal line gives the name of the location and the playerstart number to use when the player uses Walk The Abyss in the Game, like this:

portal MyHaven 15

The Nihilistic designers tend to reserve playerstart 15 for this purpose.

The reviveloc line gives the name of the location and the playerstart number to use when the player uses the "Revive" option on the escape menu during play, as:

reviveloc MyHaven 0

The flags line is described well in the NOD SDK. Keep in mind that it is in hexadecimal.

The .NMF file (Nihilistic Meta-File)

The .NMF file is referenced in the .NSC file, and it gives the NOD engine a list of what other files and small pieces of data to use for this chronicle. The NOD SDK documents this file well, so refer to that documentation.

If you do not specify an .NLS file to use in the metafile, many of the items that appear in your map will be described as "PROP". This is the default text that the game uses if it can't find a string. You can read more on this later in the section on the strings file (.NLS).

The .NMF file goes in the Chronicles directory, with the .NSC file.

Scenes

There are three two primary files used in building scenes for your chronicle, but you will also need to make sure that your .NSC file and your map file (.MAP) both refer to the appropriate data before your scenes will be up and running. This is also the part of the development that requires a little bit of Java know-how, so you'll need to download and install a Java 1.1 compliant compiler. Nihilistic used Microsoft J++ to compile the scripts in the game, but has also tested Sun's JDK 1.1.8 successfully. Sun's compiler is also free.

The .NSL File

The first (and most important) file to create is the .NSL file (Nihilistic Scene List). This file lists every scene you have available to you in the chronicle. This means every time that your map changes in some automated way, you need to declare a new scene in this file.

Each scene declaration in the .NSL file includes: the name of the scene (in square brackets), followed by a string ID (see below in the strings file / .NLS section) for the SHORTDESC and LONGDESC for each scene. These two strings are descriptions for the scene, and they are used in various places.

The SHORTDESC is displayed briefly at the top of the screen when the player arrives at a new location, and is used for the name of any save games that are made while in that location.

I've not seen the LONGDESC in use yet. Stay tuned.

Here is an example scene declaration:

[CNVT_3_1]
SHORTDESC=CNVT_3_1S
LONGDESC=CNVT_3_1L

Nihilistic uses four letters for a location, followed by the scene and subscene numbers as a standard convention for these identifiers.

This .NSL file is not actually used by the NOD engine. It is used by The Embrace editor, specifically by the Scenes Editor in The Embrace. This is described below.

The .NSS File

The second file you need to have for your scenes is the .NSS file (Nihilistic Scene Specifications). Each line in the .NSS file corresponds to a scene you wish to be able to "skip" to in the Scenes pane in the ST in-game interface. For example:

Scene 2 1 CTD_SCENE_2_1S

This line is the first line from the To Curse the Darkness chronicle .NSS file. It declares that the ST will be able to skip to scene 2 subscene 1 from the scene pane, and to use the .NLS ID CTD_SCENE_2_1S as the text for the scenes pane.

NOTE: The NOD SDK documentation is inaccurate on this point. The example they give as a "Sample NSS File" shows each line having the actual scene identifier (the one in square brackets above) for the scene description ID. I initially thought that this meant that the engine would figure it out, but I found that the engine actually ended up displaying the ID itself as I had given it for the scenes pane text, because it couldn't find a string in the .NLS file by the name I gave. Append an "S" to the tags given in the sample, and the sample file will work fine.

Once these two files are in place (they go in the Chronicles directory, with the .NSC file), there are two more steps to getting scenes working: updating the scene data in the map file, and updating the .NSC file.

Layers in a .MAP file

In order to create a map that uses scenes effectively, there are a few things you should know about layers.

A .MAP file contains single "static" layer that contains all of the basic geometry and any objects that will be present in all layers. In addition to this static layer, there are 32 layers of non-static objects available. Any of these layers can be associated with any scene, using the Scene Editor (see below).

A layer may contain only template brushes. Regular "static" brushes can only exist in the static layer. This means that if you want to have a wall or a block of some kind that appears on one scene but not another, you will need to convert it to a template brush, or it will stay in the static layer. This is not a problem for templates.

In order to do this, select the brush you wish to move to a given layer. Right click to bring up the quick menu, and select "templatebrush". This will convert the brush to a template brush (if this is new to you, there is a great tutorial on PlanetVampire that describes how to build a door that talks specifically about this issue). However, if you leave it at this, the brush will not appear in the level, as it has no template associated with it yet. But, you may ask, if I associate a template with the brush (like tracker_thing), won't that mean that the brush will behave like the template, instead of like an inert wall?

Yes, and there is a special template to get around this problem. It's called tracker_thing_null, and it is located in global.miscellaneous section. Assign this template to the brush, and it will appear in the layer appropriately. The brush will appear to be intert; the template does nothing but mark the brush as a template so that it can be stored in a dynamic layer instead of the static layer.

Keep in mind that if the center of a templatebrush does not fall inside a sector in the map, the templatebrush will not be drawn. Extend your sectors around these templatebrushes.

The Scene Editor and the .NSL File Again

So, now you should have a .MAP file with one or two layers in it. Now you must tell The Embrace which scenes apply to this map, and which layers to associate with each scene.

To do this, open the Scene Editor (Shift+s). You should see a scene called "_STATIC SCENE_". The first step is to open a scene list file (.NSL). This is the file that is used only by The Embrace, and is discussed above. Click the third button from the left, and pick your .NSL file in the dialog that follows. This will load your scene list into the Scene Editor.

Keep in mind that you are never going to want to associate the same scene with two different map files. Each scene should be unique, and should only occur within a single map file. If you don't do this, The Embrace will end up overwriting the scene data for one or the other of the maps.

Now pick the scenes you want by clicking the left-most button. This will show you a list of all the scenes in the .NSL file you selected. Note: double-clicking the scene does not seem to work here, although it will close the dialog box. Instead, select the scene you want, and click OK. The new scene should appear in the scene list in the Scene Editor. Repeat this for every scene you wish to apply to this map. Note also that the Scene Editor will ask you if you wish to save the scene every time you switch scenes. Do this. It's a tad clunky, but with a little practice it becomes fairly natural.

Now, to associate layers in the .MAP file to a given scene, simply select the scene in the Scene Editor and click over to the Layers tab on the right side. Check each layer you want to associate with that scene, and save the scene data. You can close the Scene Editor after that.

Exporting the Scene Data

Now The Embrace knows what data to export for a given scene. You are getting closer to having working scenes in your chronicle. The next step is to export the scenes, and to then make sure that your .NSC file has the right data in it.

Re-export your level. Be sure to select to export the scene data. Exporting the level file will generate two kinds of files: a .NIL file, which contains all of the static geometry data, and one or more .NSD (Nihilistic Scene Data) files. The .NIL file will end up in the Levels directory, and the .NSD files will be placed in the Scenes directory.

The Embrace will create one .NSD file that contains all of the static template data in the level. This file will have the same name as the .MAP file, only with an .NSD extension. It will then generate one .NSD file for every scene you selected in the Scene Editor. These files will have the same name as the scene name you gave in the .NSL file. So, if you exported "DarkDomain.MAP", a level with two associated scenes (DARK_1_3 and DARK_3_2), your Scenes directory will be updated with the following files:

DarkDomain.NSD
DARK_1_3.NSD
DARK_3_2.NSD

This is why you must not associate a given scene with more than one map; the files would have the same name and would be overwritten.

Updating the .NSC File

Finally, in the chronicle file (.NSC), you may give the file name of the scene file you wish to start with when the players first arrive at the map. You can think of this as a kind of "scene initialization". It is not required, but it is convenient. See above in the section on .NSC files for the format of how to do this.

The Chronicle Script

The final step in the process is to create and prepare the chronicle script. Remember way back in the section on the .NSC file where it specifies a script to associate with the chronicle (like MP_CTDChronicle)? It's time to write one of those.

The best way to do this is to cut and paste the code in MP_CTDChronicle.java (or MP_LOTChronicle.java) into your own class file, and make modifications as necessary. It is beyond the scope of this document to teach you how to program Java, so if you don't understand the code in the files listed above, get a book (or get online), and start learning. You won't regret it.

The important thing here is the "advance" handler. This handler is called every time the scene is advanced in the Scenes pane (and, possibly, at other times, but I have little information about this currently). As you can see from the code, the NOD engine passes in the target scene and subscene numbers. Generally, the Nihilistic designers pass this call to a function called "Step", which does the actual work. Notice that the effort of activating a given scene is handled by the call to CodexSequence.ChangeScene, and that it is done by hand.

What this means is that the engine has no internal automatic mechanism for advancing these scenes forward. The NOD engine programmers have provided hooks for developers, and have left the effort of changing scenes up to the user.

You pass the name of the map file you wish to advance, and the name of the .NSD file you wish to advance it to. Note that the player doesn't have to be in the map being referenced (and that it is in fact probably better if they aren't) when the switch happens.

Once you have created this .java file, compile it into a .class file. Almost there; there's just one more trick to getting things running.

Creating the Codex.NOB file

In order for the NOD engine to be able to find this .class file, and thus be able to pass your advance handler the information that the scene is being changed, the .class file must be placed inside a .NOB file named "codex.nob", and this .NOB file must be placed either in the Vampire root directory (bad), or in a subdirectory off the Vampire root that you specify with the -user flag to the main vampire executable (good).

In order to do this:

1. create a user directory (say, \dark) off the vampire root
2. change your shortcut to the V:tM-R executable (or make a new one) to add the following to the command line: "-user dark" (or whatever you name the directory). You may only name one -user directory per execution of the Vampire program.
3. create a .ZIP file that contains the .class file you created above. Turn off data compression when creating this file, and insure that no directory information is retained.
4. rename the file to codex.nob, and move it to your user directory.

If everything went well, and all the pieces discussed above all line up correctly, you should now be able to start up your chronicle, and switch scenes using the Scene Pane in the ST interface.

(If I left anything out of this admittedly complicated sequence, or if I'm just plain wrong about any of it, please let me know, and I will update this file.)

Finally, the .NLS File

The .NLS file (Nihilistic Localized Strings) is the central repository for string data for your chronicle. The format of the file is very straightforward: it's just keys and data, one key per line.

The .NLS file goes in the Strings directory, not the Chronicles directory. Every .NLS key you've created above should be represented with actual data in this file.

That's it. There are several more files that are useful or required for developing quests, conversations, etc, but that is beyond the scope of this tutorial.

Please email the author with comments, concerns, or corrections to this document. Good luck, and happy bloodsucking!