I always wondered why most computer RPGs were suspiciously silent about providing the player a base of operations. Many old RPGs just assumed you were just another adventurer, always on the road for the next adventure.

Perhaps the first CRPG in which I actually ran into player housing was The Elder Scrolls IV: Oblivion. There was something grandiose about purchasing a house. Deepscorn Hollow was my favourite – plenty of dark beauty.

But long before that game, I was already trying to make this kind of player housing a reality. In Neverwinter Nights.

$ ls -l "modules/Ilmryn's Home 0005.mod"  
-rw-r--r-- 1 wwwwolf users 568276 22.3.2003 modules/Ilmryn's Home 0005.mod

This goes in a long line of things that I just randomly thought was a good idea and implemented and it kind of turned out to be feasible, if a little bit difficult in the long run. NWN has some excellent modding tools.

However, it’s not my idea by long shot. People have been doing weird hacks with the methods I’m about to describe for a long time.

Player housing from scratch

So, as an adventurer, would it be awesome if, after a long and challenging adventure, you could just return to your home or base of operations. Drop your loot in chests, put the fanciest items on display on the shelf. Head off to another exciting adventure!

You can! Only problem is, NWN doesn’t provide any of such functionality. The game is structured around individual adventure modules, but those modules are always entirely separate experiences that have a start and end. They offer no persistence. Once the module starts, all you have is the ability to save/restore games and export your character; you can’t restart the module with another character and expect everything in the module to be exactly as you left it with another character.

Room for improvement

Persistence wasn’t built in in NWN originally, but it was achievable. Kinda. It turned out to be extremely important for multiplayer, of course – people built persistent worlds that were essentially MUDs, and with a little bit of code injection, and later using official API support, they could finally store the state of objects on the fly. But, of course, this is of limited joy to single-player game players.

I have to remind you that the following guide is a hack based on the original NWN capabilities. In 2003, this was the only sane and easy way to achieve persistence. Nowadays, when NWN also supports true persistence via database (including GetCampaign*(), SetCampaign*(), StoreCampaignObject(), RetrieveCampaignObject(), etc), this could probably be done more elegantly with a little bit of scripting.

This hacky method of mine doesn’t require scripting, just absolute recklessness and good backups.

The process

First, we need a few programs. You obviously need the Aurora Toolset. You also need an editor for NWN files. TlkEdit is pretty damn good.

First, construct your amazing home using Aurora. For a rhetorical example, I’m building an shop for an alchemist character of mine from my short stories.

You obviously need a bunch of shelves and crates and whatnot. You can use any of the standard containers in the toolset, but you need to remember to remove the scripts (which are used to normally generate the random loot) and set the Plot flag so you won’t accidentally destroy the containers for whatever reason.

Then, just save the module! Now, you can just go and play the game. Adore your home, set things up, put your loot in shelves, and then comes the crucial part – save the game, and save your character.

After this, you can easily open up the module in TlkEdit. Here’s how the module looks like when opened in TlkEdit:

Your save game appears in saves/ folder inside NWN directory (or wherever the directory is located on operating systems post-Win98SE era), and has a bunch of files. There’s screen.tga, player.bic, portrait.tga, saveinfo.txt and a file that’s basically a copy of your module file, except with the file extension .sav. You may notice it could be a big bigger than the original file.

The area etries have changed, obviously. The biggest change happened in module.ifo. Yep, if you extract the module.ifo entry from both, you’ll notice there’s a whole bunch of new stuff:

  • Mod_PlayerList
  • Mod_TURDList
  • EventQueue
  • VarTable
  • Mod_Tokens
  • …and lastly, a rather interesting and tell-tale change: Mod_IsSaveGame is set to 1, rather than 0.

The most spacious part is, of course, the module’s current player list (Mod_PlayerList) which tells where you are and what the characters are. This may look familiar if you’ve opened up an exported character in an editor. You don’t want to have player list around in a .mod file; The game got really confused last I tried. Who knows what it’d try to do now!

Make a copy of the .sav file (and call it, for example, “My Home 0002.mod”). Extract module.ifo and remove all these new entries from the file – and change Mod_IsSaveGame to 0. Delete module.ifo from the module and import your new module.ifo in. Save the module. Copy it to the modules/ directory in NWN. For extra sanity checking, you may want to open this new module in toolset and run the verification thingamabob and save it again.

Now open up NWN, and start up the game, pick the character you exported, and the new module. All of the stuff in the module should still be where they were when you saved the game.