448 réponses à ce sujet

[Lance Botelle]

Alpha Testing #7

It's funny how testing goes at the moment. I think all will start picking up and running smoothly, and I come across a really "minor" annoyance that I want to sort, and progress takes a hit. The "theme" for this latest bout of alpha testing has to be entitled, "Tidying Old Code".

Anyway, latest alpha testing results ....

HARVESTING

As part of my revamped crafting system, I have tried to make sure the PCs have a reasonable access to most crafting ingredients. To help ensure this, some items are available via placeable items rather than appear as "drops" on creatures. This means I can use placeable hooks to help create said items on a PC if the player has their character click on said placeable. This is a very straightforward event and script .... but was obviously not the case for me when I first wrote it many years ago.
 
Don't ask! I had all manner of variable checks and opening inventories, etc, etc. What a mess! How it even worked is anybody's guess, but as you can imagine, I was NOT happy to leave the straining script in such a way, and so rewrote it to work much more intuitively, reliably and do away with superfluous inventory accesses. Now, if the PC (or somebody in the party) has the appropriate skill (alchemy), then they can harvest an item (possibly more with a higher skill level), each day until they deplete the source. Twice as effective with half the scripting!
 
CREATED PCS
 
At the beginning of the module, the player has an option to create a couple more PCs (rather than wait to find any potential companions, if that is their preference). No problem normally, except in the latest testing, I discovered the created PCs were not following the main PC. Thankfully, this was a very simple fix, as I had simply not uncommented the *new* function (the fix from the last few days mentioned above with respect to companion control) that finished adding the companion controlling protocols to the generated PCs. (I had commented it out when resolving an include conflict at the time, and simply had forgot to uncomment the function call again.) It was a slightly panicky moment though.
 
VFX/SEF ON OBJECTS
 
When applying a home brew function to remove a SEF from a placeable object, I found that the one I had used earlier to remove a SEF from a creature did not work on a this placeable object. At first, I thought the problem was simply down to the fact that the effect had been applied to different object types. However, on closer inspection, I noted I had included the ".sef" addendum to the file  name when applying a sef in the first instance (placeable), and had not done so in the second instance (creature). Surprisingly (to me at least), having this extra addendum when calling the file name made the difference as to how it was later removed! e.g. You can add the same effect in a function referring to the file name as either: a ) "effect" or b ) "effect.sef". Both file references will apply the same effect. However, if you apply the effect calling it "effect.sef", then it can only be removed by referring to it as "effect.sef". Trying to  simply remove "effect" in this case would not work! As I say, this surprised me.
 
RESTING FEEDBACK
 
An update or two back, I believe I mentioned that I wanted to clarify some feedback with respect to "resting". In my module, a player can bring up the REST GUI by pressing "R" where they can WAIT or REST, according to environmental factors. (Actually, there are some conditions that prevent it from appearing in the first place, which is what my last alpha test update addressed.) However, as I was testing, it occurred to me that some of the conditional checks that I made when using the "R" GUI needed to be tested for when using an "ACCOMMODATION" GUI at a tavern. Furthermore, the two methods of resting required better conditional checking due to one providing food to rest (accommodation) and the other requiring the player carried food in the first place (when using "R") and the choice required it. This, like the earlier mentioned "Harvesting" script was one of my earliest written, and as the resting routine was now potentially being called in more than one way, I decided to rewrite this script (and accompanying ones) too. I ripped out the "rest checking" conditions and placed them into a dedicated function, and called that function as required instead. I also tidied up feedback, and made the whole thing much more informative to the player. I even added my own "NOREST" conditions into the scripts, thereby removing the need to rely upon the area properties "No Rest Allowed" property tick box. (I never noticed the No Rest Allowed" message when using this property, and so I hope my own Notice Text version will be more informative.)

OTHER STUFF

Unfortunately, I did not make any actual progress in the story due to the last few discoveries, but hopefully, I will have a fresh start the next time I have a go.

More later, as I make progress....

A ) Approximate Alpha Testing completion of points check list: 9%

B ) Approximate potential additional coding needed (to date) of points check list: 0.3%

C ) Party currently 3 clerics, a wizard and a dog (henchman). All PCs are at level 3.

D ) Combats to date: 1 (No deaths, rebirths, respawns or raises.)

Point B ) has been weighted by a factor of 10 to help give a better representation of estimated additional work compared to entire module. The extra coding will not be done until after being released to BETA and only then if others notice the same things as I did.

[Tchos]

What a mess! How it even worked is anybody's guess, but as you can imagine, I was NOT happy to leave the straining script in such a way, and so rewrote it to work much more intuitively, reliably and do away with superfluous inventory accesses. Now, if the PC (or somebody in the party) has the appropriate skill (alchemy), then they can harvest an item (possibly more with a higher skill level), each day until they deplete the source.

 

Thank you for not having Witcher 1-style harvesting. 
 

[Arkalezth]

C ) Party currently 3 clerics, a wizard and a dog (henchman). All PCs are at level 3.

You may have answered this question somewhere already, but is there any reason for testing with a 3 cleric-party instead of, say, a more classic one (with a warrior and a rogue)? Just curious.

[Eguintir Eligard]

Lance I will update to a 100% version in my signature when he is uploaded. Might even be tonight but watch for it.

[Dann-J]

I have a similar harvesting system in the module I've been working on for about a millennium. I have various small models that have OnUsed scripts that cause the player to play one of the 'get' animations (get high, get table or get low, depending on the relative height between placeable and player), spawn a number of items in the player's inventory (based on Min and Max integers on the placeable, and an item ResRef), and destroy the placeable model (or make it unusable if a specific variable has been set on it).

 

Such resources appear randomly in overland encounter areas. They get destroyed (along with anything else) when the player leaves the area, but new ones appear during every encounter.

 

In some areas I have an OnClientEnter script that spawns a certain number of a comma-delimited list of resources in a certain radius around a waypoint. For instance, it might spawn between 10 and 20 plants (chosen randomly from a list of mushrooms, thistles, belladonna, etc) in valid random locations tested to be walkable for the player. A time integer gets set on the area whenever they spawn, and if 48 hours have elapsed since the last spawn, and there are less than a certain number of the last lot of resources remaining, then they 'regrow' as a new random assortment.

 

In some areas I position the usable placeables manually, so they can be collected only once. Some of them start 'hidden' - an ipoint HB script checks for nearby party members, checks their relevant skills (like search or survival), and the resource appears if the skill roll is successful (the usable placeable spawns at the ipoint location). I use that system for locating underground truffles, a luxury item that some NPCs or merchants will pay well for. The same 'hidden' system can be used on non-usable placeables that look like environmental eye candy, unless a party member 'finds' them and they become usable.

 

I've added some new distillable alchemy entries to one of the crafting 2DAs, so some raw gathered ingredients can be converted into more useful usable items by party members with the relevant Craft Alchemy skill.

[Lance Botelle]

Thank you for not having Witcher 1-style harvesting. 

Hi Tchos,

I have forgotten how it worked in the Witcher games. At least, I remember I did not do it because it seemed too involved. In my own module, if you invest points in alchemy, then any amount allows a minimum collection, and additional points allow the chance of greater collection. When it comes to crafting, I want to keep things as simple as possible for the player to implement, without taking away some of the interactive elements involved. Therefore, I have made acquiring crafting parts very straightforward, and tried to simplify usage of them too. So, as you say, hopefully, this will appeal to you more than the Witcher games.
 

You may have answered this question somewhere already, but is there any reason for testing with a 3 cleric-party instead of, say, a more classic one (with a warrior and a rogue)? Just curious.

In this case, it was just the way it turned out by me choosing to play a cleric as my main PC (and NOT adding any more PCs at the start in this case), and then seeing what transpired with companions (if and as I encountered them). That said, this is still an *unusual* situation to be in, as it meant I had to play it a certain way to get to this point. Other PC types will become available as companions the more I play ... or, I could even "hire" some extra help at the tavern if I so wished. So, at the moment, this is just due to circumstances of play more than anything else. 
 

Lance I will update to a 100% version in my signature when he is uploaded. Might even be tonight but watch for it.

OK, noted thanks! 
 

I have a similar harvesting system in the module I've been working on for about a millennium. I have various small models that have OnUsed scripts that cause the player to play one of the 'get' animations (get high, get table or get low, depending on the relative height between placeable and player), spawn a number of items in the player's inventory (based on Min and Max integers on the placeable, and an item ResRef), and destroy the placeable model (or make it unusable if a specific variable has been set on it).
 
Such resources appear randomly in overland encounter areas. They get destroyed (along with anything else) when the player leaves the area, but new ones appear during every encounter.
 
In some areas I have an OnClientEnter script that spawns a certain number of a comma-delimited list of resources in a certain radius around a waypoint. For instance, it might spawn between 10 and 20 plants (chosen randomly from a list of mushrooms, thistles, belladonna, etc) in valid random locations tested to be walkable for the player. A time integer gets set on the area whenever they spawn, and if 48 hours have elapsed since the last spawn, and there are less than a certain number of the last lot of resources remaining, then they 'regrow' as a new random assortment.
 
In some areas I position the usable placeables manually, so they can be collected only once. Some of them start 'hidden' - an ipoint HB script checks for nearby party members, checks their relevant skills (like search or survival), and the resource appears if the skill roll is successful (the usable placeable spawns at the ipoint location). I use that system for locating underground truffles, a luxury item that some NPCs or merchants will pay well for. The same 'hidden' system can be used on non-usable placeables that look like environmental eye candy, unless a party member 'finds' them and they become usable.
 
I've added some new distillable alchemy entries to one of the crafting 2DAs, so some raw gathered ingredients can be converted into more useful usable items by party members with the relevant Craft Alchemy skill.

Hi DannJ,

This does sound like quite a comprehensive system. I note you consider one or two things (like regrowth), which I considered myself, but decided not to incorporate at this stage ... mainly due to circumstances and game balancing. However, I like the way you think ...


Thanks all,
Lance.

[Tchos]

So, as you say, hopefully, this will appeal to you more than the Witcher games.

 

Oh, it does.  It's the way I do it (for ore), and the way I prefer it in other games and other modules that do it that way, like Andy's.

 

The way The Witcher did it, by contrast, was make you open the plant as a container and remove the contents.  Contents would eventually respawn.

[andysks]

I cannot take credit for that. It's Wyrin's from the vault. What's nice with it is that it even creates the potion automatically if you gather the herb needed. I am planning expanding it a bit, but it falls of priority at the moment. I believe kamal has expanded it already and I might take a look at that some time.

[kamal_]

I cannot take credit for that. It's Wyrin's from the vault. What's nice with it is that it even creates the potion automatically if you gather the herb needed. I am planning expanding it a bit, but it falls of priority at the moment. I believe kamal has expanded it already and I might take a look at that some time.

http://neverwinterva...proved-foraging

 

My expansion of wyrin's system. I used it for Crimmor.

[Lance Botelle]

Alpha Testing (Restart) #1

Latest testing reached the point where I decided to restart my alpha-testing ... and so I am now on Alpha-Testing #2. Basically, I had a number of fixes to creature AI, journal updates, feats and general maintenance that made me decide a restart was required to ensure I had sorted these first issues. It also gave me the opportunity to start with a different class PC to try a few other ways of approaching the module. (NOTE: I had probably done around 10% of the module.)

Script Handling & AI

The main changes I made this time around were to do with the scripts that are attached to companions and creatures, especially as dictated by the NWN2_ScriptSets.2da. In the early days of my coding, I relied more on existing scripts and OC protocols, using variable holders to fire my "custom" scripts associated with creature event hooks, like OnSpawn and OnHeartbeat. However, as my scripts have grown, these two "older" systems have become more of a confusion and hindrance than simply rewriting my own and directly associating them using the SetCreatureScriptsToSet function pointing to the NWN2_ScriptSets.2da. After the issues I experienced in Alpha-Testing #1, I decided this change was sorely needed to allow me to sort through both companion and creature scripts more easily. This change helped a lot when it came to working with henchmen and other associate types that shared scriptsets in common, or I had manually edited to try to workaround the differences between them. This separation has helped streamline the code and tidy many of the discrepancies.

Journal Entries On Creature Death

Another change that determined a restart for me was after I encountered a failure with a "trigger" event to do with a journal entry update after I killed all creatures spawned from an encounter. In this case, a single trigger for an encounter would be simple enough. However, I had a series of encounter triggers that spawned creatures, which was only meant to update a journal entry when all creatures from all these spawned encounters (from shared triggers) were killed. My existing system relied upon another trigger involved in the setup, which simply did not work reliably. Therefore, it was a case of rewriting the scripts surrounding this journal update event for those quests that relied on such.

Other Fixes

There were some other issues that revealed themselves in the latest lot of testing, but they were straightforward to fix by comparison. There was a situation where two "Hunger" icons were displayed in certain circumstances, due to me not doing a correct condition check.

There was the reappearance of some erroneous "faith" related information, which pointed towards an error I had in setting a variable at the time of "losing faith". This also had an impact on clerics "resting" and the prayers they gained, which meant it was important to track down and fix.

"Out with the old and in with the new" is probably the saying I mostly used regarding script changes recently made, as I rewrote some of the oldest scripts I had previously written ... even amalgamating similar event scripts to reduce overhead. I believe I have addressed most of these older scripts now, and, hopefully, I will be able to make progress again.

Hopefully, I will have a bit more to say in a few weeks time. If you don't hear anything in the meanwhile, just assume I am focussing on another set of issues, and will update you when I have more to report.

[Lance Botelle]

Hi All,

I was without an internet connection for a couple of weeks, but am back now.

Cheers,
Lance.

[Lance Botelle]

Alpha Testing (Restart) #2
 
Scripting AI is always a little harrowing, and so whenever I have to return to an issue to do with it, I always slow down a bit. This time around, during testing, I was reminded that players can switch "Puppet Mode" on or off for each PC they control. I knew this, obviously, but I had forgotten to take into account my own specially adapted system that allows players to switch to "Puppet Mode" from a main menu (for ease of use) and better control of combat. It meant that I had to add extra checks to allow for a "MIXED AI" setting icon to be displayed on the player's Main Menu icon should they turn Puppet Mode on or off individually for each PC they controlled. A quick search of the XML to find the scripts involved allowed me edit the OC scripts that controlled PC modes and now update my own system icon accordingly.
 
Taking Care With GetNearestObjectByTag
 
Now, I may be the only person who missed this, but I noticed something that I had not noticed before regarding the GetNearestObjectByTag function. If you do not pass a valid "TAG" (or more precisely pass a null tag), then I discovered that it can return the PC, which does not own a tag. This can be particularly hazardous, when (like I was calling it), you may accidentally pass a null tag without checking for such first. E.g. I checked for the TAG to search by retrieving the TAG being held in a variable. The problem is, I discovered that on rare occasions, the variable could be empty ... leading to the null tag, which, in turn, meant returning with the PC. This became a problem because my next line checked to see if the object returned was INVALID, which it was NOT ... even though the TAG checked for was " ". NB: The function can return OBJECT_INVALID if a string is passed and the object NOT found, but will NOT if the string is empty.
 
This problem revealed itself when I was opening a container which runs a pre-check on clicked testing against a potential TAG passed. If the container was NOT one of those with a string value, then rather than cause my script to run the OBJECT_INVALID path, it ran something completely different. I may have to double check the use of this function in other areas of my module ... just in case.
 
Time To Open
 
I also ran into a timing problem if a player chose to WAIT (allowing time to pass within the game) and NPCs were supposed to be in a different area after the time had passed, due to being a different time of day. Or vice-versa, NPCs would not turn up even though it was well past opening time! The problem was due to the way I had originally checked for NPC locations, which was based upon when a player left an area with their PCs. I used this event to check what any NPCs would do when the player left ... or entered a new area. The problem is, I had not yet accounted for NPCs who may have left an area and were due to return to the area in which the player rested their PCs, where the PCs did not actually leave the area in question. Thankfully, the main function was already written, and I have a dedicated RestEvents script, which I was able to add a small routine to call the function needed to do the check whenever the player caused time to pass within the same area.
 
Start .... Stop
 
The last significant problem to report this time around was a module quest specific one. i.e. Not a "systems" code problem, but related to s specific PC event to do with one of the potential earlier quests, where a guard would be called to the scene. This turned out to be one of those problems that was introduced after I had altered the creatures heartbeat script slightly. The problem was, an AI related call was firing before the creatures actions had completed, which meant the guard would start their procedure, just to be stopped in their tracks before they took two steps. It was not a game-breaker, but was a nuisance, and one I was glad to resolve.

More later, as I make progress....

A ) Approximate Alpha Testing 2 completion of points check list: 5%

B ) Party currently 1 ranger, 1 rogue, 1 cleric and a dog (henchman). All PCs are at level 1.

C ) Combats to date: 0 (No deaths, rebirths, respawns or raises.)

And a screenshot until I write again ... showing one of the puzzles:

[kevL]

Meester Bond, you cannot fool me weeth your ampty streeng ...

:|_~

[Dann-J]

Am I the only one who thinks the area revealed through the fog-of-war on the minimap in that screen shot above resembles something rude?

[Lance Botelle]

Am I the only one who thinks the area revealed through the fog-of-war on the minimap in that screen shot above resembles something rude?

There's always one.

Actually, I wondered if anybody may have noted how this map demonstrated the semi-transparent FOW for areas you already know .... but have not yet explored.

Cheers,
Lance.

[Tchos]

I didn't notice the semi-transparent FoW, but that's a nice refinement of the system.  Though I think I would either have the map pins absent in the transparent unexplored areas, or use an opaque unexplored area if I'm going to have map pins active in the unexplored area.

[Lance Botelle]

I didn't notice the semi-transparent FoW, but that's a nice refinement of the system.  Though I think I would either have the map pins absent in the transparent unexplored areas, or use an opaque unexplored area if I'm going to have map pins active in the unexplored area.

Hi Tchos,

Note that the transparent area map is only available to PCs that already know the area. i.e. Unexplored areas will be totally black ... EXCEPT if the player takes a unique special option near the start of the game. (Check out module when released.)

Map Pins will be absent in UNKNOWN areas (except for perhaps obvious comments or learned info). They are only present on this map because the PC is assumed to know the area well. In theory, one could argue that I could have left the map completely without any FOW (but with all pins added), but I wanted the player to recognise areas they had wondered through (even though their PC knows it). And, of course, map pins will automatically be added as the PC explores an area or finds new locations. (Note also, the PC can add their own Map Pins when controlling their Main PC.)

Cheers,
Lance.

[Lance Botelle]

Alpha Testing (Restart) #2.3 ( B )
 
I am continuing to make steady progress with testing different parts and paths of the module ... and am still having to make some "significant" updates. By this, I mean there are updates I am making that are fixing a broken side quest, mostly to do with a conversation not flowing correctly due to a missed variable check.

However, I did hit a rather frustrating point last week after I discovered what appeared to be potential saved game corruption due to manipulating module scripts between module saves. See the link below:

http://forum.bioware...or-transitions/

I am going to try to circumvent this problem by returning to my priority hak system of patching (rather than simple add to override, progress, save and remove again), to see if that avoids save game corruption (if indeed that is what it is).

Now, unfortunately, this also means I will have to restart the module again! However, I am going to fast track through the stages with the same party as last time, so that my next report will (hopefully) be further along than my furthest point to date. Also, to clarify post titles, I am now referring to posts in the format used above and in the following example (which will be the next post title): "Alpha Testing #3.1", where the first digit represents the number of restarts I am on to date and the last digit represents the report number for that restart. i.e. This will mean I am on the third restart, and that is my first report of that restart.

BETA TESTERS: I apologise for the delay, but I do believe it is essential that I iron out these potentially game stopping bugs prior to beta release. As soon as I think the game is stable enough for testing, I will contact you all and update this thread.

Cheers,
Lance.

[Lance Botelle]

Hi All,

Just a quick file explaining a bit about what to expect when entering "The Scroll" for the first time:-

DOWNLOAD PDF QUICK SHEET & GAME MANUAL (RAR): https://dl.dropboxus...Information.rar

Cheers,
Lance.

A FEW SCREENSHOTS:

[Lance Botelle]

Alpha Testing #3.1

50th Birthday Target

I have tried setting myself a date for when I would like to release this module to the public: the 1st October (this year), which coincides with my fiftieth birthday. I would like to give the beta testers at least a month to give me feedback, and so that means having something ready for them to be able to play by the end of this month. To meet this date, I have decided to cut back on my own testing and concentrate only on two aspects:-

1) Lighting and Sound for areas. (Currently 23.5% checked.)
2) Encounters and Bestiary entries. (Currently 15% checked.)

This means "Conversations" and "Treasures" (which I had hoped to double-check), will now be left to the beta testers for feedback, alongside everything else, including basic working and flow.

New Material

I did also have to spend a little time accommodating another side quest after realising I had made reference to it, but somehow missed doing anything about it. To prevent further delays, I made the decision not to cover one or two "options" that I was going to include originally, and see if the beta testers are conscious to the "missing" options. If too many report a request, then I will endeavour to include it before final release.

Store Conversations

This new quest did help me to finish off another system concept I wanted to include, which is to allow conversations start if a PC sold a particular item to a vendor. This has now been achieved, and adds a neat element to the already new store system.

Fixed Crafting Anomaly

I also fixed a crafting anomaly, where you could add enchantments to "gloves", but not to "bracers". This appeared to be down to a confusion about the BASE_ITEM_XXXX, where BASE_ITEM_GLOVES use the "Gauntlet" descriptor and BASE_ITEM_BRACERS use "Bracers". The problem is, only the "Gauntlet" allows enchantments. Therefore, as changing the descriptor does not affect anything else to do with "bracer" items, I set all their "Bracer" descriptor to "Gauntlet", which means it now returns BASE_ITEM_GLOVE, which can be enchanted like any other worn items. No more anomaly!

 

Not For The Faint-Hearted

 

I would like to point out that this module does not go out of its way to help the player. What do I mean by this? Well, firstly, I would like to think that the module offers useful tools and abilities available to the PC to make their tasks easier. However, they are not handed to the player on a plate at the start of the game. For instance, please note the following core D&D rules are in place:-

 

1a) PCs can become tired and hungry if they do not EAT and REST. (The VIGOUR system.)

1b) Eating means acquiring food or acquiring magic to overcome hunger.

1c) Resting means finding a good place to rest, and maybe taking longer to rest to recover all spells. (Due to environmental conditions.)

2a) Maps are not given to the PC unless they are familiar with the area. (The FOG OF WAR system.)

2b) Skills are available to help improve mapping capabilities.

3a) Wounds are not completely healed upon resting, although resting in a better environment will help.

3b) Healing potions are available at more reasonable prices, and there are medicinal plants.

4a) The PCs can wander wherever they have the ability to reach, but may not survive long if they enter dangerous areas.

4b) The game tries to give players descriptions that may give clues to whether something is currently too difficult for them.

4c) Some areas are *dark* and the PCs will need a light source (mundane or magic), or have Night or Dark vision to explore.

5a) You will not be a "Pack Rat" with respect to gold, unless the PC has the strength to carry it. (One bag of 500 gp weighs just over 10lb)

5b) Better to carry lighter gems, which you may be able to transfer to gold as required.

 

I may post more points as I recall them.

[Dann-J]

I've always wondered about the weightless gold in a lot of RPGs. Obviously everyone owns a Coin Purse of Holding. It's good to see a campaign where gold has regained its natural weight.

 

As for the screenshots above - we all know that people in glass houses shouldn't throw stones, but I also suspect that people in straw-thatched houses shouldn't walk around with flaming torches held high.  Maybe they need covered lanterns instead?

[Lance Botelle]

I've always wondered about the weightless gold in a lot of RPGs. Obviously everyone owns a Coin Purse of Holding. It's good to see a campaign where gold has regained its natural weight.
 
As for the screenshots above - we all know that people in glass houses shouldn't throw stones, but I also suspect that people in straw-thatched houses shouldn't walk around with flaming torches held high.  Maybe they need covered lanterns instead?

Hi Dann-J,

It certainly places more value on finding a Bag of Holding in this campaign.

Covered lanterns are in this campaign. In fact, the merchants use them because they are more precious about their stock (and can more readily afford them). As for the villagers, they (and their buildings) are always damp because of the rain.

I will be contacting Beta-Testers soon as I get the final checks made. (Well, almost all.)

Cheers,
Lance.

[Lance Botelle]

ATTENTION BETA TESTERS

I am now in the process of contacting and finalising contact details with Beta Testers (and any other potentials). If you have volunteered to be a Beta-Tester, please check your emails (and "junk" directory just in case), and you should have received an email from me confirming the email I have for you is still a valid one to use, and if it is OK to use in a common email with other Beta Testers where we can share information.

If you are a volunteer (and not yet given me a contact email), then you should have received a PM from me via these forums requesting an email that I can use to contact you regarding the testing. If possible, please can you supply me with one via a PM. I hope to use the email you provide to give download links and share information with other beta testers.

I may also have contacted you if I have not yet received any response form a PM I may have sent you ... or you did respond and I have misplaced my own response. If you can confirm if you want to take part or not, that would be helpful.

Finally, if you have not received any contact from me and would like to take part in beta testing, now is you last chance to get included on the list.

Cheers,
Lance.

[Lance Botelle]

ATTENTION BETA TESTERS
 
Files have now been uploaded and all those that have supplied me with an email address should now have had an email with direct download links and a link to my blog with instructions. If you have not received an email from me, then please contact me via email, my blog, or as a PM here.
 
ATTENTION INTERESTED PARTIES
 
For those interested in following the progress of beta testing, then please go to my blog (see signature). Here is a link to the first entry: http://worldofalthea...ly-updated.html
 
Cheers,
Lance.

[Lance Botelle]

Hi Everybody,
 
We are at the half way mark towards my hopeful release date on 1st October. Testing is still underway, and I am still expecting some more feedback from testers before the end of its testing period. Here are a couple of comments to date (with any specific details removed to prevent spoilers):-

"Good work!" - Thierry 10 Sep 2015

“Wow, man – quite a technical feat here. Probably the most I've seen in NWN2.” - Jason Roy 16 Sep 2015 (Bouncy Rock: http://bouncyrock.com/)

Thanks all,
Lance.