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

[Tchos]

Rolo Kipp, master of the arcane workings of Gmax, explained to me how to handle the smoothing. These are the steps:

 

1. Select the faces. Buttons for "smoothing groups" will appear on the rollout.

2. Put the faces on the top surface of the book into one smoothing group and the faces on the sides in a separate smoothing group.

 

This fixed the problem. I also increased the max angle for smoothing, though I don't know if that has any effect in NWN2, since when I reimported it, the angle was back to the default, and the separate smoothing groups had reverted to a single one. Something to keep in mind for future model work. I'll have to keep a Gmax format version of the mesh to work from instead of always working from an imported MDB if it loses information like that.

[Tchos]

Something strange is happening with my script to change the appearance of the party members to swimming. Depending on what race I have as the main character, and/or what the race composition of my party is, one of several things can happen. One is that everyone turns into the main character's race, and gains the swimming appearance, or they all turn into the main character's race and do not gain the swimming appearance, or they retain their own races, and gain the swimming appearance, etc.

 

I have a switch function, and I used numbers for the appearance types instead of their constants, and I ordered them by race instead of in numerical order. I don't know enough about switches to know if it goes through the whole switch to check for a case number, or if it stops if it reaches one higher than what it was looking for. If the latter, then that could be the problem. I'm reordering them in numerical order now to check.

 

No, that didn't work either. And it's not just the main character's race. In this last test, the main character was a human, and everyone turned into elves.

 

I use a while loop to cycle through the whole party, checking their appearance type with a switch function, and changing the party member to the appropriate swimming version via a command just after the switch, after which it should go to the next party member and go through the process again.

 

Okay, explaining just now what's supposed to be going on in this script has helped me read through it and find what was going wrong. It was that the command to check the appearance was outside of the while loop, so it only checked once.

 

The tests after making that fix shows that it's working properly for a racially-diverse party, although strangely, the script fails completely if the party is larger than 5, which is the max party size that I set in the campaign settings. Despite the limit, you can currently have a party larger than 5 if you create a 5-member party through the party editor, and also recruit additional party members from the NPC companions around town. I was going to just allow the player to do that, and potentially have a 10-member party, but if it breaks the script, then I'll have to actually enforce that limit and run checks on party size when you recruit NPCs.

 

SoZ handled this by forcing you to dismiss all recruited party members if you go to edit the party, and then recruit back the NPC companions that you still have room for. I'll go with that system.

 

I copied the cohort scripts from the SoZ campaign folder, and the way they're set up, they use the specific names, resrefs, and tags of the SoZ cohort characters. I hoped the scripts could have been a little more generic, but I can work with them the way they are for this instance by replacing the names and tags with my own companions. Next time, though, I think the scripts could stand an overhaul. I'd create functions that don't need to see which specific companions are in the party -- only how many there are and whether they're cohorts or not.

 

I'm interested to see in this code that they seemed to have been planning to have the same kind of party dynamics as in the Baldur's Gate games, or maybe Planescape: Torment, in which certain conditions could trigger companions getting angry and leaving the party. It's marked as temporary, and I don't think that functionality was ever used in the game.

[Tchos]

I've been wrestling with more persistent problems.

 

First, a new potion I've added to the apothecary was only 1g, despite the base cost showing as 730 and an additional cost set to 400. I found the problem, though. It was set to plot. Removing the plot flag corrected the price. Not sure why having a plot flag in a store item would cause that item to be sold for only 1g, but something useful to know in case I want to have a plot-necessary item sold in a store, and want it to cost more money. I'd have to set it to add the plot flag on acquire, probably, and have the store sell it without the plot flag.

 

Second, the mayor's quest indicator was doubled. Couldn't figure out why, since the others weren't. It must have had an extra one added by something, but I couldn't find what it was. I made an extra safety removal at the outset, and that fixed the problem.

 

The mayor sits in a chair, and I wanted him to make some gestures while talking. Doing it through the animation or node section of the dialogue tree caused him to stand up and sit down repeatedly while doing these gestures. I created some new ga_ scripts to handle gestures with PlayCustomAnimation() which kept him in his seat. However, after leaving the area and returning, I found him standing up again.

 

I added an On Enter script to the area to re-fire the script that seated him in the first place. However, that caused him to sit in his chair backward. I changed the script to just refire the sitting idle animation instead, and that put him back in his seat.

 

Since I had to restructure the system of companion recruiting and removing to enforce the limit, I brought in some adapted SoZ scripts. However, I'm having a lot of trouble getting them to work properly, where Kaldor Silverwand's adaptation of Dick Lorraine's companion recruiting and removing worked as it should have, though disregarding the limit. I'll continue to work on that.

 

Okay, after extensive investigation, deliberation, and testing, I went back to the old way for part of it, while keeping the SoZ scripts for other parts. As far as I can tell, it now works as intended. You can have a maximum of 5 party members, regardless of whether they're player-created (imported PCs from your local vault) or recruited NPCs (cohorts).

 

To recruit an NPC in the first place, you have to talk to them. After they agree to join your party, they will appear in the party roster, whether or not you have room for them. However, if you already have 5 party members, they will not join your party until you remove one. This is true whether you attempt to add the NPC through conversation or through the party roster editor.

 

Editing the player-created party members requires going to a tavern or inn, and using the guest registry book. You can add and remove both kind of companions with the guest book. Player-created characters which were imported from your local vault, which you remove from the party in this way will appear to disappear from the game world until you re-add them from your local vault with the same process, but in my tests, the game does remember the state of those characters, even after saving and reloading, so your inventory and everything else should be safe when you re-add them. There's only one thing to remember, and that's if you have multiple copies of the same character in your vault (e.g. Brigid Chandler, Brigid Chandler (1), Brigid Chandler (2),etc.) as you might have if you export the same character at different levels, you have to remember to re-add the same copy of the character that you imported the first time, or else it's counted as a different character.

 

Once an NPC has agreed to join you the first time, you can add that NPC anytime you have enough room, either by talking to them and asking them to come along, or through the tavern guest book, or though the party roster menu option in the player menu.

 

http://4.bp.blogspot.com/-cxPbamlWu34/UOk1HQrDlvI/AAAAAAAAE04/jUoSF62wiFk/s320/bcocc+cohort+join.jpg

 

You can remove them from the party in the same ways (talking, tavern guest book, or menu selection). If you choose either of the first two options, those cohorts will remain standing where you leave them in the taverns until you re-add them, but if you use the party roster menu option in the player menu, then the cohort will disappear from the game world until you re-add her/him. And of course, the inventory and level is saved, as normal.

 

So far so good, and several items crossed off the list.

[Tchos]

I had a long list of things that needed to be done to the docks area -- that large area that seems to grow ever more difficult to open. I took a rest from working on the last of the exteriors, restarted the computer and loaded the bare minimum system resources, and tried opening the area with all effects and visible items turned off. A fresh reboot with nothing else loaded and everything turned off has been the only thing that's worked in the past, but this time I was greeted by a very disheartening crash.

 

However, I thought this time to take the precaution of reducing the far plane distance in the options, as well as reducing the display resolution, and upon trying again, this successfully opened the area. Finally!

 

So I went about taking care of the items in my long list (mostly adding spawn points, fixing some misaligned items, adding missing walkmesh cutters, and improving navigability), and despite several more crashes, I implemented nearly all of the things that I needed in that area, and left it open to go out for a few hours. I returned to find it had crashed again during my absence, for unknown reasons, but of course I had saved before leaving, so it's all right.

 

What remains to be done there, as far as I can tell, are just some descriptions on placeables (in this module, all doors are named to indicate their destination, and shop signs include descriptions of the shop that you can read before entering them, to know what you're getting into), and placement of sign posts. Everything else can be handled through scripts without opening the area again, since I have the waypoints and item tags documented externally. There are cosmetic things that I would like to do (proper signs with graphics), but I'll do without here.

[Tchos]

There's a signpost up ahead. Your next stop...?

 

http://4.bp.blogspot.com/-5uUaAPdwnBQ/UPTWCbEcqhI/AAAAAAAAE1Q/mQWDSXNGBKE/s320/bcocc+signpost.jpg

 

Right, so as I mentioned before, I needed signposts for the town, to help the player get around town, and I didn't find anything like this in the available resources. Asking directions or consulting the map for map note pins is all well and good, but how about actual street signs? This is what you might call my first foray into real model manipulation for this game. I've done this sort of thing before with the simple tools available for Oblivion (Nifskope), but here, I had to use Gmax. The modeling itself didn't take too long, but learning to navigate Gmax's methods of creating a UV map for this mesh (with more shapes than I've mapped before) took an entire day. The other day was spent actually texturing it.

 

I put some intentionally illegible writing on the signs so that they can be used generically. I didn't want yet more blank signs like what I've settled on for the shop signs.

 

There is a very nice pack of merchant signs that I plan to check out when I have the time, but it won't be in this module.

 

Anyway, as is no doubt evident from the screenshot, I have the sign arrows separate from the post itself, so that you can name each arrow appropriately, and also to add or subtract arrows as needed. I made a prefab group out of it, for easy placement around town.

 

I'd say it's a slight improvement over the directional signs they used in the OC.

 

http://3.bp.blogspot.com/-dUL8OAuVvVU/UPTWBM6ubsI/AAAAAAAAE1I/wyTNnhC9i6E/s320/OC+street+sign.jpg

[Tchos]

I can't even count or estimate how many hours have been wasted fighting with the walkmeshes in this toolset. Today, it was hours upon hours.

 

It was another run of work on the docks, fixing some things that became broken in the previous session and adding more signposts, and adding the last of the sign descriptions. I found that I had enough room in the walkable area of town to reduce the grid size by 1 unit on each side, which I hoped would make it easier to open the thing (out of memory errors are one of the errors given when it doesn't just crash without explanation).

 

This unfortunately required rebaking the walkmesh. One result of this was that the tile around the Merchants' League HQ became completely unwalkable again, which I traced to the fact that I swapped a torch environmental object with a lamp, which I had neglected to make into an environmental object. Too many placeables on the tile was the cause of it, even though there were nearly none at all. Converting to environmental fixed it.

 

The other result was that the walkable docks regained gaps between them where they should attach. Dealing with these docks has caused many lost hours in the past as well, and I've tried so many variations on the setup, I just can't understand what the problem is.

 

I've tried it with the docks as placeables using their own walkmeshes, at different elevations or identical ones, touching, overlapping, or barely separated, with walkable land painted underneath or none, and at different distances from the terrain they border.

 

 

More time was spent with the docks as environmental objects, with walkmesh helpers taking their places. Again, countless variations, including those above, and with mesh blockers in the form of invisible boxes, or with cutters, or without either. There are 3 dock objects. One is the base, and the other two jut out from that one, perpendicularly. I had managed to get all of these perfectly connected with no gaps in the walkmesh after many attempts, but after many hours of atttempts following my edits today, I couldn't recapture that elusive state of affairs.

[Tchos]

Things are worse than I thought. I was in my minimal bootup working on the area some more, and was going to try to bake it again, but was doing some other edits before then, and on one of the saves, I was given a very bad error. Out of memory on a save. So it couldn't save it, despite multiple tries, but of course it overwrote the area files with its failure anyway. I ended up with a 0-byte docks.git file. Just wiped out like that.

 

Imagine losing this large and very important area entirely! That's the first time something like that has happened to me.

 

I backed up the area just before I started work on it yesterday, so all I lost was yesterday's work. This is a reminder that we should back up our work often.

[Tchos]

I re-fixed all the things in the docks area that were lost in the corruption, and finished adding the signposts. There are still a couple of extra things to fix that I found in my last runthrough, but very minor ones.

 

One thing I found is that doors have inherent problems. I have a couple of doors that have notes posted on them, and you can read the notes. But I found that even if a door is flagged as static, it interferes with the selection of placeables in front of it. I had thought at first that it was a problem with the placeables, but it was definitely the doors.

 

Considering that doors marked as static cannot be affected or changed by script, I can't see any reason for this behaviour. They should not react at all.

 

So, my conclusion is that transition doors (doors that transition the player to a different area, rather than doors that open within a single area) should best not be doors at all, but placeables. Considering that I already use a script to replace the standard door transition system (which I made to eliminate the superfluous animated opening of the door into a black void), a door placeable works just as well.

 

It works better, in fact, since placeable doors can be marked unusable instead of static, allowing me to "leave the door open" (so to speak) for activating those doors in a later patch, whereas actual doors cannot be marked unusable. I prefer not to leave-an-active but locked door in any spot where the player is not actually meant to go, even if I may add it later, because when I play a game and see a locked door, that says to me that there's something behind it, and I'm missing something if I can't open it. If there's not really anything behind it, then I could be unnecessarily wasting a lot of time looking for a way to open it, and that's something I won't do to my players if I can help it. Therefore, in my work, all active doors, locked or not, must be openable in some way.

 

The only downside is that placeable doors use the default "use" cursor that looks like an asterisk when you hover over them, instead of the "door" cursor. But with properly named doors like "Entrance to Town Hall", the cursor isn't as necessary to indicate to the player what's going to happen if they click it.

 

At any rate, my next module will use nothing but placeable doors for doors leading to transitions, and reserve actual doors for those that swing open between rooms in a single area. It allows things like this:

 

http://www.youtube.com/watch?v=rJ3gp8foY1E

 

In other news, I've been learning more about good lighting in this engine. In this last runthrough I had point light shadows turned on. I had been playing with them turned off for quite a long time, because I've seen them create some extremely harsh shadows in some places in the OC and in mods I've played.

 

I noticed they were back on only after seeing that the contrast seemed stronger and the colours richer. I think it actually looked better this way in most cases. I believe those harsh shadows I had encountered before were due to those lights being set to cast shadows of a high intensity (where I think "1" = completely black, and something like 0.2 or 0.3 is more appropriate for a normal room where light bounces off the walls and ceilings). Some prefabs include lights, and those lights no doubt have a range of shadow intensity settings, or in other cases are set not to cast shadows at all. I think it was that, combined with perhaps too many lights in one spot, that created the harsh shadows in the OC that turned me off of point light shadows, which is too bad, because it can really make an area look much better as long as the lights are set carefully. I think on my near-final playthrough, I'll see how all the areas look with point light shadows turned on, and adjust if necessary.

[Tchos]

I imported Crystal Violet's placeable OC doors, though the misnomer is that they're not placeables, but environmental objects. The included blueprints were also apparently made pre-MotB, so the entries in the placeables.2da were all where MotB placeables need to be. I moved them all (there are 59) to the free spot where I've been putting all my own work, and reassigned all the proper appearances to the blueprints, and converted them to non-static usable placeables, with some standard values for doors (such as for traps) and being sure to include hit points so that they can actually be used and manipulated by scripts. Also added my own transition script to these new blueprints.

 

Also integrated Crystal's later door fixes to correct the normal maps of certain doors (I agree with her assessment of how the doors were intended to look) and the doors with windows on one side but not the others. To this I also included Heed's tint maps for standard interior doors 1-5, making certain of those doors useful, where before they were too ugly for me to consider using. This is all mainly convenience work for working with doors in the future.

 

I created another generic trigger script and blueprint, based off of my earlier quest-related generic trigger script, but this one instead functions as a rough replacement for the encounter system, which despite being rough suits my particular needs better. Later I can expand it to be more flexible, but at the moment it serves as either a spawn trigger (for up to 9 unique creatures, in any quantity), or a SpeakString trigger, or both, depending on which variables you fill in. In this case, I used it to spawn some creatures, and alert the player that they heard something.

 

I did some more touchups on the tavern and inn and the NPCs within, and elsewhere I also ended up moving a questgiver, since it didn't make much sense for him to be manning a reception counter, considering his rank. This required putting him in a chair, and by now I understood the system well enough to control his seated actions. I made a script, but I should also make an included function to perform this same task, which allows you to specify a character's animation, and also slow down that character's heartbeat to match a multiple of the length of the animation, to prevent obvious skips in the animation when the heartbeat fires again. By changing the variables on the NPC through scripts or conversation actions, you can change the NPC's custom animation and heartbeat at any time, which is useful for a character that moves around between quests or events, and may be engaged in different tasks.

 

Moving the questgiver does mean I need to create another small conversation for the new NPC manning the counter, though.

 

I did some more work on the starting area and the book that introduces the player to the module and the game world. While in the starting area, which is a room at the inn, the player has the opportunity to rest and prepare spells before setting out, preferably by clicking on a bed. I say preferably, because although you can also do it with the normal resting command, the message box refers to setting up "camp", which you wouldn't do in an inn. But it was either that or getting an inappropriate "resting is not allowed here" message. I know there's a way to customise that message box, but I haven't looked into it.

 

There are no storage containers in the starting rooms, since the player will never go back to it, but storage is available at both the inn and the tavern.

[Tchos]

I filled out some more of the conversations that had been on the backburner, and completed a couple of other cosmetic items on the to-do list. One of these conversations was the minimalistic clerk at the merchants' league HQ, and another was a node for the tavern, because the tavern doesn't offer rooms for rent -- only the inn does.

 

I use a single conversation for all innkeepers and bartenders (which amounts to only two in this release), with individualised content using both custom tokens and conditional nodes.

 

Anyone who opens up this campaign to examine my work will find quite a patchwork of different methods for accomplishing tasks being used all over the place. Sometimes this is because I start out with one method, and find later that I need to expand to a different method to accomplish other things, or that it's easier to do something a different way, or I simply discover a better method that I didn't know originally. In this case, I used custom tokens because it would have been more efficient that way if I had the 4 inns and taverns I had originally planned instead of the two. Since there are only two, it's more straightforward to just use conditional nodes.

 

I feel very silly about something, when I'm not sagging under the weight of so much unnecessarily lost time. Kamal, if you were trying to tell me this, and I was failing to understand, thank you for trying, at least. The troublesome docks walkmesh could have been dealt with in such a straightforward manner. I was going about it the wrong way entirely by trying to connect several dock-shaped walkmesh helpers to each other. Raising the ground underneath the docks is likewise unnecessary.

 

The way to do it is to paint the entire terrain under the docks as unwalkable, then place one single large walkmesh helper at the elevation of the docks which covers all of the dock's protrusions, and then cut out the non-dock parts with walkmesh cutters.