448 réponses à ce sujet

[Tchos]

LOL...I forgot about that maxim. 

[Eguintir Eligard]

Bloodlines.

[Lance Botelle]

#14 Life Can Be Draining

http://worldofalthea...e-draining.html

Progress continues ... and once again, I find myself back into coding some AI related scripts. This time, however, these scripts deal with creature encounters and how they respond in certain opening situations rather than the actual combat responses thereafter. That is all rather deliberately vague, I know, but suffice to say, it all works as it should do now.

However, to be blunt, I have not done as much as I would have liked since I last blogged, simply because of real-life issues (including worse health again). I had hoped to have finished the dungeon I am currently working on by now, but this has simply not happened. Apart from the above AI scripting, however, I did manage to alter some existing spell code to rework the way life-draining creatures work with my Life Essence system. (Something I touched upon in my last post.)

I'll keep doing what I can as I can ... and obviously keep you all updated. In the meantime, here is another screenshot ...

[Lance Botelle]

#15 Light, Sound, Conversation & Monsters!

http://worldofalthea...n-monsters.html

ATMOSPHERE

I have set myself a procedure to follow now as I go through my module area by area. First I go through an area checking the lighting and sounds, to make sure the ambience feels right and that the player can "see" relatively well, subject to their own visual capabilities or need of a light source. I make sure area sounds are balanced, and offer audible clues if need be.

At this stage, I also check to make sure the area and mini maps are set up and working correctly with respect to whether they are available in the first place, and to ensure they are not giving more information than they should be by revealing hidden rooms before they have been discovered.

If all looks good, I double check that I can reach every object I need to, and make sure transitions work as they should, at the time they should. Once I am satisfied that this all seems fine, I move onto stage two: conversations.



Evening fireflies and a cloudy sky

INTERACTION

Checking conversations is much more difficult to do due to them relying on variables being set. However, I check what I am able, and even alter some variables or leave access to certain links just to check other responses if need be. This testing stage is more to do with ensuring I have at least finished all the conversations in an area with respect to what I want the creatures or objects to be able to "say" in the first place. For instance, I have a number of placeholder conversations that have only partial comments and need finishing off. My goal now, is to ensure I finish all conversations in an area as I make my way through them on this final testing stage.



Store Interaction: This book looks interesting!

SURVIVAL

Once the conversations are completed for the area, I move onto the combat monsters that will be encountered in the area. This part requires a little more attention, as I want to make sure I have allowed a fair and reasonable environment in which the player can meet the challenge. This is all about game balancing, and player choices prior to encountering any monsters can make the difference in whether the player perceives the game as a fair challenge or not. That's not to say the design should make every encounter a breeze or nightmare simply based on statistics, but also recognise environmental factors that may alter factors for either the PC or monster in the first place. E.g. A place where a PC could never rest would eventually wear them down to the point where even a fight with a giant rat may be difficult.

This monster stage, is also the time I ensure the bestiary has been updated for the creature if required. The bestiary can give slightly more information about a creature, which sometimes gives extra clues about how to fight it. At the very least, it will help categorise the creature for the player.



Example: Animal selected from creature category.

[Lance Botelle]

#16 Installing User Mods & Custom Content: READ THIS FIRST!

http://worldofalthea...om-content.html

If you are new to installing users' modules or their custom content, then hopefully reading this will save you a lot of potential frustration and/or having to send emails back and forth with the authors asking them for help about getting something to work. Even if installing user material is not new to you, then maybe this article will help you be aware of any potential pitfalls you have not yet experienced.

NOTE: This article is intended for the player end-user of created material, as opposed to material created for builders to use within their own projects. It is assumed builders will already know most of what I am about to cover, although I would draw their attention to the ADVANCED section, which may help to avoid issues with accidental duplications of files.

Even if you think you understand the BASICS, please at least consider reading the ADVANCED section of this article, as that covers where most issues arise after an installation.

THE BASICS

BACKGROUND

The Neverwinter Nights PC game franchise comes with a toolset that allows users to build their own custom content for others to download, and then to install to use or play. User content can vary from relatively simple User Interface (UI) alterations (e.g. Making the "Game Paused" wording say something different when the game is paused), to building an entire module, with or without additional material. When installing user content, however, care is needed to make sure the files and folders that make up that content are placed into the correct NWN folders on your own computer.

NWN FOLDERS

From here on in, whenever I use NWN, I will be referring to the NWN2 game only, but some aspects of what I say can also be applied to the original NWN1. The main differences are that NWN2 has more places where user content files and folders can be placed.

The following also assumes a default installation on a computer running Windows 7. Please bear that in mind if you have changed the installation path or run a different operating system.

When you install NWN, the main game default installation path is:-

C:\Program Files (x86)\Atari\Neverwinter Nights 2

When installing USER CONTENT, there is NEVER any reason to alter any of the files or folders from those in the above folder. At the very most, only ever make copies of files from this installation directory, and work with the copies inside the folder mentioned next.

However, at the time of installation, a user folder for NWN is also set up here:-

C:\Users\UserName\Documents\Neverwinter Nights 2

When you are asked to install user content, it will be into the folders that are found in this folder. The most important folders to note are as follows (as found in alphabetical order):-

Campaigns
hak
modules
movies
music
override
tlk
ui

This article covers files (and/or folders) that are asked to be placed inside these folders. If you asked to place any other files into other folders in this path, then please follow the builder's instructions.

USER CONTENT PLACEMENT

When you download user content or a user module, then the builder should explain to you in a Readme.txt or similar instructions where to place the files you have downloaded. Some user content may only use one of these folders, whereas downloads (such as modules) are likely to use many or possibly most of these folders.

Hopefully, even if the builder does not give clear instructions where their files should be placed, the way they may have packed the files may help indicate where they should be placed. This is the way each folder should be used:-

Campaigns - Contains the "campaign" folder. i.e. The "global" files for one or more modules.
hak - Contains hak files: Material used to alter in-game visuals. (Primary 2da files are placed here too.)
modules - Contains a module file, or a module folder. (Differs according to builder tastes.)
movies - Contains user created movie files in bik format.
music - Contains user created music files in bmu format.
override - Contains different files or folders to help change the way a game plays.
tlk - Contains user created tlk file. Alters what text the player receives in a game. Can be original reworded or new text.
ui - Contains user altered or created primary UI XML files. (Can include supporting images & sounds.)

NB: This is a general structure. However, it is possible (and even likely in some instances) that many files (even XML or 2da format) can and will be placed in the Campaign folder. However, some primary XML and 2da files have to be treated differently and are placed elsewhere, as explained above.

 

THE ADVANCED

FAULT FINDING

If you have followed the builder's instructions on where to place their files and you have done so correctly, then all should work fine when you start the game. However, through no-one's deliberate fault, problems can occur and are often down to duplicated files. (NB: There is an exception to this: See Some Safety Steps To Follow #4 below.)

While any file duplication can be a problem, there are two specific types of file that are more prone to duplication and are the highest likely to cause problems with your game. The two file types I refer to are the 2da and XML file formats. These two are more likely to suffer from duplication due to the high amount of alteration and testing they go through at build time, and also due to the location they are finally placed when the content is released.

For example, a single XML file may have five clear different versions (but all with the same name), spread across four different folders, with each one making a difference, subject to where it is placed. I will give an example of this in a moment, but first need to explain something about "priority" with respect to files being read for the game.

FILE PRIORITY

As far as I am aware, there are up to four folders that can affect when file priority is involved. Here follows the priority of folders from which the NWN reads and finally executes a file:

HIGHEST PRIORITY
================
HAK (PRIORITY) (*)
HAK (NORMAL) (*)
OVERRIDE
CAMPAIGN
CUSTOM UI (+)
=================
LOWEST PRIORITY

(*) NB: A game can come with more than one hak file to place inside the hak directory. Hak files have their own order of priority, subject to how they are installed by the builder, and so if a file appears duplicated in multiple haks, then only the highest priority hak version will count.

(+) This folder does, however, take the priority when you launch NWN for the first time, which is why it is used by builders to set up fonts, typefaces, opening images, etc for their module. However, once the game is loaded, it becomes the lowest priority as other folders (with files) take precedence.

So, what I am saying is, if you had, for example, an official campaign XML file with the same name (but each slightly altered in some way) in each of these directories, then the one in the HAK (PRIORITY) would be the only one to fire. If the XML file was not in the HAK (PRIORITY), then it would look at the one of next priority in the list, HAK (NORMAL), and if it were not there, it would look inside the OVERRIDE folder and so on, until it had gone through all the potential user folders.

If, after going through all the USER folders it does not find anything, then (if an official version exists) it will default to the official game version, which is installed with the game. (i.e. The ones you should NEVER alter.)

NB: I have NOT included the "module" folder, as not all files placed inside this folder have an impact. E.g. An XML file placed here will not do anything (at least in my tests). However, for the purposes of including it in the list, and if it does have any impact anywhere, then it would come below CUSTOM UI and just before the official game files. E.g. Official scripts can be altered and saved to the module by the builder, which then take priority here.

The 2da files suffer from the same kind of duplication error, as they can often be found in many places. So, if you have an old version of a 2da sitting in your override folder, which is taking priority of the one that you downloaded and comes in a campaign folder, then errors will occur.

SOME FILE INFORMATION

XML FILES: These are the files that alter the way the UI works within the game. UI are the "user interface" such as character sheets, inventories, maps, etc. It also includes some things you may not expect, like the fonts used and individual components, like scrollbars. If a font is missing, or a UI does not look correct, then the fault is likely to be with an XML file.

2DA FILES: These are two-dimensional arrays (2DA). Basically, think of a table with columns and rows, where code calls for references held within this table according to a row or column reference. If you are seeing odd behaviour with respect to some wording or missing text, especially related to character information, then it is likely to be caused by a missing or corrupt (old version) of a 2da file.

OTHER FILE TYPES: The user folders will contain a great number of other files, from new models, tilesets, terrains, images, sounds, scripts, etc, etc. And, in principle, they can all suffer from the same "duplication priority error". E.g. An old tga image file sitting in a hak, when a game is trying to use the one that comes within its campaign folder, will cause problems. However, due to the way that many of these other file types are put together at build time, they are less likely to encounter this issue. HOWEVER, if you do experience unexpected results, then do a search for the file in question among all the sub-directories of the NWN user directory.

SOME SAFETY STEPS TO FOLLOW

Here is my advice to follow when installing custom content:-

1) KEEP THE OVERRIDE EMPTY: Most user content, if properly structured, should NEVER need to have anything placed within the "override" folder. The "override" folder is a quick and messy way to fix things, or, more normally, to test things. If you have downloaded custom content that uses the override, then chances are, if you have other custom content you use, then it is likely to break that. NB: Note, however, a duplicate file in an override (even if newer) will NOT take priority over the same named file in a HAK.

2) CARE WITH CUSTOM UI FOLDER: You should take careful note of files that are added to the CUSTOM UI folder. There is nothing wrong with files being placed here, but you should be aware that files placed in this directory have the potential to alter EVERY module you play while these files are present. However, sometimes, these files NEED to be present to ensure the custom content or module work as intended, and so one must not be afraid of following the instructions to place them there. Just be advised that it is best to work with only one custom folder at a time within the CUSTOM UI. Most builders will provide a folder with their CUSTOM UI content, so it is simply a case of temporarily removing this folder to the desktop (for instance) if you intend to play a different module.

3) CAMPAIGN & MODULE FOLDERS: Files and folders can be placed into these folders without any real concern, unless, of course, somebody happened to use exactly the same name for a file or folder as you are about to copy. They can sit here indefinitely without causing any concern to any other module at all. The only caveat to be aware of, is if the builder updates their content, you may also need to update files in these folders too. (However, see THE PRIORITY HAK next.)

4) THE HAK FOLDER: Treat similar to the Campaign & Module folder. i.e. Files placed in this folder are not likely to interfere with any other module, unless they have the same name as another hak used for another module. NB: This may be important to know if you have downloaded two modules, and each uses the same hak, but the builder may have slightly altered the original hak and not renamed it. This is unlikely to happen, but may be worth noting if the builder forgot themselves.

THE PRIORITY HAK: More importantly, however, is this folder is the one that can contain what I call the "Patch Hak", which is basically a dedicated priority hak for a campaign or module. If your module comes with such a hak, then be sure to keep this hak up to date, as it contains all the latest fixes for the game in question, and any files it contains get priority over any older ones. In this case, this is where the file priority system works in our favour, as it uses (in theory) the most up to date version of the file in question, over and above any other version found lower in the list of folder priorities. This is the one time when file duplication is expected for players who are "patching" their game. Using this method of file updating means a player does not have to restart a module, but can carry on from a saved game.

5) THE TLK FOLDER: This folder is where you place the builder's own tlk file. Once again, files placed in this folder are not likely to interfere with any other module, unless they have the same name as another tlk file used for another module. NB: The official campaign tlk file is called Dialog.tlk and is found in the installation directory. This file should NEVER be altered, and any user tlk files should use a different name and be placed in the tlk user folder.

NB: I am unaware of anybody editing the official Dialog.tlk file directly, but there would have to be good reasons for doing so. In theory, a good builder will rather supply an end user with edited 2da files and a new tlk file so that all original files are left unaltered.

6) MOVIES & MUSIC FOLDERS: Treat similar to the Campaign & Module folder. i.e. Files placed in this folder are not likely to interfere with any other module, unless they have the same name as another file used for another module.

FINAL COMMENTS

There is a great temptation for players to try to install all their favourite modifications for the many user modules available. This comes inherent with installation dangers! Often, a module contains hundreds, if not thousands of edited files. Unless you know where to look for potential file duplications, then any modification left within an override or added as another hak has huge potential to cause the game to fail. Even if you do find the clashing (duplicated files), trying to merge them without knowing the full implications, will also likely cause a broken game.

So, while the temptation may be great, I would recommend being prepared to make sure your environment is "clean" before you attempt any potential installation, and use only the files that come with the module.

Lastly, if you have done everything your end correctly, then at least you have a good understanding of what to explain to the builder with respect to the problem you are experiencing.

[Lance Botelle]

A FORUM *BONUS* POST: MULTI-PLAYER MODULES
 
Have you ever wondered why there are so few multi-player (MP) modules for NWN out there?
.... Or, at least, if you have found one, did you play it as a MP module with friends with any success?
 
NB: This is *not* about Persistent World (PW) coding, but about coding a module where more than one player can play at a time in co-op mode, with or without a DM at the helm. (PW are much more difficult I imagine.)
 
Here is the reason I ask .... Because there are *many* differences to cater for between a SP and a MP module. Here are just some examples:-
 
1) MP coding may have to cater for a DM being present or not (if started by the DM client).
2) If the DM is absent, a MP game started without the DM Client, has to consider who hosts the game from week to week.
3a) What happens if one player cannot make a session one week and their PC was carrying a critical item needed by the players?
3b) ... Or, what happens if a player has to leave the session early one week and their PC carries a critical plot item?
4) What happens when one player tries to enter a new area while the other players are in another part?
5) What happens when one player starts a critical plot conversation while the other players are in another part?
6) What happens with respect to journal entries from player to player (as they are acquired) .... Do they all get them correctly?
7) When accepting companions into the party (or creating PCs at the Party Generation Screen), who controls them? Who commands do they obey?
8) Extra XML coding for MP environment.
 
So, whether you are a player or a builder, you now know some of the hurdles that MP modules have to overcome. Put simply, there are *many* more aspects of the story and plot items that the builder has to consider when coding for a MP module.
 
... So who thought it was simply a case of sticking "SP or MP Module" in the module description?
 
Hats off to PW coders!
 
Cheers,
Lance

[Eguintir Eligard]

multi player campaigns should not have to cater for players interchangably dropping out between saved games. If a group wants to play that way they can keep their game groups together or wait till everyones ready

[andysks]

It's basically like p&p. My party would not start playing if one was stuck in traffic. I think a builder should not care about all these. It's not our fault if a group can't get together. We can't think and prevent everything .

[Lance Botelle]

It's basically like p&p. My party would not start playing if one was stuck in traffic. I think a builder should not care about all these. It's not our fault if a group can't get together. We can't think and prevent everything .

multi player campaigns should not have to cater for players interchangably dropping out between saved games. If a group wants to play that way they can keep their game groups together or wait till everyones ready

Hi All,

I hear you ... I just considered that some players may want to continue a game if somebody could not make it for some reason .... Of course, one always hopes that everybody can, but I have known times when having this flexibility is useful. e.g. From my pen and paper days, a player could temporarily take over another players PC if needed. That's the reasoning here.

Cheers,
Lance.

[Arkalezth]

I've played a few modules on multiplayer, even though they weren't designed with it in mind, and they worked just fine. I suppose that some things, like conversations, often feel better suited to a single player (sometimes one has to do the talking while the other(s) just stand there and watch), but I recall no technical issues to speak of.

 

We never even thought of having a DM because, well, the module is already taking care of that with scripted quests and encounters.

 

I've always played with one or few people, so if someone can't make it, we'll likely leave it for another day. Quest items can always be spawned or something, and I don't think it's the author's responsibility to babysit players in the unlikely case such a specific thing happens.

 

Area transitions port the whole party, so there's no way for players to be in different areas, unless they hit a bug, in which case they'd better reload.

 

Anyone can control companions. We normally distribute them so each player controls an equal number of them and things don't turn into a mess.

 

At any rate, I guess you can tweak a few things here and there to make a module more multiplayer-friendly, but I don't think anything is really needed to make it work.

[Lance Botelle]

I've played a few modules on multiplayer, even though they weren't designed with it in mind, and they worked just fine. I suppose that some things, like conversations, often feel better suited to a single player (sometimes one has to do the talking while the other(s) just stand there and watch), but I recall no technical issues to speak of.

Hi Arkalezth,

Thanks for posting this info. I would like to check a few things about it with you, as that may help with my own module. I just answer with comments in some places, but have specific questions in others.
 

We never even thought of having a DM because, well, the module is already taking care of that with scripted quests and encounters.

I believe that part of the pleasure some players seek is the "intelligence" they may experience with differing encounters. So, while I do endeavour to write scripts and add AI to help with some circumstances, I believe there is something to be said with having a DM in control of a game if gaming circumstances can allow it. i.e. A DM at the helm can add a very different element.
 

I've always played with one or few people, so if someone can't make it, we'll likely leave it for another day. Quest items can always be spawned or something, and I don't think it's the author's responsibility to babysit players in the unlikely case such a specific thing happens.

SPAWNING QUEST ITEMS: I believe this would *break* my module. (And, I would suspect it would likely break some other modules where certain variables work around quest items, or quest items may even store variables.) I.e. It's a good idea that quest items can be spawned, but unless you are aware of the consequences of such, then this may cause an issue with a module.
 

Area transitions port the whole party, so there's no way for players to be in different areas, unless they hit a bug, in which case they'd better reload.

Agree with you here. In fact, I came to the same conclusion that this was *essential* for the kind of MP environment I was working on. Persistent Worlds, on the other hand, are designed for players to wonder into different areas at different times (multiple parties setting).
 

Anyone can control companions. We normally distribute them so each player controls an equal number of them and things don't turn into a mess.

QUESTION: How much control do you actually have? I mean, when a companion joins the party, whose commands do they listen to? e.g. If you (as a player in a MP game) shouted "Follow Me", do you have specific companions react to your "follow" command, or do they only actually listen to the commands of the "party leader". In my experience, it has been the latter, and is why I had to take extra steps (coding) to make companions truly separately controlled by different players. I would be interested to hear more on this and have you explain more what you mean in your case.
 

At any rate, I guess you can tweak a few things here and there to make a module more multiplayer-friendly, but I don't think anything is really needed to make it work.

My friend and I tried to download a few NWN2 modules in the past to play as MP, but discovered different issues caused us problems, including journal entries, missing items and control issues (as above). Of course, we may have just hit a few poorly written modules, but our experience with them is what caused me to look more into the way I had to cater for a MP environment.

Cheers,
Lance.

[Arkalezth]

I believe that part of the pleasure some players seek is the "intelligence" they may experience with differing encounters. So, while I do endeavour to write scripts and add AI to help with some circumstances, I believe there is something to be said with having a DM in control of a game if gaming circumstances can allow it. i.e. A DM at the helm can add a very different element.

I understand that a DM can add or improve things, but I don't see them as crucial, or the difference they may make as big as in a PW. In any case, I can't say if the DM client works properly in modules. The author of the Icewind Dale conversion DMd a game once, but it was brief and I don't recall him changing anything from the normal module. I can only tell you that he managed to log as a DM.

SPAWNING QUEST ITEMS: I believe this would *break* my module.

Maybe you're right, I couldn't say, though I think I've done it in a module or two after running into a bug. Still, I can see it being an issue if the quest item guy stops playing altogether and the item can't be transferred or something, but I think the situation may be a bit too obscure for the module's author to be held responsible for it. IF a player happens to have a quest item, IF he happens to be unable to play and IF everyone else happens to play without him... I mean, if there's a workaround, great, but you can't babysit every possible circumstance.

QUESTION: How much control do you actually have? I mean, when a companion joins the party, whose commands do they listen to?

I believe voice commands are limited to the party leader, but I don't remember for sure. In my case, companions are in "attack nearest" mode 99% of the time, so it's not an issue for me, but I guess it may be for others. However, anyone can take control of any companion at any given time (with the -possible- exception of the leader and/or player-created characters; I don't remember either).

My friend and I tried to download a few NWN2 modules in the past to play as MP, but discovered different issues caused us problems, including journal entries, missing items and control issues (as above).

I don't recall having any of those problems, at least specifically in multiplayer. At most, some possible small convenience issues due to modules being generally aimed at single player, but nothing serious.

I hope that helps. Feel free to ask if you have any more questions, but I can't think of much else to add from my limited experience.

[Lance Botelle]

I hope that helps. Feel free to ask if you have any more questions, but I can't think of much else to add from my limited experience.

Hi Arkalezth,

Thanks, your feedback was helpful.

One thing I note that I hope will be part of a difference for the better is that each player will *definitely* be in control of their own companions, with the capability of handing over control to other players with the right setting. This means each player can "shout" their own commands such as "Defend Master" and the companions will defend the player that controls them and not just the party leader.

As for the DM client .... I have to experience that still, and so I cannot comment any further for now. It's taken me all this time to build the module ... let alone DM it. The worst case scenario, I will just join as another player and "spectate" or join in as a fellow adventurer.

Cheers,
Lance.

[Lance Botelle]

Alpha Testing #1

http://worldofalthea...ha-testing.html

I have finally reached what I would consider the alpha testing stage for my module. I know there are some that would say I should just jump straight to using beta testing, but due to the high amount of customization in both AI scripts and XML, this module needs this final stage of internal testing before I release it into the hands of beta testers. As it happens, it's a good job I did, as some of the latest changes I made did have quite a bad affect on the module. Here is just some of what I picked up in my recent testing:-

Companion and Henchmen AI

This was one of my biggest concerns in my initial testing, as I discovered both companions and their summoned creatures would fail to return combat after a first combat. This was a hard cookie to track down! In the end, it turned out to be due to a player AI toggle setting to do with my own AI master control between having PCs in AI Mode or Puppet Mode.

The problem turned out to be due to two issues: The first issue was because I had failed to NOT include henchmen (inc summons, familiars and animal companions) in the master AI toggle, which meant when the game switched automatically to turn-based combat, it turned the AI off on these creatures too, which it is not meant to do. The second issue was more difficult to track down, and turned out to be due to the main PC not using the conversation script attached to it until after the player had switched to at least one companion. Once I had addressed these two issues, the AI all worked again as it was meant to, with companions using AI or not (according to the player's AI toggle setting), and henchmen (etal) using AI as standard.

Indestructible Quest Items

When a PC returned a quest item to an NPC, the item is destroyed as normal. However, upon a reload, the quest item returns to the player. This problem was due to the database not being updated correctly due to the item being "destroyed" rather than "un-acquired", where the check is normally updated. In the end, I decided to have the database update as the player used the escape key to bring up the "Options" menu when saving or quitting the game. This turns out to be a better way of dealing with this code anyway, and it sits quite nicely alongside my "henchmen fix" code that uses the same XML. (The "henchmen fix" code removes henchmen prior to exiting the game, which normally makes the module crash on exit if not done.)
 

UPDATE: On UnAcquire does fire when an item is "destroyed", so this was easier to resolve than first thought. I did not need to know the specific item destroyed (which is not returned in such circumstances), but merely required to have a way of firing a function when an item was no longer in the hands of the PCs. This hook still allowed me to do this.

 

Conversations

As some may recall, I have made a list to double-check four things during this testing time, and conversations was one of them. In the testing, I discovered a few conversations that had illogical nodes due to where the PC was located according to the time of day. (A rare situation, but one that I have proven to be possible.) While this was not a drastic problem, it was the sort of thing I was keeping an eye open for and so it got fixed.

I also decided to add an option to allow a conversation to continue after a player chose to "shop" via an NPC. This was because I wanted the player to not miss out on any potential new nodes that may present themselves *after* having browsed the shop's goods. Works a treat!

I also noticed that if the area map was open when a cutscene conversation started, that sometimes, the map would still be visible over the cutscene conversation. I edited the cutscene.xml to ensure it closed the area map GUI as it started, which now does away with that potential issue.

Quest Completed!

I have a dedicated quest VFX and small tune that plays with some quests, which adds quite a nice sense of achievement. However, in my testing, I discovered that the method I was using to deploy the VFX (via a conversation) was not being reliably displayed, due to the way the conversation set the camera angle. Therefore, in the end, I opted to deliver this VFX outside of a conversation and just within the game itself. I had to alter the SEF slightly, but all now looks far better when presented.

Debug Feedback

And while the least of my problems, I discovered there were still one or two lines of debug code giving feedback, even though I was no longer testing the game in "Test Mode".

Additional New Code

The only new code I added was the implementation of Spell Resistance (SR) when wearing items that give SR. I decided to use the feat system to add a new feat (SR Via Item) whenever a PC wore an item that gave them a higher SR value than any natural benefits the may have had.

And Onwards ...

That's all I have found and fixed so far, but I will continue to go through the module at a reasonably swift pace, and in a fashion that I think may help to mimic the most common choices or path. (Beta testers will probably do better at finding the more unusual path for me.) That said, this first batch of alpha testing has had me restart about four or five times, mainly due to the AI bug, as that was difficult to track down. However, now I am underway again, and have the support once more, hopefully, I will make quicker progress and iron out any other final major issues prior to beta release.

I will report back further testing issues in the days that follow ....

[Tchos]

Indestructible Quest Items
I decided to have the database update as the player used the escape key to bring up the "Options" menu when saving or quitting the game.

 

This may complicate things, but it's entirely possible to save and quit the game without using the escape menu.  When I'm done playing for a session, I will often hit f12 to quicksave, and then hit alt-f4 to quit the game.

[kamal_]

As far as indestructible quest items go, I submit that as long as the quest item is not of significant size/weight, you don't have to actually give the pc an item, just say that you do.

 

Let's say the pc is tasked by a wizard with writing down what some runes in a dungeon say so the wizard can study them. The wizard provides some charcoal sticks and paper for the player to make a rubbing of the runes. Do you actually need to put charcoal sticks and paper into the players inventory? Not really, you can just have the player "You tuck the items into your pack for later use" when accepting this quest, the quest item takes negligible space and has a negligible weight. When the player reaches the runes, the rune interaction assumes the player has the charcoal and paper (because they've accepted the quest and been told they packed the charcoal and paper in their pack) and the quest journal updates that "you've taken a rubbing of the runes, which you put into your bag to bring back to the wizard". Thus, the quest items for this quest are indestructible because they don't actually exist in the game.

[Eguintir Eligard]

Yes. And also, I used F12 exclusively when I save.

[Lance Botelle]

As far as indestructible quest items go, I submit that as long as the quest item is not of significant size/weight, you don't have to actually give the pc an item, just say that you do.

Hi Kamal,

Yes, I have considered this method myself, and may use it still. (I cannot recall if I used it at all yet.) I.e. Have the journal update with items carried with respect to the quest in question.
 

This may complicate things, but it's entirely possible to save and quit the game without using the escape menu.  When I'm done playing for a session, I will often hit f12 to quicksave, and then hit alt-f4 to quit the game.

 
 

Yes. And also, I used F12 exclusively when I save.

Seriously guys!?

 

I mean I do understand using the quicksave as a means of saving while playing, but surely you do a "main save" of sorts when leaving a session. Isn't that just "good practise"? I mean say, for example, you are playing a couple of mods at any one time (or perhaps you don't do this), and you rely on just the quicksave, then you will lose the game position for one game at least.

 

Anyway, your comments do still raise the concern of a module being exited (purposely or due to a crash) and the data not being updated due to the last save only being a quicksave, so your points are still valid, even if for somewhat unusual reasons.

 

I did look into using the "saving xml" scripts, but they run scripts *after* saving the actual game, so that would not work. I'll try taking another look then, and seeing if I really do have to resolve to editing a new "destroy item" function (scripts) that replaces current ones .... or see if I can intercept and make a call some other way.

 

UPDATE: GOOD NEWS: *** PROBLEM SOLVED *** It seems the Unacquire hook *does* fire when an item is destroyed. The issue is that you cannot retrieve the item that was destroyed. Thankfully, I do not need to know the item itself, but simply needed to acknowledge an item was lost to fire the function that updates the database. Therefore, as the hook is still fired when an item is destroyed, I now check for an invalid item and use that to update the database. Yeh!

 

Cheers,

Lance.

[kamal_]

You cant program for every possible action a player can take. Nor should you for game programming, the time required to cover the case where the player hits alt-ctrl-z-5 while spinning around during a full moon and the game clock is at 9am exactly is wasted time, the likelihood of that case is exceedingly small. The time is better spent elsewhere.

[Lance Botelle]

You cant program for every possible action a player can take. Nor should you for game programming, the time required to cover the case where the player hits alt-ctrl-z-5 while spinning around during a full moon and the game clock is at 9am exactly is wasted time, the likelihood of that case is exceedingly small. The time is better spent elsewhere.

Ah! I knew somebody would want to do that! Back in a minute, I have some coding to do ...

Back with today's alpha testing results in a minute.

Lance.

[Lance Botelle]

Alpha Testing #2

 

And so with today's list of discovered issues ....

 

Journal Entries

 

So, today's big one was to do with companion journal entries not updating correctly. Now, believe me when I say I thought I had this one buttoned down many moons ago. In fact, a couple of today's issues come under that category ... i.e. I thought I had them resolved already. Anyway, this one raised its ugly head again in the following way: I have a journal entry that is supposed to update for all party members when certain creatures are killed. The function setting had the AllMembers set to TRUE, which should do the trick nicely. However, because I also have quite a complex "journal system", which updates other aspects of a journal entry (tokens) as well as the basic entry, I found that having the next parameter AllPlayers set to TRUE to be a problem. Now, under normal circumstances this may work as intended. However, I found that due to the way I call this function, that the companions entries would not update correctly when both these parameters were set to TRUE. In the end, setting the AllPlayers to FALSE resolved the issue. And I hope this will remain so for a MP game, as the idea is that all players will be in the same party anyway, which the AllMembers parameter should cover.

 

Crime Prevention Failure

 

The next issue was a relatively easy fix. In the last few months, I made a much more robust placeable interaction script, which determined when PCs were interacting with something that maybe they should not be. I noticed that one placeable I interacted with allowed me to do so without any issues. It was simply missing a line of code in the older script, which some of the earlier placeables rely on compared to the newer robust script. Once that line was added, everything worked as it should.

 

Altar Usage

 

A PC can use altars in this campaign to sacrifice items to gain benefits. However, the altars do not work until the player has determined their Life Role. There was no feedback to describe this when I interacted with one for the first time. Obviously I knew the reason why, but I added feedback for players who would not have known.

 

Conversation

 

I have triggers that activate conversations according to certain conditions. There is a main script that handles all the conditions, which has often needed updating over the years due to one thing or another (new additions). I thought I had this script well and truly nailed down, but I did get one minor conversation start up, which should not have done. So, I added another variable check, and that should have nailed that problem.

 

Another AI Scary Moment

 

I had a scary moment when a couple of my clerics (I like using this class to play) both summoned a creature at the same time to help with a combat, and found that both their creatures stayed put after summoning instead of entering the fray! I instantly thought I had missed a "Puppet Mode" setting somewhere, but also realised that if only one of them summoned the creature, all was fine. After a little more investigating, I realised that these two clerics has summoned to the exact same location at the exact same time, which meant the creatures were effectively "locked" together in the same spot. A quick test by bumping into them proved me right, and so I updated the summon spell code to a ) Give a random delay when casting and b ) Apply Umbumpable for a brief moment after summoning, to allow them to move from their locked summoned spot. So far, testing shows this all OK now.

 

Item Database Fix

 

Those of you following the last post will know that I also discovered that the OnUnaquire hook does fire when an item is destroyed, and so I re-established my database function with that hook to allow my database to update before anybody saves and exits the game ... no matter which way they go.

 

Just Some Info

 

All fixes aside, the module is looking quite smooth and the quests appear to be coming together well, with everything making logical sense, and the flow works well. I am very much looking forward to releasing to Beta Testing. So far, I have played around two hours and reached second level with a couple of companions. Only one combat to date, but it's early days yet. Things should start going more smoothly now with the basics, and just some odd bits to do now (hopefully).

[Tchos]

surely you do a "main save" of sorts when leaving a session. Isn't that just "good practise"? I mean say, for example, you are playing a couple of mods at any one time (or perhaps you don't do this), and you rely on just the quicksave, then you will lose the game position for one game at least.

 

It depends!  It sounds like you took care of whatever the problem was, but just to explain, in many sessions I use quicksave alone.  I only make normal saves when I reach important points in the plot that I may want to go back to, but I don't do it at the end of every play session.  But yes, I do play multiple modules at a time, and sometimes I'm too lazy to load up the last module I played and make a normal save in it, so I end up not using quicksave at all when I'm playing the new module, and rely exclusively on normal saves so I don't lose the last save from the other module.

[Lance Botelle]

It depends!  It sounds like you took care of whatever the problem was, but just to explain, in many sessions I use quicksave alone.  I only make normal saves when I reach important points in the plot that I may want to go back to, but I don't do it at the end of every play session.  But yes, I do play multiple modules at a time, and sometimes I'm too lazy to load up the last module I played and make a normal save in it, so I end up not using quicksave at all when I'm playing the new module, and rely exclusively on normal saves so I don't lose the last save from the other module.

Hi Tchos,

This I understand, and is very similar to the way I do my saves. And that is how I originally thought the fix I had in place would work .... which of course, it would not .... as mentioned above.

Thankfully, as you say, I did manage to make use of the OnUnaquired and all is well now ... And I am very grateful that people reported back with how they saved, as it made me pursue this problem to a much better fix.

Cheers,
Lance.

[Lance Botelle]

Alpha Testing #3

And so with today's list of discovered issues .... Once again listed in case people have similar issues that this helps them to recognise ... or simply to read for fun!

Placeables OnClick

 

I am still encountering some placeables that need the newer OnClick event that tidies up many of the issues I once had. It's only minor issues it fixes, like limiting containers, etc, but I like to make sure they all give correct feedback and so will continue to add/replace this script as I find them.

 

Exit/Enter Area

 

I discovered a couple of issues with respect to exiting an area (and entering another). One did not fire a conversation, and was due to me redefining oPC half way through a script, trying to keep variable usage to a minimum. A quick change sorted this. Another time involved companions' summoned creatures not following upon entering a new area. I have a function that is supposed to keep them following. I found I had to delay it slightly longer before applying to allow all the PCs (and PC staff) to allow them to enter the area properly by the looks of it.

 

Journal Update Variable

 

I found a journal update had changed at some time, which meant a conversation node looking for the old variable meant it failed to allow the conversation to take place until updated. (As an aside, I also noted I could not simply fix this and carry on playing/testing using the campaign folder changes method. This is because the conversation is a "module" specific one rather than a campaign one, so I will have to fix that using my Priority Hak method.)

 

Resting GUI Options

 

I only allow waiting or resting from the Rest GUI according to area conditions and whether the PCs have access to food (when resting). I noticed that if a PC had no food and tried resting in a REST only area, then the GUI would be completely empty, which looked odd. So now, I simply stop the GUI from opening with an appropriate message.

 

Auto Closing Doors

 

I have doors auto-close when there are no creatures any longer close to them. However, I noted that if you associate two doors with each other, then the door that the PC opens is opening another door further away at the same time (if on the same area), and so the distance also fire for the furthest door at the same time. When it did, it assumed there was nobody close by and closed, thereby closing the one the PC just opened. Suffice to say, I removed that script for such a door.

 

Unjamming Walkers

 

I have put in place some code that is supposed to help minimise NPCs from "jamming" in a piece of scenery and doing the "moonwalk". However, working a reliable "release code" that does not interfere with potential scripted waypoints is particularly tricky. That said, I removed the check that stopped the unjamming code to ignore scripted waypoint walkers, because I noticed these were prone to the same jams and I weighed up which was worst ... having jamming NPCs or having them miss the occasional scripted waypoint. Further testing will govern how I eventually leave this one.

 

Potential New Code

 

I am possibly looking at writing a new function that helps determine if a PC has a certain DAMAGE resistance/immunity on them to help with a particular situation. However, I am trying to be strict and keeping all such new stuff to a minimum at the moment, and will consider adding it later subject to time and priorities.

 

That's all for now. Hopefully, I will be able to add a little more next week.

[Tchos]

I found a journal update had changed at some time, which meant a conversation node looking for the old variable meant it failed to allow the conversation to take place until updated. (As an aside, I also noted I could not simply fix this and carry on playing/testing using the campaign folder changes method. This is because the conversation is a "module" specific one rather than a campaign one, so I will have to fix that using my Priority Hak method.)

 

Do you know that you can still use the campaign to override this?  If you have both a module-level and a campaign-level conversation, the one in the campaign folder will be used, so you don't actually need to use the hak method.  It will of course change the conversation to a campaign-level conversation, but as long as you don't have any other conversations that use the same name, there will be no conflict.