Shannon V. OKeets
From: Honolulu, Hawaii
February 1, 2011 Status Report for Matrix Games’ MWIF Forum
Accomplishments of January 2011
I monitored all the threads in the MWIF World in Flames forum daily.
There are 125 bugs remaining for basic solitaire play.
Rolf and Matt have joined the programming team and are getting up to speed on how the game plays. Rolf will be working with Mitchell on Pascal code for NetPlay and the AIO. Matt will be working with Peter on AI Opponent scripts, which are written in LAIO. You’ll find more information on these under NetPlay and AIO below.
As I continue to learn my way around the MWIF code base Steve has asked that I first focus on three areas: (1) tracking down and fixing the cause of the delays occurring when changing Major Powers, (2) get NetPlay working to support multi-player beta testing of MWIF, (3) collaborate with Rolf to finish the AIO parser.
My availability in January was negatively impacted by a two week business trip abroad, leaving me precious little time to sink my teeth into the items Steve has me looking at. However, I did manage to make some progress in each these three areas [see the “From Mitchell” paragraphs below]. I look forward to a much freer schedule throughout February and a corresponding increase in my productivity with respect to MWIF.
Hardware and Software
Note that Theme Engine is a third-party component library use in MWIF to manage the color schemes and other screen elements associated with each major power.
The delay experienced when switching major power appears related to the mechanism used by the Theme Engine library to communicate the potential need for individual screen elements to repaint themselves. Theme Engine employs a Windows message broadcast model that is apparently less specific that it could be, which causes hundreds or even thousands of Windows elements to be unnecessarily queried and processed with each change of theme. For example, it examines all components in all applications that are running (e.g., word processing, spreadsheet). Fixing this will require us to subclass and tailor Theme Engine to better suit the needs of MWIF, which should not be a problem, but first we have to determine exactly where to make the needed changes. Even without the shortcomings of the Delphi debugger, issues like this are difficult to trace. Essentially, one needs to step through the executing code line by line as each Windows element is processed, which is a tedious and time consuming process. We are working through it, though, and gradually bracketing the list of components that actually need to respond to the Theme Engine broadcasts so the others can be skipped.
I released versions 7.01.02 (16 fixes), 7.01.03 (14 fixes), 7.01.04 (11 fixes), 7.01.05 (3 fixes), 7.01.06 (12 fixes), 7.01.07 (27 fixes), 7.02.00 (20 fixes), 7.02.01 (17 fixes), 7.02.02 ( 23 fixes), and 7.02.03 (25 fixes), to the beta testers last month. This totals 10 new versions and 168 fixes, which is 40% above average for fixes. I changed the numbering to 7.02.00 because the patch count reached 7 for 7.01. The next version will be 7.03.00 so there will be a full new version to accompany a complete source code upload for Rolf.
Fatal errors still occur and some remain inexplicable, although I solve some of them every month. Most of the bug reports are related to recent changes. There are so many interconnections in the WIF rules and corresponding MWIF code that try as I might it is difficult to anticipate all the repercussions of even small changes.
One thorny area has been naval air combat. That is the nexus of numerous rules: DOW surprise, spending search rolls surprise points, air-to-air combat, multiple rounds of air-to-air combat, antiaircraft fire, aborting air units from air-to-air combat and antiaircraft fire, naval combat results, multiple naval combat rounds, aborting naval units from naval combat, and interception of naval units aborting from naval combat. Throw in land based air units and carrier air units which can either be printed or temporary carrier air units representing each carrier, and you have a lot of detailed steps. For instance, if a printed carrier air unit is destroyed, then it just goes into the force pool. But if a temporary carrier air unit is destroyed, then its parent carrier becomes damaged. All carrier air units also need to be assigned roles as either fighters or bombers for each round of naval combat, although their roles do not change within an air-to-air combat.
I’m working my way through that code but it is difficult enough just to set up the saved games needed to test everything. Nonetheless, I have reduced the number of bugs for Naval Movement and Naval Combat from 59 (28 + 31) as of December to 21 (6 + 15) as of today.
Saving and restoring games is stable.
Map and Units
Rob continues to send me updates of the naval unit writeups.
Scenarios and Optional Rules
I fixed a few bugs related to setting up partisan units behind enemy lines after all the major powers have been set up. This was a tricky subphase of the Setup phase. It needs to perform a preparatory check to see if there is enough room for the units to be placed on the map. If the occupying major power positions his units well, he can sometimes cover all possible placement locations with enemy zones of control. That results in no partisan units being capable of setting up.
MWIF Game Engine and CWIF Conversion
Solved all outstanding bugs related to land combat. I still need to add an additional subphase at the end of the processing sequence for disorganizing units. Presently that is done when combat results are applied. It should occur following the Advance After Combat subphase. I also corrected most of the bugs related to land movement. What remains to be done for that phase pertains to imposing restrictions on undoing moves that affect supply status so players can not ‘cheat’.
I killed off the bugs related to creating Vichy France. As part of that I created a small new form so the Vichy France controller can allocate countries that were aligned or conquered by France to Axis major powers. There are still some small changes that I need to make based on my better understanding of those rules. But the main task of getting the creation of Vichy France to flow from start to finish is done. I must of run the opening segments over a hundred times this month. As I did that I found many small improvements to make to their efficiency and clarity. As a simple example, when a unit has to be moved to the nearest hex, the program now identifies exactly which hex is nearest. There might be several, but providing the first one enables the player to get the general idea of where to look for others. I thought about providing the full list but decided the pain of coding that wasn’t worth the gain.
As part of my quest to fix all problems with Vichy France I rechecked the code for making Vichy hostile and collapsing Vichy. There was a least 1 serious problem regarding the latter.
Here is the new sub-subphase sequence of play for determining country and hex control at the start of the Vichy creation:
• Dice are rolled for all the Vichy Groups and each is assigned to either Free or Vichy France.
• Each country France has conquered is aligned to an Axis major power (if the die rolls indicate that it belongs to the Axis).
• Each country France has aligned since the start of the war is conquered by an Axis major power (if the die rolls say so).
• After all the new alignments and conquests have occurred, units are rebased - if any need to be. These are handled as ‘overrun' digressions.
I rewrote most of the code related to transported units. I was having a devil of a time trying to debug that. In fact I still have one item left to correct during the Return to Base phases. The new data structure enables me to find and fix bugs in a fraction of the time it use to require.
I replaced a CWIF component for grids (TSimpleGrid) with one from the JEDI library (TJvStringGrid). The former was generating program crashes when the mouse wheel was touched while the grid was displayed. There were nine uses of TSimpleGrid and it took me almost a full day to make the substitutions. Visually there is no apparent difference. But TJvStringGrid does not crash the program, so the time and effort were worthwhile. I have now standardized on the use of TJvStringGrid throughout MWIF; it appears in 85 places.
Modified the OverStacked form and reset where in the code the checks for overstacking occur. I need to add one more check at the end of the land movement phase for overstacked air units that have been deserted by an HQ or engineer that had previously provided a stacking bonus.
Imposed a restriction on moving land units so you are no longer able to partially move a unit, move a second unit, and then go back and continue moving the first unit. Doing this would violate the WIF rules. However, you are permitted to continue moving a stack of units that performed an overrun if you do so immediately after any overrun air and/or naval units have finished rebasing.
Corrected a few small error in the Selectable Units form (e.g., the Help button didn’t work). Almost all the forms are the way I want them. Exceptions are the PBEM and NetPlay forms which either need to be created or undergo heavy use to identify any rough edges.
Internet - NetPlay
After Mitchell transfers the code from the stand alone test program for NetPlay into the main MWIF program, he’ll be working on testing it there. To help out, Rolf has joined us and together they need to convert the Windows messaging system that CWIF used to Game Record Logs. I have done about 2/3rds of that work already and there are slightly less than 100 GRLs to implement. I’m not sure how fast that work will go but it could take as little as a month or as much as 2 months to put in the basics. Then the real work begins with having multiple players on different computers test playing a game over the internet.
I am building a class wrapper around suitable Indy components to facilitate integration of NetPlay into MWIF. The idea is to encapsulate the TCP and PBEM functions needed to support multi-player testing, exposing methods that make it simple for the main MWIF code to pass the Game Record Log structures it is already programmed to build. I am nearly finished with a new version of the NetPlayComTest utility designed to test the new NetPlay class. I had hoped to get this out to the beta testers before my trip but I simply ran out of time. I now plan to finish it this week.
Once Mitchell gets the NetPlay communications working, he’ll do the same for the PBEM communications. This should be a lot easier than the NetPlay code, partially because Mitchell has previously created PBEM applications (although not for games).
Artificial Intelligence (AI)
Peter is anxious to write more scripts and test the ones he has already completed. The latter are for setting up minor country units when they enter the war. I think he has a script for each minor country at this point. There are a lot of small decisions in WIF and I’ve set up the AIO decision making so each one is a separate decision point. The task is to work out the process for how the AIO should make each decision and then write it up as a LAIO (Language for an AI Opponent) script.
Matt should be a great help on this. I find that everyone contributes new insights into what needs to be done for the AIO and how to accomplish it.
I studied the AIO language and a few of the scripts. Finishing the LAIO parser should not be too difficult but I have yet to coordinate with Rolf to get started - will do so next.
I updated the Players Manual with a few small changes. However, I have several other additions and edits to make that I am delaying until the bugs in the sequence of play code are ironed out.
Tutorials, Training Videos, and Context Sensitive Help
Made some changes to the context sensitive help messages based on feedback from the beta testers.
Historical Video, Music, and Sound Effects
Paul is the administrator for the fan site. He has offered to set up Rolf and Matt with access so they can review and comment on it.
Perfection is an elusive goal.