Jump to content


The Black Scourge of Candle Cove -- Tchos' development diary

  • This topic is locked This topic is locked
254 replies to this topic



    Cacoethes scribendi

  • News writer
  • 2,373 posts
Okay, I've finished collecting scripts and materials, and finished playing the other modules and games I wanted to play, so it's time to get started on this. As with my Dragon Age: Origins module of last year, I'm starting this development diary thread to document my experience in creating a module for NWN2.

This will be my first NWN2 module, aside from some tinkering around I've been doing while playing the OC/expansions/various modules. My overall intentions for this module (in campaign format) are to include one main quest in several short "acts", and several side quests that can be done at any time during the module (as many as I have time to add). It will be pretty lighthearted, with bits of drama (or melodrama) and bits of comedy, and things that I hope will be fun to watch or participate in. Areas should have a high density of content. No running around large areas where there's nothing to do or see.

Design choices include no voice acting, and no "cinematic-style" dialogue, because that's how I prefer it. As readers of my blog know, I take umbrage at the trend toward more and more non-interactive cinematic content in what is supposed to be an interactive medium, to make games more like movies. If I use any cutscenes at all, it will only be to direct attention to something important, and only briefly.

My larger dialogue box will be included, and optional. It will be in campaign form, since it will include several features that I've read require that. It will include the SoZ party gen as well as a selection of recruitable companions, SoZ-style party dialogue, and the SoZ death and rest system, as well as a small overland map for one section. It will also feature the quest indicator system I scripted. This goes along with my emphasis on "game" vs "cinematic experience".

If I include any custom loading screens, they'll be in widescreen format, since widescreen is the current standard -- stores don't sell 4:3 displays anymore, as far as I can tell. On modern widescreen monitors, loading screens are ugly and stretched out when they're designed for the 4:3 aspect ratio. I calculate that the correct loading screen dimensions should be 1600 x 600 for a 16:9 display, accounting for the borders, as opposed to the 1200 x 600 for 4:3, if I go with the same vertical dimension, though if I make any at all, I really should make them 1920 x 720 so that they wouldn't need to be blown up at full HD resolutions. Scaling down looks better than scaling up.

I have the main quest and several side quests and NPCs written out in an outline and ready to go now. Since it's the beginning of the month, that makes a convenient way to gauge the time. I'll aim for a release at the beginning of July. I'll make updates on my progress in this thread every day or two.

It should be known that I'm not giving my module the same title as the pen & paper module that serves as its basis ("The Sea Witch"), because I found much in the P&P module to be in need of revision. First of all, the names were bland. Secondly, it was sorely lacking in detail, so I needed to flesh it out anyway. I thought some of the plot needed work, too, mainly in the logistics of the situation. The basics are the same, but there will be some major additions. Don't read the original module if you don't want spoilers regarding the main plot, since that much is the same.

In fact, it was part of the discussion surrounding the creation of the Neverwinter Nexus that partially inspired my choice of module. During the discussion of which tags and categories should be available for modules on the Nexus, "Undersea Adventure" was voted as unnecessary, since there was only one module meeting that criterion across both NWN1 and NWN2. I thought it was a shame that I couldn't find any NWN2 undersea adventures, especially considering Robinson Workshop's excellent Underwater Placeables. When I also found RWS' swimming system, I decided I wanted to create an adventure with an undersea section.

I searched the prefab area on the Vault and Nexus for an appropriate starting town. It needed to have a good dock, since that's the launching point for this module. I also had a specific town size in mind. The original P&P called for a small fishing village, but it also involved some rich merchants in the shipping industry. I liked the merchant angle, so I opted for a larger city, which would also allow me to provide decent suppliers for the player and some quests around town to earn some money.

On the short list of candidates was Grumpy Strumpet Prefabs - City Docks, Outer Harbor Clandestine, Port Town, and Old City. Each had their pros and cons. The best overall was TGS' City Docks. The city was beautifully detailed, and full of nooks and crannies that I could fill with quests. The only reason I didn't use it is that I found it to be a little too heavy duty for my computer to play at a smooth frame rate.

My second choice was Port Town. What I liked about that prefab was mainly the docks themselves, which had numerous long piers with good detail. The town itself, however, was not to my taste, and it was very cluttered. Old City was appealing mainly due to its use of elevation, rather than being a flat city. It would have been a fine choice for a module, but not this one, because the city looked a bit too rich for my purposes. Outer Harbor had some good ideas, and also had some interesting elevation, but the town was a bit too cramped, and built much too close to the water without sufficient safeguards against flooding. In the end, I decided that even though it's likely to be rather recognisable, I'm going with a beautiful prefab by Sébastien, though I need to make a lot of alterations to fit my purposes.

I spent most of the day learning how to use prefabs and how to use TerraCoppa to merge two areas together, since the dock area in this prefab was split up into two areas, right in the middle of the wharf. Most of the time involved troubleshooting, figuring things out, and waiting for the toolset to reload after numerous crashes.

After I got the whole dock area merged smoothly, I fixed up all the seams, found many floating placeables to correct, and extended the ocean to build a lighthouse rock off in the distance. I changed the atmospherics to taste and added some sky rings, and set about naming the map notes and readable signs. I'll be doing some more customising to the place later, changing buildings and such, and deciding which ones I want to use as shops and inns for this module.

For this module I'll need at least 5 locations -- the city, the lighthouse exterior, the lighthouse interior, the underwater area, and some caves. I'll also need a number of interiors in the city, and I'll need to create an overland map. Adam Miller has a classic style lighthouse in Dark Waters, but I couldn't find any permission notice on that work, so I'll just use one of the RWS towers instead. It's important that I get this done quickly, so I can't leave anything waiting on anything.

But before I get into too much fine detail, I'll focus on roughing out the main quest and putting the key NPCs in place. I'm going to try out Kamal's advice on speed building, since it closely matches my own philosophy, and seems like a solid plan.

NPC conversations
One of the things I consider important to liven up a place full of NPCs is to have them talk -- Speaking "barks" when walking around, or when the player tries to talk to them, or having little conversations between each other.

The first instance can be simple ambient chatter that adds to the atmosphere, like "Oh, that bread smells delicious!", or can be used to call a player's attention to something that can be explored.

The second instance I often see used to give a player information, like "I hear strange things are happening in the old Lodge," such as to direct them toward quests. They can also be used to show a progression in the world by acknowledging the player's actions, or other recent events, by updating their lines after things happen.

The conversations between NPCs can serve the same purpose, but in greater detail than a one-liner can, but I think I'll be using them more to just provide extra flavour and humour.

I found an example of how to accomplish NPC conversations in Kaldor Silverwand's Sample Campaign. The campaign doesn't feature documentation, but it's a valuable resource as an example of many useful systems. It took me several hours to figure out which elements were necessary, and how to adapt them for my own NPCs. I had a lot of trouble getting the conversation to fire at all. Eventually I discovered that I needed to have the NPCs set to "can talk to non-player-owned creatures".

The second problem was that when I did get them talking, they spoke the entire conversation at once. I couldn't understand that, since the sample conversation had no delays set anywhere, but it had several seconds between lines, as it should. Eventually, I found the one difference between my conversation and the sample was that mine was set to "NWN-style conversation", and the sample was not. After removing that setting, the conversation proceeded at a normal pace. Good. Now I can make a generic blueprint trigger with an attached script to handle these things more conveniently. I'll probably edit the script to use local variables to select the NPCs I want to speak instead of having it specified in the script itself, so I won't need a new script for each conversation.

I also learned that you can prevent players from aborting a conversation with the escape key or moving around during a conversation (which can mess up some kinds of encounters) by ticking the "multiplayer cutscene" box on the conversation, even though it's not a cutscene. That'll eliminate any disadvantage to using the NWN1-style dialogue box as opposed to the cutscene style I dislike so much.




  • Premium Member
  • 46 posts
The Sea Witch huh? Sounds cool. I like the idea of undersea adventure certainly donít have enough of those type mods.

You think youíre going to have it done by July? Well if you use all prefabs I guess itís possible. But will it be HofF quality? I guess will see. I thought I was going to have my project done over a year ago and well that turned out to be a bit of an exaggeration. LOL

Sounds like youíre off to a good start, Iíll be watching as this project progresses. Donít forget to post an occasional screen shot, Iím particularly interested on how your undersea areas turn out.

Good luck!



    Cacoethes scribendi

  • News writer
  • 2,373 posts
The thing is, I have to finish things on a strict deadline, or risk never finishing them. If I don't set a nearby deadline for myself, then there will inevitably be days that I just don't work on it, and just "think about" working on it, and those days multiply in number until finally I forget even to think about working on it. With a deadline like this, every day is a day that I work on it, until it is done.

As for quality, I'm working with a well-defined plan with a hierarchy of priorities. I must first finish the parts that are necessary, and get them functional and polished, before adding the unnecessary parts. That way, as the deadline approaches, I can decide what optional content I can finish in the remaining time with the same degree of quality, and what parts I'll just save for a future module.




  • Premium Member
  • 46 posts
Procrastinator huh? I hear you friend, LOL. Iím a little guilty in that area myself. What I do is not worry about when itís going to be done but just set a time every day when I force myself to put a minimum of 2 hours work in. Usually in the morning while sipping coffee, my mind seems to have the best sense of focus then.



    Cacoethes scribendi

  • News writer
  • 2,373 posts
I understand. I'm sure we all have our methods that best fit our preferences and priorities. :) Here's today's report:

More explanation of my overall design philosophy, and other design decisions:

  • DM text. Plenty of descriptions, both upon entering new areas, and on signs describing a place you're about to enter. NPCs and objects should also be described. I believe that text has a unique ability to bring an area to life in ways that a strictly audiovisual presentation does not. It also does a far better job of setting a mood or calling attention to important details than a camera shot does, and most importantly, it does not take control away from the player.
  • Lighting is for the player. The player will always be able to see. I'm not going for immersion, but good gameplay, and since I have no gameplay plans that involve the player being unable to see, there will always be sufficient lighting, whether or not it's realistic for it to be there.
  • Quest rewards are shown in advance. As a player, I like to know what I'm getting into, and what I'll get out of it. In this module, when someone offers a quest, you'll get to see exactly what the reward will be, in a DM-text kind of note in the conversation that should be understood not to be spoken by the NPC. Yet more weight on the scale of game vs. immersion.
  • No need to click twice on a door to go through it. When I click on a door that transitions to another area, I don't like having to watch a little animation of the door opening, just to reveal nothing behind it but a black rectangle, which I have to click on again to get to my destination. Why show the door opening if there's nothing behind it? Click on the door once, and it'll take you there immediately, without playing an opening animation. It took me several hours today to figure out how to make that happen.
Also, as I mentioned I would be doing, I'm using folder mode and a revisioning system to automatically keep backups of the last 10 versions of each file, stored both on my hard drive and in Dropbox.

As mentioned above, the door transition code is what occupied much of my time today. I could have handled it with a conversation attached to the door as PJ suggested in the Creating Campaigns thread, but I wanted the cursor to be the door cursor and not the speak cursor, and delaying the transition with a dialogue box is the opposite of what I wanted to achieve. I found the code I needed in a couple of scripts in the Community Scripting Library, and I took just the parts I needed from each, and made a new script to put in the On Open event.

The other thing I spent a lot of time on today was writing conversations and quests, so that was already breaking one of Kamal's speed-building suggestions. I'm re-reading his post on the subject, and I'll switch to those broader strokes tomorrow.

Now, my normal writing style is very verbose, but for NPC conversations, my philosophy is that each line should be for the purpose of useful explanation or entertainment, and no detail just for the sake of detail. I want these quests to be entertaining, and not something you get bored of and just click through to get past the text and on to the fighting.

I'll do my best to have each shop, temple, or inn have some kind of involvement in a quest, if time permits.

I'm writing a lot of the conversations in Flamewind's Conversation Editor, which is conveniently lightweight, and doesn't need the toolset to be open, and has an option to test run through the conversations, clicking on the options as if you were in the game. The limitations are that it doesn't seem to support text formatting or paragraphs, it doesn't have the template list for things like [sir/madam], [race], etc., and of course you can't assign conditionals with it. It's also hardcoded with a tiny font that is extremely difficult to read on my main display, which would make it easy to miss a typo. In the toolset, I have the font set to an easily readable size. It's more useful for writing conversations on my netbook while I'm away.

I also set up the campaign using the instructions here. I searched for an hour or so looking for documentation on what each of the options does, but could only find individual explanations for some of them in forum posts. There was no campaign information in the official toolset help files, or in the Obsidion tutorial PDFs on the Vault, or in the Toolset Notes PDFs. I also looked in Don't Panic, ToolsetCommunityGuide_v4, and Toolset_Manual15. No doubt there was a post explaining it all back on the old defunct Bioware forums. The ones I'm not sure about are:

  • DLGPartySwap
  • GameStateVariableName
  • KeepJournalSynchedToLeader
  • LoaderTipMax
  • NoCharacterChanging
  • OverlandMPLock
  • SuppressRestMessages
  • AutoXPAwarding
  • CompanionXPWeight
The rest are explained elsewhere, or clear enough on their own. I went with 100 for the ConversationDistance based on M Rieder's experience here. I understand there are some other scripts I need to set up somewhere to enable the SoZ death & bleeding system, in addition to setting the PartyMemberDying variable here to "true". Here's how mine is set up.

Posted Image

I also put some horses into a stable, and spent a few hours trying to stop them from rotating to face the player if I clicked on them. The variable that's supposed to prevent that according to the default script (NX2_NO_ORIENT_ON_DIALOG = 1) doesn't work! I also tried removing its conversation default script, setting it to un-bumpable, and setting its walk rate to immobile, but it still rotated itself out of the stable when I clicked on it. That would not do.

Fortunately, I had just finished playing Dann Pigdon's Shaar Moan a few days ago, and I recalled some horses in there that didn't turn to face me, so I looked to see how he did it. He used a custom On Spawn script for it, including the line "SetOrientOnDialog(OBJECT_SELF, 0);" (which is also supposed to get executed with the default script if you add that variable above, and I don't know why it doesn't). So I did basically the same thing, except I left the default On Spawn script in place, and added the necessary code to a separate script that fired with the SpawnScript variable attached to the horse. No more turning horse.

I also want to have that little sun/moon clock to appear above in the player menu.



    Cacoethes scribendi

  • News writer
  • 2,373 posts
Today I spent many hours trying to get the clock and resting system to work properly. Despite following Dann Pigdon's instructions to the letter with the scripts, the clock, though it showed up, did not update the time, and was perpetually stuck on the starting hour, and always showing the sun. Many frustrating hours later, it occured to me to try disabling my overrides. It turned out it was Kaedrin's PrC pack that was overriding my module event scripts such as k_mod_start and k_mod_hb. I suppose to keep the Kaedrin compatibility and still be able to add the code I need, I should use differently-named module event scripts which end by invoking the same scripts that Kaedrin's versions invoke.

The MotB-style resting system finally works, but many of the wandering monster encounter types don't show up. "Beetles", "DangerousForestAnimals", and "NormalDrow" work (though the drow that spawn are non-hostile), but not any of the others I tried. It seems that the trouble is that the other types are calling for creatures that were created specifically in the MotB module. So, I just need to import those creatures, or change the 2da to always use standard creatures, and the other encounters should start working.

On a related subject, I found what "SuppressRestMessages" does in the campaign settings. It's for if you're using this MotB-style resting system. Turning the option on eliminates the "canceled rest" message that results from bypassing the original resting system with this alternative system.

I ended up making some significant changes to the starting town. I reshaped the dock area, swapped, moved, or removed certain buildings, and changed most of the open torches to enclosed lamps. The latter might improve performance, with the fewer flame effects. The terrain shaping and texturing was pretty much the same as in the Dragon Age: Origins toolset, so the learning curve was a gentle slope. I did notice that this toolset tends to crash when I'm erasing grass. Usually on the second or third click.

That's probably more detail than I need to be putting in the starting town. I'll have the opportunity to craft an area from scratch on the lighthouse island, and the underwater areas will need that kind of attention, too.

So, about the types of fights, as you asked about, Dorateen -- as mentioned above, there will be a chance of wandering monster encounters when resting in unsafe areas. (Resting will be allowed everywhere except on the city streets. Inns will offer resting for a fee.) I've designed this module around several specific boss fights (four of them for the main plot, and at least one optional one). While approaching the bosses, there will be small groups of lesser challenge to a good group, though I'd like to find a point where an appropriately-leveled and balanced group should have a chance of dying to one of those groups, and be in serious danger if more than one group attacks them at once, at the higher difficulty modes. In my playtesting of the fights, I'll be playing on the two highest difficulty modes.

The bosses all have their own little backstories and personalities, and favoured methods of attack. I'm trying to make their fights more interesting than standard fights.

Another design decision is to allow attacking non-hostile creatures. In Baldur's Gate, you could do this. The default action on a non-hostile creature is to talk to it, but in BG you could always click the "attack" command and fight them anyway. This allows you to, for instance, use your rogue effectively to open the fight with a stealth backstab. At some point, this option started disappearing from games, and turning every enemy encounter into an ambush, regardless of whether you've scouted ahead and know full well what's waiting for you. Instead of being able to make a preemptive attack, you're forced to have a chat with the villain as your entire party is teleported into the middle of the room with their stealth broken and protections stripped. Wow, thanks!

So now, with this campaign switch set, I can remedy that kind of situation. There will be no time that you're forced to speak to a known enemy. The default action is still to talk, but just like in Baldur's Gate, you can manually select the option to attack. If you miss out on some dialogue, so be it. If there's some information that you need to learn from the enemy, I will make it so that you can find that information some other way, after having killed it. Backstab away! I don't think I have any characters that are holding quest items, but if I do, I'll make sure you can solve the quest by picking the pocket of that NPC, and completing the quest without fighting, and award a proportional amount of XP for the sneaky method, because the use of character skills should be rewarded as much as fighting.

Some players may use this ability to attack the neutral citizens in town, and/or important questgivers. Again, so be it! They will have that freedom, and the consequence of that choice will be that they probably won't be able to finish the game, and the whole town will be after them.

The rest of my time was spent laying out NPCs in the testing area and starting to give them placeholder conversations to get the main quest running. I notice a very heavy emphasis on humans in the stock NPC collection. I'll import the elf, half-elf, and halfling heads I was working on earlier and make some NPCs with those. Not much to show in terms of screenshots yet, aside from things like this. I'll post more screenshots in later reports, when they have something interesting to show.

Posted Image



    Cacoethes scribendi

  • News writer
  • 2,373 posts
I started today by merging the systems I had tested separately into this main module, such as the quest scripts, some exploding barrels that will be used for the lighthouse lamp fuel, and can be used tactically, and the final boss, whose appearance was the subject of an earlier query of mine. Converting them all to blueprints for export took a while.

I also imported some wearable custom content. This was my first big experience with importing custom content, barrels notwithstanding, so I did it very slowly and carefully. One of them involved an armorappearance.2da, and another involved a nwn2_icons.2da, so I created the hak I'll be using for this module, and put them in there with nwn2packer. I think I'm slowly coming to understand the use of 2da files.

I couldn't figure out why some of the new items weren't showing up in the toolset at first. I thought there might be some 2da files in the override again, but the reason this time is that I forgot to actually attach the hak to the module. Ah, learning curves.

Some of the custom armour items I want to also use as placeable decorations. I searched and found Mokah's tutorial on how to do that. I'll do that later, after I've roughed out more of the plot. Once again, I allowed myself to get caught on fine details after I got that custom content imported. But at least it made for a good screenshot! This savvy barker and his chipper assistant tour guide will facilitate your diving adventure! (This stand will be next to the docks, with more placeable decorations.)

Posted Image

I set up the journal entries for the main quest. There are a lot of them! They're bare bones for now, without much in the way of flavour, and I must remember to give each entry a summary of the entries that came before it, to aid the player's memory. I assigned the main quest conversation to the mayor, and assigned journal conditionals and actions to let him run through the actions. Now I need to place temporary NPCs, triggers, and acquisition and other tag-based event scripts in Questland to allow me to test the main quest's functioning.

I discovered the ability to save and load sets of variables and scripts. That'll be very useful! I've saved a set of default scripts using the x2_def_* scripts for NPCs/creatures, since I think those are the most recent and flexible ones with hooks to the older versions and variable switches. I also saved a set of variables to use for my quest indicators.

I found the boss death scripts that come with the game, and added lines to update the journal, so I can test the main quest progression. I took Kamal's advice to set their placed instance hit points to 1 for easier testing. I find myself doing a lot of re-placing of instances when I change something in the blueprints, though. I can't find any way of refreshing an instance from the blueprints without just placing a new copy and deleting the old one. Maybe I should just do everything on the instance and convert it to a blueprint later, for moving to the actual locations where they'll be encountered.

Next was lots of troubleshooting. The balcony I placed for the gnome to stand on didn't support his weight, and he sank right through it. Almost none of the conversations fired, including the triggered ones that worked in the previous testing area. A hat that showed up fine in the toolset was absent in the game, while another appeared fine. My quest indicators didn't show up.

I got the normal conversations working, and the mayor's main quest conditions worked fine, as did the boss death scripts, in updating the journal and generating the special treasures. I found that some of the scripts weren't firing because the ones I imported from the previous testing area only imported the uncompiled scripts, so I recompiled them. The quest indicators started working again, and the triggered conversation script fired, but the ambient conversation itself was missing. The hats are still missing. The balcony now has collision, but the gnome was scooted off of it. I tried height-locking the gnome, but in-game he was still sunk into the thing. I tried building up some terrain under the balcony, but the ground mesh's triangles were too large to fit underneath it without showing.

I looked around for walkmesh advice and found the ramp and block placeables by Zarathustra, but when I imported them, 2da and all, the placeables appeared in the form of a carved wooden bear pillar from MotB and one of the Okku barrow stone things with red runes on it from MotB, and the two others didn't appear at all. Sounds like a 2da issue, but I don't know what could be causing it. Finally, I found the walkmesh helper objects from the vanilla toolset, and figured out how to get them working, and now the gnome stands on the balcony.

Some of the problems I had to troubleshoot here were caused by settings changing in the placed instances, or perhaps it was me making the changes to the blueprints, and not placing new instances. This doesn't bode well for when I need to move these objects into their proper places after testing. The setting "never show helmet" was active, though I was sure I had disabled it, and that was the cause of one of the missing hats. The non-firing conversation was due to the characters having been reset to be unable to speak to non player owned characters. I re-enabled that.

Posted Image

That left just one trouble to shoot, and this basic framework is complete. It was the hat on the main boss. Eventually, I found what the problem was. The creature scaling got reset to 1, 1, 1, which caused the hat to sink into her torso. I notice that this scale resetting happens often when I'm doing completely unrelated things in the creature's properties.

Nevertheless, now the rough stuff is all functioning. This session is done.



    Cacoethes scribendi

  • News writer
  • 2,373 posts
I play in a pen-and-paper group once a week, and this was that day, so I primarily worked on NPC dialogue today. I established the rough framework of one of the side quests that I know will be in this module, and had time to add plenty of conditional dialogue branches for the party chat with special options for various high skill or attribute checks, as well as deity checks, and of course a variety of options without conditionals. This was my first experience with large dialogue trees, and I hope that it, and the others that I write in the same way, will be rewarding for roleplay.

I also fleshed out the conversations for the city watch members who patrol the town and stand at guard posts. They now offer directions to all the major points of interest around town, and I also added a conditional hook in their dialogue, for quest reasons (I'll keep that vague so as not to give too much away in these reports).

I will say that the two temples in this town are to Sune and Valkur (I never liked Umberlee), and my intent is to design them appropriately to their teachings.

I also wrote some rough conversations for a couple of the town vendors, and fleshed out the undersea tour promoter's dialogue.

Since the next order of business for the main quest is to spawn some things in once certain conditions have been met, I looked at my options for a spawn system. I found several such systems, and of those I really wanted to use the Legends spawn system, due to its nice interface, which would make it a faster job. However, the interface gives me unhandled exception errors whenever I try to edit a waypoint, so I can't use it.

I've heard good things about Neshke Narovken's Extendable Spawn System (NESS), so I'll try using that instead. I'll read the instructional PDF on that later.

In the meantime, I placed a group of NPCs that advance part of the main quest if you rescue them (rescuing them will be optional, since there's no logical reason why it should be required to do that to advance the overall plot, though of course you'll miss out on some rewards if you don't do it). I chose one of them to be the speaker for the group and wrote his conversation to handle that advancement.

Edited by Tchos, 10 June 2012 - 12:30 AM.



    Cacoethes scribendi

  • News writer
  • 2,373 posts
I opened up Storm of Zehir to see how to add the party registry book to my inns and taverns, and enjoyed reading through the conversation that fires the script. It opened my eyes to yet more ways that conditionals can be used not just to create interesting conversation trees and to reflect quest stages, but also to allow a single placeable to have different flavour text based on where it's located! I love that!

In fact, in examining one of the SoZ taverns, I think I see how they got around the problem I was having yesterday, about the mixups of making changes to blueprints without placing new instances, or changing placed instances and then losing them by placing a new copy from the blueprint. In the tavern, they don't place NPCs at all, but just place spawn waypoints, and have the On Client Enter script spawn the NPCs there. A very good idea. I think I'll adopt that practice, and only make my edits to the blueprints.

I rewrote the spawning script I found in that tavern to read NPC resrefs from local variables applied to the area, so I can use a generic On Client Enter script for any of my areas, and I made a generic spawning waypoint blueprint with the necessary tag prefix attached and a comment to remind myself how to use it if I forget. It seems to work fine. I just wish I could change the appearance of the waypoints themselves to look like mannequins or something so I could easily distinguish an NPC spawning waypoint from a walk waypoint or something. As far as I can tell, I can only change the colour of the flag on the waypoint.

I really like this toolset, aside from its quirks and occasional crashes. It's very configurable, with its dockable and pinnable panels, appearing and disappearing as needed. Very flexible with screen space. It looks like you can make any kind of story or quest you could think of in this toolset!

Twisty plot problem
While setting up the conditions and situations that advance the plotline in a section that can be approached in different ways, I learned how tricky it can be to arrange journal entries and conversation nodes to account for those different combinations of events. This came about because I didn't want to use the invulnerable, unpickable locked door trick to keep the quest progression simple. Instead, the doors are all pickable and bashable, though the keys do exist. No XP granted for bashing, but I do grant it for picking the locks. They are difficult locks, but a skilled rogue should be able to get them open anyway.

I also found by accident that if you check conditions and set quest stages through scripting for a journal entry where you accidentally put the tag of the quest in the comment field instead of the tag field, it still updates the quest and sets the stages correctly in the game, but doesn't show the quest in the player's journal or give any journal update notification. I suppose that could be used to have a pseudo-quest that keeps track of things for the builder's benefit, but is hidden to the player.

Even though I carefully structured the conditions and dialogue, and in my first two tests it all worked properly when I ran through it in two possible ways, I found a third possibility that my dialogue didn't account for. I added another journal entry between two of them to account for the other possibility, and also added a couple of additional nodes to the conversation so that the questgiver didn't repeat himself if you talk to him again before fulfilling requirements. I also had to add conditions to two scripts to account for it. That fixed a few, but I still found ways of triggering unplanned conversations. I can see why people go with the railroading route.

Maybe I should step back and start again, and go about this with variables separate from the journal. That might help.

I stripped down the conversation to its barest structure and rebuilt it from near scratch, and while I was doing that I noticed the "Quest" column which I had forgotten about. I was setting the journal entries with the Action "ga_journal" in the first version. Now I'm setting them with the much more convenient "Quest" field in the behavior node. Both work, but the latter requires less clicking, and shows the quest stages and descriptions so I don't need to check the journal itself for reference.

I incorporated a minimal installation of Barry the Hatchet's Module Testing Toolkit so I could reset the module for quick testing of variations, but I apparently need to configure some kind of permissions in his script to allow myself to use it, so I'll handle that later.

The conversation is running better, now, but I'm running into a problem where a line is ignoring my "Show once per game" setting for the one that starts the quest, and continuing to show it instead of falling through to the line below, which acknowledges that the player is already on the quest. It might be because I have additional conditions set for showing that line, and those conditions are acting as an OR for the "show once" instead of an AND. I'll try removing the conditions, since they're at the bottom of the conversation tree anyway, so there shouldn't be any other situation in which those lines are shown.

So, more work still to be done on this tricky bit.

Posted Image
(Screenshot shows unpolished dialogue)



    Cacoethes scribendi

  • News writer
  • 2,373 posts
I got the Module Testing Toolkit working, but the main reason I had installed it was so that I could reset the module to retry conversations with different conditions. Since this is a campaign, the MTT reloaded the module, but the journal was still advanced to the end of the quest, so unless there's a command somewhere that works the same for a campaign as StartNewModule does for a module (I couldn't find one), I guess I have to do it the usual way.

I'm beginning to think that "Show once per module" might also not be working because this is a campaign, and the conversation is not a campaign conversation. I'll convert it to a campaign conversation and see if that makes it start working.

After playing around with the conversation some more, I found that the gc_talkto condition check works in the exact opposite way as I would have expected. While its counterpart ga_talkto marks an NPC showing that it has been talked to, gc_talkto checks to see if the NPC has not been talked to. I should make a copy of that latter script and call it "gc_talkedto" or something, and make it work in the expected way.

This conversation is a big tangled mess, and some of it is due to trying to get it to work even under improbable conditions, such as the player unlocking the cell door but then not talking to the people inside before going off and doing something else. It works fine under two conditions that I think would be most typical, and even the ones that are less than satisfactory still work, in that they advance the plot. The reason I'm spending this much time on this conversation, though, is because it's one of the major events in the plot.

"Show once per module" still didn't work, even when I converted the conversation to a campaign conversation. It still shows that same line over and over. Does it just not work for campaigns, or is there some other reason? I switched it to "Show once per creature" instead, and that worked as "per module" should have. So now, since I couldn't find any documentation on how SoZ party members are treated by this particular condition, whether they're each considered a separate creature, or if they're all considered "the player", I had to move to the stage of implementing the SoZ party creation before moving forward with the conversation.

I tried opening the first SoZ module to see how they handled the party creation. I found in the campaign manager plugin that G_X2 was the starting module for that campaign, but the module wouldn't load in the toolset. I opened it in NWN2packer and exported it into a folder, and opened it as a folder, and it worked that time. Evidently I had misremembered how the campaign began. I thought I recalled that it had automatically started the party creation interface when it began, but on examining the module here, I see that they had just steered the player toward using the registry book through a warning conversation that played on opening the door. I'll just go with that method.

It took longer than expected to get the book working because I used the wrong script. I put nw_startconv into the On Used field instead of x0_startconv. The first one starts a conversation with OBJECT_SELF, while the second starts it with the user. So, I got the party gen working, and added a second member to my party, and found that "Show once per creature" behaves as I had hoped. The conversation now seems to work properly in all conceivable combinations (though I'm sure it could use playtesting to be sure), and a major part of the plot is now complete.

There were a couple of oddities with the party, though. First, my added party member was unable to attack an enemy. For her, the enemy defaulted to "talk", and when I clicked on it, it switched focus to my main character, who was able to attack it.

There was a bit of hilarity during this, though, because while I was ignoring the enemy and swapping the focus character back and forth, it ran close to that long line of NPCs that were in the first screenshot in this thread, and they all started attacking it! Strange, since I had set them all to the Commoner faction, and there were no Defenders in there. But that wasn't the funny part. When I got back to the cage to test out the rest of the conversation, I saw that one of the prisoners was bashing the locked door to try to get out to the big fight, and since I had specifically made the door destructible, he eventually succeeded. Needless to say, it's not my intention that the prisoners are able to break themselves out of their cage with their bare hands. This is not Minsc! I'll have to make sure all the prisoners are docile so that doesn't happen in the game. Of course, the other prisoner thanked me for getting the door open.

Another oddity was that when I added a party member, then removed her using the party gen screen again, and then I talked to an NPC, her portrait still showed up in the party chat window, though it wasn't selectable. I tested this with several more combinations, and a second time I ended up with two copies of my main character's portrait when I removed my second party member, while a third time, when I tested it with three party members, I just had the non-clickable residual portrait of the missing member like the first time. I'm going to call this a low-priority problem, since most players probably aren't going to reduce the number in their party during gameplay, except temporarily if they want to add any of the companions they find in town.

After these tests, I went back to the Campaign Editor and changed a few of the settings. After that, my added party members were able to attack enemies. I'm not sure which one fixed it, but my settings look like this now:

Posted Image

Now I'm looking over Kamal's PoE prefabs. I believe once I have the NPCs' AI and conversations set up and functioning in the plot, and make sure they're blueprinted, I can go ahead and place their spawn points into the actual intended areas. The next major task is to set up one of the important encounters, which involves triggers and scripting.

Page loaded in: 0.716 seconds