Auto-Pause Combat

This week I have been looking over some of the new things that come with "Storm of Zehir". This includes the new scripting command SetPause, which allowed me to add a simple bit of script that supports auto-pausing combat every 6 seconds - on a module heartbeat. As some may know, my group of players and I have a preference towards turn-based combat - probably because we stem from the "very" old school of PnP playing. And while auto-pausing every 6 seconds is not exactly turn-based combat in the sense we like to play, it is a welcomed compromise that allows the game to accurately pause every 6 seconds somewhere between a combat round. Rest assured though, this feature is fully toggable for those who want to keep their combats free from any such facility.

Sorry Feat - Cooldown

I have finally managed to get the "cooldown" feature to work with feats, many thanks to Kaedrin who helped me to pin down where my problem was. As it turned out, the issue was nothing to do with the actual information I was trying to add to the feat.2da file, but the fact that it was not always saving between my tests - and so settings I was making were simply not there! I required this feature for a "Althéa Feat" that allowed a player to say "Sorry" to a neutral that they may have attacked. It is part of the "Life System" where a player will be permitted to attack any creature they can see. However, on the off-chance an attack was made in error, then I needed a way to allow a player to prevent the neutral remaining hostile with them. This is where the "Sorry" feat comes into play. By clicking this option, any neutrals (now made hostile) will return to being non-hostile. However, I decided to give this feature a 30 second cooldown usage so that players could not exploit the situation by hitting every few seconds between saying sorry.

Party Conversations

My friend and I finished MotB the other day, with the cutscene conversation bug unfortunately, which was introduced with the SoZ add-on. So, we had to play the last section again with me pausing between lines so we could actually read the ending.

With that over, we started to play SoZ, and were pleasantly surprised at the way the new party conversations worked in a multi-player game. The ability to allow both players a chance to speak or ignore and do their own thing was a great joy. It did remind us more of good old traditional PnP style play where anybody in the group of players could join in.

So, coupled with my own party conversation code, this will be a welcome addition to the campaign and future adventures I intend to build.

Storm of Zehir

My first impressions of this game are very good. I already enjoy the facilities introduced as mentioned above, and I look forward to delving more into the "recipe collecting" system, which was an area I felt needed improving. To me, SoZ has been a big step towards actual gameplay with respects to the spirit of the game. While I can see this will compromise some companion interaction (that the players build themselves), I thoroughly welcome all the great advantages that the game brings instead.

So, even though I am not even off the first beach (we only just started the game), I give SoZ a high score already simply because of the feel it has given me and the added benefits I can already see. In fact, I would even go as far to say that SoZ is probably one of the biggest improvements to the NWN franchise since its release. Good stuff!

Actually, there is some bad stuff that I forgot to mention: There appears to be a bug with the AI since the update and I have heard there are one or two other issues with the latest add-on that require fixing. I have encountered the AI bug myself, in that NPCs do not appear to arm themselves properly and they like to run away from a target before they use ranged weapons. This is most annoying, but something I can fix if Obsidian do not fix it first - which I obviously hope will be the case.

Another Small Step Forward ...

At the end of last year I gave an outline of some of the ideas I had in mind for the Life Essence in this post. At the time I mentioned the following:

• 1st Level (All PCs) - Soul Protection. (The PC is protected against untimely death.)
• 2nd Level (Craft Skill PCs) - Maintain Equipment. (The PC with the crafting skills can also maintain their equipment if they are damaged.)
• 2nd Level (Wizard PCs) - Arcaene Lore. (PC can create "Arcaene Lore Scrolls" enabling powers similar to earlier Colour Magik.)
• 3rd Level (All PCs) - Empower Attributes. (PC can recover lost or increase attributes. Scaling cost per point.)
• 4th Level (All PCs) - Enhance Life. (PC can trade Life Essence for real experiences - Increase XP.)

Well, since then I have managed to code nearly all these aspects ... and a few more. In particular, Soul Protection was coded very early on when I coded the Death System. Readers who have been following the blog closely may already have an idea how this will work. If not, you will know all about it by the time it comes to play.

The Maintain Equipment is almost complete. There is one small change here to the original plan, however, and that is to allow PC's of any level maintain their equipment, as long as they have the appropriate crafting skill. More details of this will be given in the game and on the website, which I hope will be ready to upload at some point in the future, even if it has to coincide with the release of the module itself.

The Arcaene Lore code was established quite early on, but continues to be a work in progress. It has grown as an idea since its first conception and will, hopefully, continue to develop further as I get the time. One off-shoot of this system was the announcement at the time that most material components for spells would no longer be required. Well, I can now add that I have decided that the new era will not require any spell components for the standard spells. I will still have the player meet certain requirements for special case spells, but this will be made clear as part of an adventure.

Over the last few days I have been coding the system that handles the ability to Empower Attributes. I won't go into details about how this is done, as the astute player will learn more about this when they get the chance to play. What I can say, however, is the coding was a bit trickier than I first thought it was going to be. (Isn't it always!) My first idea of using XML code to do the job did not work out, and in the end I was left with two alternatives: The first involved allowing the player to increase attributes in a similar fashion to the equivalent Epic Feats that do a similar thing, or, alternatively, have attributes altered that would still be affected by what the PC had in the way of other attribute altering magik. The main difference is that the former would allow attributes to stack with magik items, where the latter would not.

In the end, I went with the latter, as it fitted in better with the idea I had in mind, and left the Epic Feats untouched as another goal for the player at later levels. As my idea was to allow the player a way to have more control over their PC's very soul, then having a system that was still affected in some way by other items made for a more interesting/tactical gaming experience. For example, when this method is discovered, the player will not only be able to raise some attributes, but also have the ability to lower some. If the PC who is doing the altering of their attributes finds and uses a magik item that duplicates the same attribute benefit, then they may chose to drop the said attribute and increase another instead (because the two benefits on the same attribute do not stack). There are costs involved of course, and there are other reasons why the player may chose to play this part of the game differently. After all, this particular method of increasing an attribute will not be tied to an object that could theoretically be lost at some time.

In the coming weeks, I hope to write the code for the last idea in the list: Enhance Life. I already know how to do this, and is fairly straight forward. And once this part has been done, the core ideas for the Life Essence (which should carry between each module) will be finished, leaving me more time to continue with the story itself.

Ranges

One other aspect I have been looking at today was to do with the range of vision, spells and weapons. I have always preferred to give both the player and monsters a bigger range with respect to all these aspects, as it can allow for some interesting long range combats, as well as help prevent the player's PC creeping forward to cast a spell or use a weapon, just because they are "not in range".

Having altered some of the figures in the ranges.2da, I have managed to improve the distance of vision, and I believe spells work better (I have only tested a couple), but I do not see a great improvement in ranged weapons, like bows.

I even tried altering some of the figures in the baseitems.2da, where it makes reference to minimum and maximum ranges of weapons and ammo, but even this did not appear to make any difference. So, if anybody has any other ideas, then please let me know. :)

Updated Games Menu

I just thought I would give an update on some of the additions I have made to the player's in-game options menu. There are two, and they both appear on the front menu option panel: Adding Map Pins and Renaming A Weapon.

Adding Map Pins

Adding Map Pins is as simple as pressing the Add Map Pin button. This will then add a map pin directly in-game, which also updates on the map (in the traditional manner) after the player exits and enters the area again. This can also be updated manually by the player selecting the Update Map Pins button, which becomes available when there are map pins to update. The third button, Edit Map Pin, selects the nearest pin to the player and allows them to edit the comment from another GUI that pops up. Again, this only becomes selectable when there is a map pin to edit. I have also taken care to ensure players can only edit their own map pins.

There is a small chance that Obsidian may add some code in a later patch that will replace the need for this menu option. However, as I have now finished it, I will leave it in place just in case.



Renaming A Weapon

The second new GUI option is the ability for a player to rename a weapon that they carry in their right hand, up to a maximum of 24 characters. I needed this function for the players as some weapons in the new era can deteriorate (Dead Weapons), meaning the player may wish to reflect this in the name of the weapon.

I have currently disabled the ability to write in numbers as part of the name, as this is not in keeping with the spirit of the campaign. In other words, there is no ability to write Longsword +4. Although, I suppose a player could call it Longsword Four if they really wanted to. However, I am trying to help players avoid naming a weapon to something that may mislead them in the future if their weapon deteriorates.

E.g. A weapon that is +4 enhanced and has 2d4 fire damage may have traditionally been called a Flametongue +4. However, if this weapon deteriorates with use, then it may lose the +4 enhancement or the flaming damage, and so it would be wiser to call it something along the lines of Flametongue only ... unless it loses its flaming damage as well over time.

UPDATE: Due to popular demand, I have allowed numbers to be used in the naming process. Just don't forget that the name may not reflect the ability of the weapon if it changes and you fail to notice. ;)

Map Pins Have A Future?

In the last post you may recall that I managed to work a system that enabled a player to use my own version of "map pins" within NWN2. As I built this system, I was in contact with Sunjammer via the Bioware forums (website added to the website links), who gave this response when I asked him about the possibility of using existing NWN code for map pins in NWN2:

"It isn't possible at this point. In NWN1 when you clicked on the map the client sent the information to the server so the map pin was displayed immediately. In NWN2 all we are doing is creating the underlying variables and there is no message being sent to the server that tells it to create the corresponding map pin ... until the client enters the new area. However I have it on good authority that a) the code still exists in NWN2 and b) it would be very easy to create a UI callback to send the appropriate message to the server. Consequently I'm submitting a feature request to Rob & Rich.Hopefully it can be included in v1.22 (v1.20 is SoZ, v1.21 is the "day 1" patch for SoZ, v1.22 will be the first normal patch after SoZ)."

So, basically, if Obsidian are able to make this UI callback available to us, then I guess the idea of including map pins for area maps will become available to us once again. And if they do, then it would be a great honour to say that it all started here, and thanks to Sunjammer, may become a salvaged system to replace the method I currently have in place. Here's hoping ...