SITREP Mon 21 Sep 2015
Hi all,
Despite the seeming quiet it's been very busy behind the scenes.
There is a new
Build 5.1.21 coming out real soon. It's with LNL but they have a fair bit to do as it involves new installers for several of the modules. this fixes an issue with the commander signature images in the AAR screen. It affects only certain scenarios. It was an oversight on my part when we went to CO2. I had forgot to update the file paths for the sig files that referred to the Graphics\Scenarios\Default directory. In CO1 each game had a different sig files in the default dir. Under CO2 we can only have two, one for the axis and one for the allies. SO these sig paths had to be changed.
I signed off on our version of the
Westwall module. It's now with LNL for them to work up the their version of the installer. We are still pondering whether to stick with the "Westwall" name as this implies battles along Germany's entire western border. The current 12 scenarios cover the battles along the Westwall between Aachen and the coast. They do not cover the battles south of Aachen. We would like to get to these eventually but for now the current module focusses on the northern part of the wall. Needless to say until we can settle on a name we can't finish the cover either. Hopefully these will all be done this week and we can release the new module next week.
As I mentioned in another thread we have also been making progress on the
Trial of Strength board game. See here:
http://forums.lnlpublishing.com/threads/where-is-trial-of-strength.2018/
On a more mundane level Dan Dennison and I are in the process of migrating our
development framework to Visual Studio 2013 and implementing our back end source repositories. Once we have that settled I'll be doing a get on all the code changes Dan has made to address the use of "strings" in the game engine so that they comply with the new methods mandated by Microsoft. We need to do this so we can get our existing code working in the new environment. Once that I under our belt we'll begin the new core engine development work for the next upgrade.
Given the upheaval of migrating to VS 2013 I am going to start with a very limited focus on Sequential Tasking. There is a fair bit to do in terms of both the UI and AI to implement this. In terms of
UI, we need to provide an interface for the user to issue and edit sequential orders. This will involve implementing triggers and named areas of interest (NAIs) so that we can support conditional sequencing - eg if enemy enter NAI then start next task. This will involve adding a new NAI tool to define the area on the map. We then need to provide a means for the user to select identify that NAI when setting the task options. We also need to provide a means to navigate to the next task in the TaskEdit dialog. The actual "trigger" will be embedded into the Task Edit dialog. Where we currently have Start and End times, we will now have Start and End triggers. These can be of different types - eg a set time, a condition relating to an NAI, a condition relating to the force status (eg if strength < XX%), or some other condition that I'm sure will raise its ugly head as we start coding. So there is a lot to do just for the UI.
But there is also a bit to do for the
AI. We need to create a new class for triggers. Within the ScheduleNextEvent() we need to handle triggers. We need to revise the Plan Doctrine used for all order types to accommodate not only triggers but the fact that the user can now set a sequential task and that this should override any of the default behaviours. Eg if you issue a Move task then the default behaviour on arriving at the objective is to defend there. Now we will have to modify that so it checks to see if there is a subsequent order and if so make a decision on what to do next. This gets complicated. If the trigger is a set time we need to see how long a wait is it and whether we should deploy into a defensive perimeter in the meantime. The nature of the subsequent order will also have a bearing. Eg if the next order is another move then we might decide to hold in our current formation. If it's an attack then may be it's best to deploy into an attack formation now to speed up the process. It gets complicated very quickly and so we'll need to a fair bit of thinking up front and then a lot of "code a little, test a little" to tease out the best approach.
Amongst all this I also hope to release
Knock on All Doors (KOAD) module in November. So it's going to be a busy few months ahead.
