MWIF Monthly Reports

World in Flames is the computer version of Australian Design Group classic board game. World In Flames is a highly detailed game covering the both Europe and Pacific Theaters of Operations during World War II. If you want grand strategy this game is for you.

Moderator: Shannon V. OKeets

Post Reply
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

MWIF Monthly Reports

Post by Shannon V. OKeets »

April 2, 2010 Status Report for Matrix Games’ MWIF Forum


Accomplishments of March 2010

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Hardware and Software
I completed replacing all the assembler routines with equivalent Pascal routines. Doing so also eliminated any code that modified the call stack. I still have glitches when Delphi 2010 IDE (Interactive Development Environment) executes MWIF in debug mode, but it continues to improve (or at least I have that impression). Once the Assembler mysteries were gone I was able to focus on Theme Engine bugs.

Theme Engine 9.10 caused me some new grief. One of its new features is the ability to animate buttons (TTeButton) so they can be programmed to blink and do other stuff. However, the cost of this change is 5 more bitmaps for each TTeButton. MWIF can not afford that - and I have zero interest in animating buttons. The program is already close to tapping out the available bitmaps under Windows XP and given that MWIF has 750+ TTeButtons (i.e., 3750+ new bitmaps), this change in Theme Engine caused the program to fail do to insufficient “Windows resources”. So, I replaced all the TTeButtons with TTeSpeedButtons (which do not have the sexy animation feature).

Although that global change was done with one command and executed in 2-3 seconds, there were other code changes required. The compiler caught most of those and I was able to get a clean compile and execution within a half hour. Annoyingly, the differences were more extensive. A TTeButton has embedded defaults which were used extensively within MWIF. A TTeSpeedButton has no defaults so I had to explicitly code stuff that had been done automatically previously. For example, when you click on an OK button (and it is a TTeButton), Windows automatically closes the form, and records that you pressed ‘OK’. It does something similar for Cancel, Yes, and No buttons. Basically, I spent 3-4 days making the full conversion to TTeSpeedButtons.

After all these attempts to remove suspects, I was still getting weird errors. Therefore I disabled the execution of the Theme Engine themes. At that point I was able to debug in a more normal manner, and I have cleaned up what I hope to be all the newly created bugs do to the conversion from Delphi 2007 running under Windows XP to Delphi 2010 running under Windows 7. I even fixed some older bugs I encountered along the way.

Beta Testing
I released version 4.01.00 to the beta testers last week. I expect to release 4.01.01 later today and return to meeting my goal of releasing a new version every 5 days or so. I would like to do 6 new versions/month. Once things settle down and I have restored my shattered confidence in the MWIF code, I’ll reenable Theme Engine themes and see how that goes. By the way, I did spend a little over a week this month looking into modifying the Theme Engine source code (i.e., the definition of TTeButton). I had mixed success with that and decided to just go back to the original TE source code. TE consists of 100,000+ lines of undocumented code, with multiple levels of abstraction, so messing around with it is very unpleasant.

Saved Games
Fixed a bug with recording the movement of factories. Now saved games record which factories have moved where and any damage factoreis have sufferred due to strategic bombing.

Map and Units
Added some more naval unit writeups from Rob/Warspite.

Scenarios and Optional Rules
Nothing new.

MWIF Game Engine and CWIF Conversion
Substantially modified/reduced the CWIF library routines by eliminating assembler routines and unused definitions of fundamental components (i.e., hash tables).

Player Interface
Fixed some bugs in the Victory form.

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Andy Johnson has returned to working on the MWIF web site (the restrictions placed on him by his employer no longer apply). Presently the web site is being reviewed by Matrix Games and the beta testers. When it will be made available to the public at large depends on Matrix Games management and other demands on Andy’s time.

Communications
Nothing new.
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

May 2, 2010 Status Report for Matrix Games’ MWIF Forum


Accomplishments of April 2010

Project Management

I monitored all the threads in the MWIF World in Flames forum daily.

Hardware and Software
Theme Engine is still disabled but I expect to restore it to active duty in the next couple of weeks. Running the Delphi 2010 IDE/debugger is still very annoying. For example, as I type this I am waiting for the debugger to reach a ‘Break’ point so I can analyze variable values to see why it is having trouble returning Yes to the question of whether an Egyptian unit cooperates with Wavell. I’ll probably have to kill the IDE and restart Delphi 1020 soon. The IDE is continuously requesting more memory (from 4K to 80K) every second or so. It starts out with 130 MB and increases that up to 282 MB (currently - I monitor this all the time, and I always debug with a stopwatch near at hand so I can track how long it takes inspecting its navel). My system has 12 GB of RAM and 9GB of that is unused, so I don’t care about it requesting more memory, I just wish it wouldn’t take forever before letting me examine variables. At one point this month I resorted to progamming methods I used in the late 1960's: inserting print statements to track variable values, sigh.

Beta Testing
I released versions 4.01.01, 4.01.02, 4.01.03, 4.01.04 and 4.01.05 to the beta testers this month. They got a new version about every 4 days at the beginning of the month but that paced slacked off once I started working on the rewrite of the supply routines. I’ll upload version 4.01.06 to them today (either before or after I finish writing this).

Almost all of the changes this month related to correcting new bugs that I introduced when making thousands of edits since the first of the year - to accommodate Delphi 2010, Theme Engine 9.10, and other libraries upgraded to support Windows 7. Those are down to only a few bugs presently, but the beta testers will undoubtedly find more as they work their way through the 152 phases/subphases/sub-subphases.

Saved Games
Nothing new.

Map and Units
Added some more naval unit writeups from Rob/Warspite.

Scenarios and Optional Rules
Nothing new.

MWIF Game Engine and CWIF Conversion

Rewrote the supply routines. I am now in the process of debugging them. So far the program correctly identifies all primary and potential secondary supply sources for all countries (major powers and minor countries). It also finds the shortest overland rail path from each secondary to a primary correctly. I am very happy with its ability to perform a directed search, wherein it makes the right choice as to which hex to explore next; one of my main concerns here was to improve the efficiency of tracing a supply path so the AIO could conduct hundreds of what-if moves and determine the effects those moves have on supply.

I haven’t tested the oversea path search algorithm yet, though that code is mostly written. I also have written the code for tracing a Basic supply path from a unit to a supply source. Actually I wrote the code for unit => supply source Basic path first. And then I cloned and modified that to create the secondary => primary using a Rail path. I’ll reuse the code for searching for a Basic path to link ports to supply sources and units, and to link tertiary supply sources to secondary and other tertiary sources. I already have written the code to propagate supply from one sea area outwards.

Perhaps I should explain the logic here. Every coutnry which has units maintains the following variables:
// ****************************************************************************
// Variables for supply links, connections, and paths. Primary sources.
// ****************************************************************************
PrimarySupplyCities: TSupplyCitiesList;
PrimarySupplyHQsTurn: TSupplyHQsList;
PrimarySupplyHQsImpulse: TSupplyHQsList;
PrimarySupplyCoopCities: TSupplyCitiesList;
PrimarySupplyCoopHQsTurn: TSupplyHQsList;
PrimarySupplyCoopHQsImpulse: TSupplyHQsList;
// ****************************************************************************
// The secondary sources with All at the end are all possible secondary sources.
// ****************************************************************************
SecondarySupplyCitiesAll: TSupplyCitiesList;
SecondarySupplyCitiesCoopAll: TSupplyCitiesList;
SecondarySupplyHQsAll: TSupplyHQsList;
SecondarySupplyHQsCoopAll: TSupplyHQsList;
// ****************************************************************************
// These secondary and tertiary variables have valid supply connections back to
// a primary supply source.
// ****************************************************************************
SecondarySupplyCities: TSupplyCitiesList;
SecondarySupplyCitiesCoop: TSupplyCitiesList;
SecondarySupplyHQs: TSupplyHQsList;
SecondarySupplyHQsCoop: TSupplyHQsList;
TertiarySupplyCities: TSupplyCitiesList;
TertiarySupplyCitiesCoop: TSupplyCitiesList;
TertiarySupplyHQs: TSupplyHQsList;
TertiarySupplyHQsCoop: TSupplyHQsList;
// ****************************************************************************
// These variables track which sea areas can be used by each country for supply.
// ****************************************************************************
SeaAreasSupplyPath: TSeaAreaSupply;


The last variable is for keeping track of which sea areas can trace supply back to a supply source. It is defined as:
// ****************************************************************************
// Status. 0: unexplored; 1-4: # of basic hexes used; 5: failed; 6: impossible.
// Beaufort (#9) and Kara (#10) are impossible.
// ****************************************************************************
TSeaAreaSupplyEntry = record
Status: Byte;
Path: TSupplyPath;
end;
// ****************************************************************************
// 1st entry is for a Basic path, 2nd is for a Rail path, 3rd is for an infinite
// path (Isolation).
// If a RailPath exists, it's Status is always <= the Basic path's Status.
// ****************************************************************************
TSeaAreaSupply = array [0..SeaAreaCount - 1, 1..3] of TSeaAreaSupplyEntry;


Major powers have an additional variable:
// ****************************************************************************
// These variables track which sea areas can be used by each major power's
// aligned countries for supply. The difference between SeaAreasMPSupplyPath
// and SeaAreasSupplyPath is that the former is a path to the major power's own
// supply source, as opposed to one belonging to an cooperating major power.
// Aligned minor countries can not trace supply to the major powers that
// cooperate with its controlling major power.
// ****************************************************************************
SeaAreasMPSupplyPath: TSeaAreaSupply;


To help you understand why major powers have the second TSeaAreaSupply variable, consider a German and a Rumanian infantry units stacked together in North Africa. The German can trace to Italian supply sources, since they cooperate. But the Rumanian can only trace to German and Rumanian sources. So, the German can trace to any of the Italian cities on the coast, while the Rumanian will have to trace to supply further inland.

Here is the processing sequence for determining supply for all units on the map:
// ****************************************************************************
// UnitMenuTraceSupply.
// ****************************************************************************
// Step 1: find all valid supply sources for major powers and minors.
// ****************************************************************************
IdentifyMajorPowersSupplySources;
IdentifyMinorsSupplySources;
// ****************************************************************************
// Step 2: find all valid secondary supply sources that do not go overseas.
// ****************************************************************************
IdentifyMajorPowersValidSecondarySupplySources;
IdentifyMinorsValidSecondarySupplySources;
// ****************************************************************************
// Steps 3 and 4: initialize the sea area supply sources and identify all the
// sea areas that can be used by major powers and minors to trace supply to a
// primary supply source, by either a Basic (3rd step) or Rail (4th step) path.
// ****************************************************************************
InitializeSeaAreaSupply;
IdentifySeaAreasSupply(True);
// ****************************************************************************
// Step 5: identify all the secondary supply sources for both major powers and
// minors that can trace to a primary via an overseas Basic or Rail path. This
// search doesn't care what the path type is.
// ****************************************************************************
IdentifyMajorPowersOverseasSecondary;
IdentifyMinorsOverseasSecondary;
// ****************************************************************************
// Step 6: identify all the tertiary supply sources that do not go overseas.
// ****************************************************************************
IdentifyMajorPowersValidTertiarySupplySources;
IdentifyMinorsValidTertiarySupplySources;
// ****************************************************************************
// Step 7: identify all the sea areas that can be used by major powers and
// minors to trace supply to ANY supply source (which didn't become a valid
// supply source by going overseas), via a Basic path.
// ****************************************************************************
IdentifySeaAreasSupply(False);
// ****************************************************************************
// Step 8: identify all the tertiary supply sources that go overseas.
// ****************************************************************************
IdentifyMajorPowersOverseasTertiary;
IdentifyMinorsOverseasTertiary;
// ****************************************************************************
// Step 9: determine supply for all units,
// ****************************************************************************
TraceUnitSupply;

My general strategy here is to determine not only supply for each unit but to also record the supply path the unit used when it last traced supply. When supply has to be redetermined, each unit will first check to see if the path it used last time is still valid. If so, there is no need do a new search for a supply path for that unit. I record each supply path as a series of links (e.g., from unit to HQ to primary supply city). Then I also record which units are using which links. This enables the AIO to immediately know which supply links are being most heavily used: for defense and for offense. I’ve created a form so players can monitor this too (see below).

Player Interface
Created a new form for debugging supply paths. I expect this to be part of the final product and very useful for new players to learn about supply sources and paths.

The Supply Sources Display form lets you look at each major power and minor country and see (1) its different supply sources. Clicking on a supply source centers (2) the insert map on the hex. It also lists (3) the hexes and sea areas in the path that is being used. You can examine secondary to primary paths the same way. At the bottom of the form is (4) a list of the units using the supply source. I want to add the ability to list all the units that are out of supply and isolated as well. Once I get Theme Engine reenabled, I’ll post some screenshots of the form and solicit comments.

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Andy Johnson has made enormous progress on the MWIF web site. The beta testers have been given access to the site and have been helping with content and well as critiquing how things look and feel. At this point, when it will be made available to the public depends primarily on Matrix Games management.

The fan site contains a lot of different stuff: Picture & Text Tutorials, Training Videos, Articles on AI by Peter, and on playing through a turn of WIF by Patrice, Screenshots, Rules as Coded, excepts from the Players Manual (on scenarios, ADG add-ons, optional rules, sequence of play, modes of play, system requirements, etc.), an article previously published in an ADG Annual where Patrice interviewed me about game develpoment, and WW II quizzes. The last is expected to be a monthly feature on WW II trivia, WW II movies, and MWIF rules. Robert, Paul, and Michael are helping Andy with that. Meanwhile Patrice is working on a MWIF wiki for the fan site.

My involvement has been close to nil, but I look it over every so often and I think it will be very well received.

Communications
Nothing new.


_____________________________

Steve
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

June 5, 2010 Status Report for Matrix Games’ MWIF Forum


Accomplishments of May 2010

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Hardware and Software
Theme Engine is still disabled. Running the Delphi 2010 IDE/debugger has dropped down to merely annoying, because I am now using work-arounds, which are actually better than the debugger in a few instances. Although I would still prefer to have the debugger’s functionality available, obviously.

Beta Testing
I released versions 4.01.06 and 4.01.07, to the beta testers last month. The next version for them will be 4.02.00 since when the number of patches is high (each time the last number changes the version is a patch) downloading and installing the program becomes tedious.

The changes this month were to correct bugs I introduced when making edits since the first of the year, new code for the improved supply determination routines, and enhancements to the supply path display form.

Saved Games
Nothing new.

Map and Units
Added some map changes in Australia from Patrice.

Scenarios and Optional Rules
Nothing new.

MWIF Game Engine and CWIF Conversion
I continued to rewrite the supply routines, with debugging them taking a ton of my time. Partially this is because I kept trying to use the Delphi 2010 debugger - I have since sworn off trying to do that except in extraordinary cases. After much effort, I have the overseas path search algorithm working correctly. Indeed, I stepped through that code hundreds of times looking for bugs and in the process found ways to improve its efficiency.

What cost me almost a week of time was trying to find a bug in the supply path determination routines when no bug existed. The problem was that the display form had a bug so the path that was shown on the form looked defective/incomplete. In reality the path was perfect but the presentation of the path on the Display Supply Paths form was stopping processing abruptly. Usually the MadExcept package I am using detects this kind of exception and fault isolates it for me. In this instance the program just skipped some code and acted as if it had completed the processing with no trouble. Spending days going over code that is perfect, looking a mistake that isn’t there, has a zero happiness quotient.

I find it near to impossible to stop trying to fix a problem when I have a good understanding of the circumstances under which it occurs. Hence the lateness of this monthly report. As long as the overseas supply path determination routine had a single bug, I simply could not drag myself away from fixing it to write this report.

Player Interface
Made major enhancements to the new form for displaying supply paths. The Display Supply Paths form lets you look at each major power and minor country and see (1) its different supply sources. Clicking on a supply source centers (2) the insert map on the hex. It also lists (3) the hexes and sea areas in the path that is being used. You can examine secondary to primary paths the same way. At the bottom of the form is (4) a list of the units using the supply source. I want to add (5) the ability to list all the units that are out of supply and isolated as well. Items 1 through 3 are now fully functional and I’ll complete the other two this coming month.

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Andy Johnson continues to made enormous progress on the MWIF fan site. Currently we are planning on making the fan site available roughly a month or two before MWIF is released.

Many of the features I listed in last month’s report about the fan site have been improved. Andy is currently working on setting up a system for players to link up with each other for playing games over the internet and by email. His newest addition is to create a system for “Game of the Month”. His idea is to create a saved game of a particular scenario (a definitive start and stop points with selected optional rules) for everyone to play. At the end of the month the person with the best ‘score’ will be announced and the game annotated. As I write this, how to score a game is an open question.

My involvement in the fan site remains close to nil.

Communications
Nothing new.
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

July 1, 2010 Status Report for Matrix Games’ MWIF Forum


Accomplishments of June 2010

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Hardware and Software
Theme Engine is still disabled. I rarely use the Delphi 2010 IDE/debugger any more, but I’ve become quite efficient using work-arounds. My work-arounds are inline diagnostic messages that let me track call sequences and variable values. I comment out the messages once I have fixed the problem (unless I forget).

Beta Testing
I released versions 4.02.00 (24 bug fixes), 4.02.01 (20 fixed), 4.02.02 (20 fixes), 4.02.03 (14 fixes), 4.02.04 (3 fixes), and 4.02.05 (19 fixes) to the beta testers last month. I had left diagnostic messages active in version 4.02.03 which drove the beta testers crazy (every time they moved a unit the program reported its destination hex); hence the quick upload of a new version the next morning. The beta testers send me saved games for many of the bugs they discover so it is easy for me to reproduce them and for me to validate that I have corrected them after making changes.

The mods this month were to correct bugs in a variety of places in the sequence of play. Over the past 2 weeks I have been gathering some momentum, usually correcting all new bugs the beta testers have posted during the night by noon my time (Hawaii). Then I spend the afternoon and evening working on the backlog or writing new code.

Saved Games
I have these fully functional again. There had been sporadic glitches which seem to have been cleared up.

Map and Units
Added some small map changes from Patrice. I also renamed the Verz Cruz (sp) militia to Veracruz so it matches the city name on the map, enabling the program to know where to place it when it arrives. Rob sent me an update of the naval unit writeups.

Scenarios and Optional Rules
Added new code which finalizes the optional rule for changing when the game is over. The players can do this whenever they like, setting the last game turn anywhere from the current turn to Nov/Dec 1952.

With the help of the beta testers, I have finished the specifications for how the Unlimited Divisions optional rule works. Based on that discussion, Paul has volunteered to write up the rule for inclusion in Rules as Coded and the Players Manual. I’ll post more on that once I modify the form for reforming the divisions back into corps/armies.

MWIF Game Engine and CWIF Conversion
I completely rewrote the code for determining valid naval moves. The CWIF code had used recursion that was dependent on assembler routines. Since I had removed all assembler routines, I needed to create a new solution to the problem of determining which ports and sea areas were valid destinations for a naval unit. A Repeat ... Until structure served that purpose. This rewrite took me a week but it enabled me to correct some logic deficiencies and to fix some bugs reported last year in November and December. I had been in the midst of fixing those when I decided to upgrade to Windows 7, Delphi 2010, et al.

The new search routines look for a path that can not be intercepted by enemy units. This is very handy when returning to port, since you will rarely want to encounter enemy units at that time. CWIF always searched for the shortest path, even if it took the units through sea areas controlled by the enemy. Now don’t get me wrong, you can still take a shorter path through enemy controlled sea areas. For instance, that can happen if you want to reach a higher sea box section in a destination sea area. To do so, you specify the path for the naval units one sea area/port at a time using Ctrl Left Click. The new code is working well now. From a programming perspective, it is both simpler to understand and fully documented.

I added another piece of code to my rewrite of the supply routines: enabling HQs in a coastal hex to trace supply overseas without having to first find a land path to a port. I’ve gotten the code for tracing from tertiary to secondary supply sources mostly written but I haven’t activated it for testing yet (I like to reread code several times after I have written it to reassure myself that the logic is sound). Once I can get far enough ahead of the beta testers, who quickly report bugs when I upload a new version, I’ll finish the rest of my new supply routines and trash the old ones from CWIF (which are still in place and still execute all supply determination).

Player Interface
Created a new form for changing when the game ends. It is accessible when a new game is being started and also during play. In both cases it is accessed using a button on the Optional Rules Help form for Extended Game Play.

For the Unlimited Divisions optional rule I began work on modifications to the Pools form so it shows which divisions were created when a corps/army was broken down. As part of that, the location of each division is shown.

Internet - NetPlay
Removed the last of the CWIF code for Internet Play. That had been based on using Windows utility routines, while MWIF’s is based on a Delphi library for Internet communications. Because the old routines were interfering when playing Head-to-head, I went to the effort of cleaning up this loose end.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
A few small changes to reflect changes in rules interpretations. Nothing important, but I want both Rules as Coded and the Players Manual to be as precise as possible.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Andy Johnson has the MWIF fan site looking good. My involvement in the fan site remains close to nil.

Communications
Harry Rowland answered a question posed by Patrice (on behalf of MWIF) about the use of fractional odds on the 1D10 Assault table. The question arose because there are gaps in the odds columns: 5:1, 7:1, and 10:1. So, what happens if the odds are 8.5:1? Harry’s answer was that there was a 50% chance of rounding up to 9:1, which is then reduced back to 7:1. This becomes important if there are other factors causing odds shifts - weather and snow units for example.
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

August 1, 2010 Status Report for Matrix Games’ MWIF Forum


Accomplishments of July 2010

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Hardware and Software
Theme Engine is still disabled. I never use the Delphi 2010 IDE debugger any more. I find the in-line tracking messages faster for debugging, and I should have been doing it this way since forever. By adding if statements to control when the messages are displayed, I have more control than I had in the debugger. I am also able to leave the debugging messages in as comments, so if a section of code causes any problems later, I can reactivate the debugging information quickly and easily.

Beta Testing
I released versions 4.02.06 (21 bug fixes), 4.02.07 (13 fixed), 5.00.00 (4 fixes), 5.00.01 (4 fixes), 5.00.02 (6 fixes), 5.00.03 (8 fixes), 5.00.04 (9 fixes), 5.00.05 (22 fixes), 5.01.00 (13 fixes), 5.01.01 (5 fixes), and 5.01.02 (10 fixes) to the beta testers last month. I also have 7 more fixes done for version 5.01.03, but I want to finish modifying Production Planning before uploading that version to the beta testers. This totals 11 new versions and 122 fixes which is up from 6 new versions and 100 fixes last month. It also includes some new code, discussed below, so my productivity improvement due to changing debugging methodology has quantitative substantiation.

The major change in bug reports is that fatal errors have dropped off to close to zero. These had been dominating the beta tester bug reports for years, and had been resurgent since the massive changes I made in the first quarter of this year. The MadExcept utility software catches virtually all of the fatal errors and reports them as Access Violations. That translates as trying to use a portion of the computer memory that has not been allocated for use by the program (i.e., MWIF). For most of my programming life, access violations were rare (~5%) but with the advent of object oriented programming (OOP), they now comprise ~95% of fatal errors. Partly this is because the new compilers detect/catch “Index out of Range” errors which had been the primary fatal error when programming in the 60's, 70's, and 80's.

The arrival of OOP means that everything in a program is an object - if that is at all possible to achieve. For example, in MWIF, there are separate objects defined for: units, the map, countries, sea areas, trade agreements, neutrality pacts, declarations of war, and each phase of the game. Indeed, there are specific objects defined for land units, naval units, air units, special units, subcountries, minor countries, major countries, and so on. There are objects for stacks of units (on map and off map) and moving unit stacks. There are over 150 more object types defined for the forms alone. My point is that there are well over 400 object types defined for MWIF.

Each object has associated with it both data and procedures/functions. For example, there is a fixed datum on a land unit object’s combat strength and a function that calculates its current defense strength based on terrain and supply. Which brings me back to the access violations. If the program needs to reference an object and the pointer to that object has a nonsense value, then an access violation occurs. A simple case would be looking up the current defense strength for a unit that is off map. The hex coordinates for an off-map unit are nonsense and trying to figure out the terrain type using those coordinates produces a MadExcept error: Access Violation.

So, since everything in MWIF is an object, and the number of interrelationships between objects is enormous, of course the fatal errors are almost always about a failure to set/clear object pointers. This is why all the rules are so hard to code. It is necessary to understand all the possible situations where one object might have to reference another object and to keep all the pointers accurate. As part of this solution, there are literally thousands of instances in MWIF where a preliminary check is made to see if a pointer to an object is nil (undefined). If the check detects a nil pointer, it typically skips processing the next section of code. This comes up in hundreds of cases where a player might choose to terminate a game in the middle of anywhere in the game. The program has to check for the game terminating rather than trying to process game elements. For example, if the player is choosing whether to commit submarines to an attack and instead decides to terminate the program, MWIF has to close up the forms for committing subs and naval combat that are open without trying to process any implied decisions.

Saved Games
I went through restoring over 150 saved games (GAM files) and found a variety of errors. Some of the very old GAM files were incomplete, the program having failed to write out the GAM file. There was another problem restoring games from before version 00.00.12.00. I decided that figuring out how to fix that wasn’t worth the effort because those games were from before 2009, 18+ months ago.

I did find one major problem with saved games that threw me into a panic, and I uploaded a full new version to fix it (00.05.00.00). After a couple of days my panic waned and I realized that the error affected less than 5% of the saved games. I was able to insert a detection routine which warns the beta testers (and myself) when a saved game is ‘damaged’. I was also able to correct the problem in some instances so the GAM file could still be used.

Map and Units
Rob sent me an update of the naval unit writeups. Once again I am under the illusion that the Unit data is complete. I made one coding change to modify how City Based Volunteers are displayed. I added a ‘V’ in the upper right corner of these units so it is easy to identify that they are CBV. The V does not intrude on the rest of the unit depiction - it occupies the same place as the R for reserve units.

Scenarios and Optional Rules
Added new code for Internment. This optional rule is only used rarely, but its most common occurrence is during the 2nd impulse of the Global War scenario, so the beta testers complained about this a lot. Since this optional rule was not part of CWIF, this was all new code.

I finished the code for Partisans. There had been a few small bugs with the Partisans phase, but the most difficult task was adding another subphase to the setup phase, after all the major powers have set up their units. In some scenarios there are partisan units that need to be set up after all the major powers have put their units on the map. For example, when the USSR sets up before Germany, there has to be a separate setup subphase for the USSR to put its partisan units on the map after the Germans have placed all their units in mother Russia. Particularly tricky was the check to see if there is sufficient room for the partisans to be placed on the map. If the Germans cover all the occupied hexes in Russia with zones of control, well, then the USSR partisans are simply destroyed instead of being placed on the map. Again, CWIF did not contain any code for this because the 3 CWIF scenarios did not include partisans in any of the setups. So, this was all new code.

I made some progress on the City Based Volunteers optional rule. Besides adding the V in the upper right corner of these units, I also separated them out from units in the force pool and future force pool on the Scrap form. There are several unique aspects to City Based Volunteers, which require me to do some considered thinking before coding the rest of that optional rule.

MWIF Game Engine and CWIF Conversion
I completely rewrote the code for determining valid land moves. This is comparable to what I did for naval moves last month. I also did the same for determining legal setup locations for naval units. Altogether, these 3 modules contain 2400 lines of code. They had previously been part of MoveStack (i.e., moving units), which has shrunk by a similar amount. Sadly, MoveStack still has 8300+ lines of code, which is more than I like for any one module. By comparison, the Main module has 8500+ lines of code, and I consider that the Big Ugly in the list of 350+ MWIF modules.

Player Interface
I fixed some problems with using multiple monitors. Depending on how a player’s system is configured and on which monitor the Mainform is placed, the positioning of other forms relative to the Mainform can be difficult to work out. This all seems to run correctly now. Once I find a beta tester willing to test out 3 monitors, I’ll make sure the code is copacetic for that too.

I finished the last remaining task for Lend Leased Air Units. This piece of code enables the source major power to demand back any lend leased air unit that is still in the borrower’s force pool or air reserve pool. Lend leased air units code is finished.

I inserted messages for whenever a unit is destroyed. At times this had been done without informing other players. Now there is not only a message about the unit’s destruction, but also a short explanation of as to why the unit was destroyed. When playing solitaire, head-to-head, or against the AIO, this change isn’t that important. However, for internet and PBEM play, keeping everyone informed about mortalities seems necessary.

I returned to work on the Production Planning form. It now correctly displays all the resources and factories for each major power and correctly transfers resources that are shipped to comply with a trade agreement. For instance, the resources that the USSR ships to Germany as part of the Nazi-Soviet pact show up in Germany’s resource list and not in the USSR’s. Today’s task is to get the automate routing of the resources to their destinations: either a factory or, for oil points, a location where they can be saved. This code no longer works because it uses recursion (assembler code) which I removed in the second quarter of this year.

The longer term goal for the Production Planning form is to enable the player to review and modify the routes resources take to their destinations. My design is to provide a mini-animation for displaying routes. If the resource is moving by rail, the form’s small insert detailed map (zoom level 4) will be centered on each hex in the path, with a half second (or so) delay between centering on each hex. If a route goes overseas, then the insert map will change from the detailed to a global map, and the centering will be on each sea area instead of individual hexes. So much for reviewing routes.

Each resource can be assigned a destination (usually a factory). Choosing those locations is necessary for both the automated routing and as a first step in modifying a route. To modify an overseas route, which was a major complaint about CWIF, I’ll let the player set the departure port, the chain of sea areas, and the arrival port. Movement along rail hexsides is either possible or not possible. The actual hex path is irrelevant except when crossing straits, and crossing straits is done by first come, first served. If you want resource A to use a straits instead of resource B, then specify resource A’s destination first. Obviously, the default route for every resource will be the one it used in the previous turn.

It is likely to take me a couple of weeks to finish coding and debugging the Production Planning form. However, that will be time well spent, since getting Production Planning to work smoothly is crucial in my opinion.

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new. This is mostly done and just needs to be reviewed and updated once all the forms et al have been finalized.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
The MWIF fan site still looks good. Patrice and Rob (Warspite) have transferred more of the unit write ups to the fan site. Those include the counters. The way it works is that Andy has set up an animation that cycles through depicting all the units which have writeups in the fan site. Clicking on one of the images brings up the writeup.

Communications
Nothing especially new.

===

Just for chuckles, here are two examples of Changes Since files that I provide to the beta testers with each new release.

===
Changes Since Version 04.02.05
(as of July 4, 2010)


(1) Fixed a bug in the Flyouts form where if there were less than 10 units, clicking on the form header skipped to a blank page.

(2) Changed the GameSaveRestore code so when restoring a game during setup for a scenario that starts without a weather roll, the weather is Blizzard everywhere (Orm, 4.02.05, Post #7).

(3) Fixed a bug with refreshing detailed and global maps that was popping up in different places (Michael, 4.02.05, Post #5). Michael’s reported instance was for HQ reorganization but that had nothing to do with the problem. I couldn’t reproduce the bug but was able to figure out what was wrong from the emailed MadExcept report. Michael sent me two which looked different but the underlying problem was the same.

(4) Fixed the bug with convoy losses being calculated incorrectly (Lars, 4.02.05, Post #1; Michael, 2.00.01, Post #30; Grotius, 2.00.03, Post #40; Grotius, 1.01.01, Post #16).

(5) Fixed the bug with the reinforcement subphase Place Units on Map being skipped (Michael, 4.02.00, Post #30).

(6) Fixed a bug in the Selectable Units form where if you clicked to the right of displayed unit that was no longer on the map, the map centered on Greenland. It now displays an informative message. This can happen if an air unit had been removed from the map during the Air Removal subphase.

(7) Modified the code to make Chinese lend lease aircraft available at the start of the war from countries other than the US (Orm, 4.02.05, Post #6).

(8) Modified the icon for medium resolution naval transports so there is no longer a white triangle on the aft end.

(9) Fixed the colors for the medium resolution naval unit bitmaps (Orm, 4.02.04, Post #19).

(10) Fixed the bug with overrunning units using Ctrl Left Click (Peter, 4.02.04, Post #18). Previous bugs relating to overrunning units no longer exist (Peter, 1.00.09, Post #40; CSharpmao, 1.00.09, Post #103; Peter, 00.12.01, Post #4)

(11) Fixed a bug in the UnitsInHex form, where closing the program while it was active (and other conditions pertained) caused a MadExcept error (Christian, 4.01.07, Emailed MadExcept report).

(12) Checked the problem with Claiming Eastern Poland (German units forced to relocate) results in the game stopping when the USSR ends the phase (Eric, 1.01.07, Post #47). This no longer occurs.

(13) Fixed the problem with breaking down Nationalist and Communist Chinese units (Orm, 1.01.07, Post #3; Lars, 1.01.04, Post #4);

(14) Fixed a bug in Naval Interception Combat where units were shown as selectable even though they could not reach the sea area where the combat was taking place. Similarly, removed air units from the selectable units list that were not fighters and did not have air-to-sea factors.

(15) Removed an extraneous call to UpdateCursor which was causing a MadExcept error when moving naval units that could be intercepted. It also came up elsewhere (Michael, 4.02.04, Post #4).

(16) Fixed a bug which generated a MadExcept error when exiting a game during the Commit Subs subphase of a naval combat.

(17) Fixed the bugs with the naval air interception combat not advancing beyond the naval air support phases (GSB, 4.02.05, Post #13; GSB, 4.02.02, Post #10; GSB, 3.00.00, Post #53).

(18) Corrected the setup for Missed the Bus and the other later scenarios so the Bearn starts in the repair pool (Michael, 4.02.05, Post #14). I decided to have the Bearn come over to the US as a ‘conquered’ unit. This makes no difference in game play but the unit then is depicted on screen better.

(19) Fixed a bug in restoring games from before 4.02.00 (Nils, 4.02.05, Post #20).

(20) Changed the processing of Anti-aircraft fire so a bomber aborts when it has zero factors remaining (Michael, 4.02.05, Post #18). This change needs to be tested.

(21) Changed the SET file for Germany in Missed The Bus (received from Michael).

===
Changes Since Version 05.00.04
(as of July 20, 2010)


(1) Rewrote where the determination of fractional odds benefits occur in the land combat calculations for the CRT column shift (1D10) and die roll modifiers (2D10). I also reviewed the routine that presents those results to the player in the message panel and in the Land Combat Results form. The message presentation code was sloppy and duplicated some of the calculations needlessly, perhaps erroneously. The code is stronger now, in that I integrated the fractional odds calculations into the LandCombatColumn routine instead of having it external to that logic ().

(2) Added more text to RAC to explain how moving land units differs between WIF FE and MWIF (Csharpmao, 5.0.04, Post #2).

(3) Fixed a bug where the Hungarians were being permitted to fly a fighter as an interceptor during Ground Support when the Rumanians attacked an USSR unit and both the Germans and the USSR had flown bombers. Since the Hungarians do not cooperate with the Rumanians, this was illegal.

(4) Fixed a bug where a ground support bomber on the attacking side was considered capable of flying to an attacked hex if it cooperated with any of the units in the attack. It should only be permitted to fly to the attacked hex if it cooperates with all the attacking units.

(5) Corrected the determination of the number of major powers in a land attack. If you use an old saved game that restores in the Land Combat Declaration phase (or later), be aware that attacks that were declared before the game was saved are likely to have the number of major powers calculated incorrectly. Cancelling the attack and redeclaring it will fix that problem (Lars, 5.00.04, Post #1).

(6) Fixed the problem with the insert maps being out-of-sync with the main map. This problem would occur in a lot of forms, the land combat resolution form in particular (Nils, 5.00.04, Post #13; Grotius, 2.00.08, Post #31).

(7) Fixed the bug where extra partisans were appearing (Michael, 5.00.04, Post #11).

(8) Added another restraint to which units are selectable in the Retreat subphase, so only those that are being retreated are selectable (Nils, 5.00.04, Post #15).

(9) Made the AdvanceAfterCombat subphase another subphase that uses the Selectable Units form. This makes it easier to identify and locate the units that can advance after combat.

(10) Modified the Place Units debug form so more units are visible. I also added a large image depiction under the cursor.

(11) Added the capability to demand the return of lend leased aircraft (Frederyck, 2.00.04, Post #34; SJH, version 00.00.05.05). To do this you need to first select the leased air unit and an air unit in the same lend lease group that has been lent. Once the two units have been identified, and their group matches, clicking on the Demand Return button immediately returns the unit to the original source country’s force pool.

(12) Added a button to the restore game forms (opening splash screen and restore game from within an executing game) so that you can view the optional rules for a saved game before restoring it. This probably will not be used very often by players but should be a big help for beta testing - at least for me.

(13) Formalized when games can be saved (GSB, 2.01.04, Post #72; Michael Baldur, 1.01.01, Post #89; Orm, 1.01.07, Post #33; Sagji, 2.01.02, Post #54). This is most of the time with the following exceptions:
- when there are “units in hand” (there are units in the moving stack),
- during any digression,
- initiative phase,
- naval combat (A and D),
- ignore notional phase,
- final reorganization phase,
- minor support phase,
- surrender phase,
- conquest phase,
- while selecting units on which to expend reorganization points in the HQ reorganization phase,
- during lend lease of the setup phase (for either side),
- during setup reserves and aligning minors of the DOW phase,
- during air-to-air combat and air attack subphases of any air phase,
- during the subphases: use snow bonus (A and D), choose combat type, and combat resolution of the land combat resolution phase, and
- while saving build points during the production planning phase.

(14) Rewrote the code so the games saved automatically have file names that match the names of the phase and subphase during which they are saved.

(15) Added code to reset CanSave flag when a game is restored during air-to-air combat and the air attack subphases. It shouldn’t be possible to save a game during those subphases, but this change clears the flag just in case (Michael, 4.00.05, Post #18). Did the same thing for when the subphases of Setup, DOW, and LandCombatResolution where saving the game is not permitted. Likewise for saving build points and selecting units for HQ reorganization.

(16) Fixed a bug in scrap units that generated a MadExcept when units were scrapped.

(17) Fixed the bug where trying to save a scrap list, after restoring a saved game, caused a MadExcept (Nils, 5.00.03, Post #26).

(18) Changed ‘Pressto’ to “Press to” in the Setup Tray hint for armor (Eric, 5.00.04, Post #39).

(19) Inserted a check for an attempt to restore a game saved before Scrap Units was completed for a major power during setup. These games can not be restored and a warning message is displayed. The program (MWIF) has to be restarted (Alain, 5.00.03, emailed saved game; Paul, 5.00.02, Post #56).

(20) I gave up on restoring games prior to version 00.00.12.00. There is something wrong with the 11.xx and earlier saved games and while I was able fault isolate it, how to correct the bug would be more trouble that it is worth. All these games are prior to 2009 so they are very old. If you try to restore one of these games you will get a warning message, and MWIF will have to be restarted.

(21) Older games (e.g., version 2.00.03) that were saved during air-to-air combat are fatally flawed. If this holds true in the future, I’ll investigate further and try to fix the problem.

(22) I went through restoring over 150 games from Barbarossa. This spans virtually all versions from 00.12.00 through to the present. There were a couple damaged GAM files (incomplete) that I discarded. And there are 4 which failed to load that I might go back to analyze someday. But for the most part the save and restore games code appears to be working as desired. One problem I found was that after loading in 9 or 10 saved games in a row the program fails to load a game because of bitmap memory problems. If you see a fatal error when restoring a saved game that says it can’t load a bitmap (BMP) then that is what has happened. This means there is a memory leak in the code: bitmaps are being created but they aren’t being released when a game is ended and a new one begun. Eventually the unreleased bitmaps build up and there are insufficient resources to load a game. I tracked down this problem before about a year ago and will go through that process again (someday). For now it is annoying but fixing it is not crucial for beta testing (Nils, 1.01.01, Post #105; ).


Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

September 1, 2010 Status Report for Matrix Games’ MWIF Forum


Accomplishments of August 2010

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

I put in 8-10 hours a day on this, every day. That works out to 250+ hours a month. This past month has been rather stressful because they started resurfacing a parking garage across the street. It has two levels and in late July they started working on the top deck, attacking it with jackhammers for about 6 hours a day 4 days a week. They hammer on the concrete until they have broken through completely and only the lattice of exposed steel rebar remains. The crew is 6 guys with jackhammers plus a guy sweeping up. The lower parking area serves as a sounding board for the 6 jackhammers so the noise level is deafening. Even with all my windows closed and cotton in my ears, the noise was insanely loud. After a couple of weeks I bought ear protection muffs comparable to what the workmen are using. That reduced the sound at the higher and middle frequencies to negligible but the lower levels still make my teeth vibrate. On several occasions I have simply fled my house and home for 2 or 3 hours to quiet my nerves. I estimate that they are about 2/3rds done after 5 weeks of work. Today is a ‘quiet’ day for the workmen (they are cutting rebar with acetylene torches) and I feel quasi-euphoric at how quiet things are - there’s just the normal traffic noises from the two main streets, 5 lanes wide, outside my condominium and the 8 lane dual highway a block away.

Hardware and Software
Theme Engine is still disabled. I never use the Delphi 2010 IDE debugger.

Beta Testing
I released versions 5.01.04 (36 fixes - 7 done in July), 5.01.05 (22 fixes), 5.01.06 (14 fixes), 5.02.00 (30 fixes), and 5.02.01 (20 fixes) to the beta testers last month. This totals 5 new versions and 115 fixes which is less than the 8 new versions and 122 fixes last month. The main reason for the decrease in both is that I spent a lot of time revising the Land Combat Resolution and Production Planning forms. More on that below. For those keeping track of this stuff, there was no version 5.01.03 because I ‘used’ that version number during alpha testing by revising the saved game format twice.

Fatal errors still occur, but most of the ones I receive from the beta testers are duplicates and (net) there are only 1 or 2 new ones per release. Typically, I fix those in less than 10 minutes. Most of the bug reports concern fine details of the game, for instance, the land combat calculations dominated the bug reports this month. More on that below.

Saved Games
The changes I made to how the trade agreement commitments are enforced required changing the saved game format several times. This was the main reason I released the new full version 5.02.00. Each executable version is now ~300 MB and that is without any saved games. Since saved games are essential for the interactive tutorials and providing the players with a “quick start” for each scenario, the released product should be close to 350 MB (compressed), plus the training videos (~1.3 GB).

Map and Units
Rob sent me updates of the naval unit writeups. Patrice sent me some minor changes to the map data.

Scenarios and Optional Rules
Nothing new.

MWIF Game Engine and CWIF Conversion
Improved the activity limits display for the Communist Chinese. Recent rules changes/clarifications by ADG mean that the Communist Chinese activity limits are a function of the Chinese and USSR action choices and activity limits. In particular, the use of a Chinese Offensive chit on Mao is a special case in the rules. When making action choices, the Allied player can now see what effect that has on the Communist Chinese units. There were over 50 places in the code where modifications were necessary to get this to work according to the rules changes.

Reviewed and cleaned up the code for building supply units. This type of unit has to be built using only oil points so it is a little tricky, what with having to convert oil/production points to built points and maintaining a running count of how many supply units have been built during the current turn. The CWIF code was about 80% unnecessary, so I removed that portion.

All the work on the Production Planning form (see below) caused me to find and fix some small bugs in the Use Oil (to reorganize units) form. These two forms are tightly interconnected since they concern the two choices for using oil points.

Player Interface
Revised the status indicators for the units to better explain their involvement in land and naval combat. For instance, when an engineer is providing his benefits to an attack, his attack indicator is now bright green, instead of the normal red for an attacking land unit.

I made substantial changes to the Land Combat resolution form. The beta testers have been after me for years to provide more information on the die roll modifiers and the column shifts. Doing so was non-trivial. There are dozens of die roll modifiers and a dozen column shifts possible. Because this form was already crowded with information, fitting in the additional details required spending time counting pixels. The form now shows:
• the list of combats to be resolved,
• an insert map to ‘see’ each combat,
• a short list depicting the defending units,
• a very long list depicting the attacking units,
• a unit data panel to see detailed information on and individual attacking/defending unit,
• a subphase strip which shows the subphases in resolving a land combat and the current subphase for the combat being resolved,
• a dozen buttons for making decisions and getting help,
• 3 medium sized panels for reporting die roll results and instructing the players to choose units to destroy/disorganize, and
• [new addition] two panels for showing details on the calculation of die roll modifiers and column shifts.

To achieve this I had to make mostly ‘net’ entries. So instead of all the plus and minus changes to the die roll due to armor and antitank units, there is just a “net armor” die roll modifier. Even so, there are 10 separate entries for the 2D10 CRT die roll modifiers and 5 entries for 1D10 CRT column shifts. The presentation of this additional information has enabled the beta testers to test land combats more minutely, and they have found several bugs - some real, some cosmetic. Oh, and all this additional information needed to be written out to the Game Record Log so it could be distributed to other players during Internet play.

I made massive changes to the Production Planning form. It now includes the option to toggle between the detailed and global maps for the form’s insert map. This is crucial for players using one monitor since they need to be able to see where the used and unused convoys are when reviewing and modifying convoy routes. The insert map’s version of the global map doesn’t have all the capabilities of the game’s full global map, since it is focuses on production exclusively. That is actually a benefit since it both removes clutter and always displays information relevant to production decisions.

Rather than create the ability for the players to sort their list of resources and factories, I created a panel of 8 filters that let the player reduce the view to a subset of all he controls: factories, resources, oil, non-oil, saved, trade, overseas, and idle. These roughly correspond to the information in the form’s summary panel. So, if you want to understand the counts in the summary panel for ‘sent’ and ‘received’, clicking on the Trade filter displays those specific resources.

I replaced several stand alone buttons for switching views with a set of radio buttons so the player can choose which of 4 Production Planning form layouts to use: Summary, Expanded, Routes, or Defaults. The first shows how many factories and resources you have and how they are converted into build points. The second removes the summary information to make room for twice as many entries detailing individual resources/factories. The last two are new, described immediately below.

I created a new element to the Production planning for that displays the route taken by resources to their destinations. If it is entirely by rail, then each hex is shown. If it goes overseas, then the only land hexes shown are the departure port, arrival port, plus the origination and destination hexes. Each sea area is also shown. This route can be animated, with the detailed map recentering on each hex in the route in turn with a half second delay. You can also simply click on each hex in the listed route to have the map center on the hex. This lets you see exactly how the resources in Siberia reach factories east of the Urals. To complement this, I added a column to the master list of resources controlled by a player to display the number of convoys used to get a resource to its destination. Still to do on this is to enable ‘seeing’ a single overseas route on the global map.

I created a second new element for the Production Planning form so the player can review and modify: (1) default resources to be used to fulfill trade agreements and (2) default uses and destinations for all resources the player controls. Sometimes a disruption in a convoy route (e.g., enemy subs sink a bunch of convoys) can prevent a resource from reaching its intended destination. In those cases the “previous turn’s” values for resources will be: Idle and No Destination. However, the program will try to use the default settings every turn, so if you can reestablish your convoy pipelines, the program will once again send your resources to their ‘normal’ destinations without you having to do recreate everything.

Here are some gory details on default settings, which will be included in the Players Manual. This level of analysis is required before writing the code.

---
I defined 4 variables as a set for fulfilling trade agreements: country, action, factory, and destination.

The relationship between the variables is that every resource has a Country defined, if it is being used to fulfill a trade agreement. Country is the receiving country. Obviously, whichever major power controls the resource is the sending country. The major power that controls the resource can define its Default Country (or set it to None). The receiving major power can define the Default Action (use) for the resource, though there are only two from which to choose: production and save. Only oil and build points can be saved and even that is only possible when the optional rule to do so is On. The receiving major power can set the Default Factory for resources that have an action of Production, and a valid Destination for oil/build points that have an action of Save. Note that the value for Action determines whether Factory or Destination are instantiated. That is, if the Action is Production, then Factory may have (does not have to) a valid entry and the value for Destination is irrelevant. Similarly, if Action is Save, then Destination may have (does not have to) a valid entry and the value for Factory is irrelevant.

There are 3 sets of these four variables: Current, Default, and Last turn's. The program tries to fulfill each trade agreement using the defaults if that is possible. Then the program tries to use the set from the last turn to fulfill any unsatisfied commitments. Only if both of those fail, does the program try to find some other way to fulfill the trade commitments. If a trade commitment can not be fulfilled, then the program "sets aside" a resource (or build point) so it is not available to the owner, even though it can not be delivered to the intended recipient.

There are two passes through these 3 sets, the first is for rail only. So, in summary, the process is:
1. Default by Rail?
2. Last turn by Rail?
3. Any by Rail?
4. Default Overseas?
5. Last turn Overseas?
6. Any Overseas?
7. Set aside.

This design lets the source country choose which resources to use to fulfill its trade agreements. The receiving country gets to decide where the resource arrives and what is done with it. This information is only used for trade agreements between major powers. Most of the time, accepting the automated decisions by the program will work fine. For example, who cares which 7 USSR resources are used to fulfill the Nazi-Soviet pact, since they are all sent by rail? It is for the Allied side's trade agreements where this design is most helpful. That's because almost all of their trade agreements require overseas shipments.
---

Right now I am halfway through enabling the player to change the uses and destinations of resources he controls. Primarily, players want to designate oil points to be saved and modify convoy routes. But there are a lot of tricky bits.

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
I began adding text to reflect the changes to the Production Planning form.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
The MWIF fan site still looks good.

Communications
Nothing especially new.

Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

October 1, 2010 Status Report for Matrix Games’ MWIF Forum


Accomplishments of September 2010

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Hardware and Software
Theme Engine is still disabled, but I have hopes of reinstalling it this month.

Beta Testing
I released versions 5.02.02 (12 fixes), 5.02.03 (7 fixes), 5.02.04 (14 fixes), 5.02.05 (20 fixes), 5.02.06 (17 fixes), 5.03.00 (23 fixes), and 5.03.01 (9 fixes) to the beta testers last month. This totals 7 new versions and 102 fixes which is under my previous 2 month averages for fixes (116).

Fatal errors continue to decrease in frequency and I can usually fix them in a few minutes. Most of the bug reports this month concerned Production Planning which I had completely revised and whose player interface details needed both debugging and refinement.

Saved Games
Saving and restoring games is stable although I continue to make revisions to the format from time to time. With a little care, I keep old save games playable. But I am not anal about that. Sometimes there were bugs which caused GAM files to be fatally flawed. I do not spend time trying to make old GAM files playable - just as long as the newly created GAM files restore perfectly.

Map and Units
Rob sent me updates of the naval unit writeups. Patrice sent me some minor changes to the map data.

I enabled moving from Colon (at one end of the Panama Canal) through the Panama Canal and into the Gulf of Panama. This works the same as for Panama City at the other end of the Panama Canal.

Units can now set up in Eritrea. The WIF FE setup booklet didn’t specify that, but Patrice checked with Harry Rowland, and MWIF conforms to Harry’s clarification.

Scenarios and Optional Rules
Added code to restrict how many saved build points in each hex can be used. CWIF didn’t worry about this but I want MWIF to follow WIF FE as closely as possible.

I wrote the code for Food in Flames. It remains to be tested, but was fairly straightforward.

I made some changes in how the specialized subs in Convoys in Flames are handled. In particular, Milchcow subs are now restricted to the zero section box. I have occasionally done bits and pieces of the rules for Convoys in Flames, when I see something that is wrong and easy to fix. There is still a bunch of work to do (e.g., add another subphase to naval submarine combat), so I have not yet reached the point where I can sit down and finish it in a couple of days.

I linked the use of the optional rules Synthetic Oil Plants and Factory Construction & Destruction. WIF FE, as written, requires both of these to be in effect before oil resources can be destroyed by strategic bombing. This is another case of bringing MWIF into line with WIF FE, where CWIF deviated slightly.

I finalized the design for Unlimited Breakdown, with the help of the beta testers (especially Paul). At the end of this report is the section from the Players Manual describing this new optional rule.

MWIF Game Engine and CWIF Conversion
Nothing new on the game engine. As for CWIF conversion I have now converted all the forms except Overstacking. I’ve made a tentative pass at that but I want to see more bugs resolved before messing around with something that pops up at odd places in the sequence of play. MWIF handles resolving overstacking as a digression.

Player Interface
I created a new form for debugging naval moves. It lists all the sea areas and ports to which a selected group of naval units can move, showing how many movement points each move uses. If is astonishing how many ports are available. For instance, a Japanese unit could only move to 8 sea areas, but has over 50 possible ports available! This will not be part of the released product because it is rather crude.

I made more massive changes to the Production Planning form. For the summary panel, I added hints and filters for each of the 35 statistics. The hints help to explain what the numbers mean. Then when you actually click on a number in the summary panel, the list of resources and factories is filtered to show the resources that make up that number. For instance, if you click on non-oil trade received, just the non-oil resources that are being sent to the current major power are listed. This works for Idle Factories, Convoyed Oil, and all the other statistics too. The code uses the same filter for calculating the numbers and for modifying the list of resources and factories displayed. That was very useful for development/debugging and has the added benefit of being useful to the players. I also added entries to the summary panel for production points received through Food in Flames and for convoys on map and idle. When convoys idle are zero, it is a good idea to build more convoys.

I reduced the number of layouts for the Production Planning form from 4 to 3: Summary, Expanded, and Route. The 4th layout, for Default and Override values, is now incorporated as a standard part of the form and is visible in all 3 of the layouts.

I added the ability to display the overseas route for a single resource on the global map. This lets you go through each of your resources that are using convoys and see the route it is using. Conversely, you can click on a sea area and have the resource list filtered to show the resources that are routed through the sea area. Sometimes major powers use convoys belonging to their allies. To identify those situations, when clicking on a sea area is used to filter the resources, whose convoy the resource is using is also shown. The general thrust of the design for production planning is to let you see both summary and detailed information on resources, factories, and convoys. The filters let you focus on subsets of them. These changes enabled me to delete the old CWIF Convoy Info form.

I streamlined the process of modifying routes for resources shipped overseas. The way it works is you select a resource, select its destination, and click on the series of sea areas in the route you want the resource to use. When necessary, the program finds a departure port and a rail link from the resource to the port. Likewise, when you reach the last sea area in the pipeline, you just click on it a second time (to indicate it is the terminus) and the program finds an arrival port and a rail link to the destination. This is very fast to do and I can reroute all the Commonwealth resources from scratch in less than 5 minutes.

The program stores player specified routes as either Default or Override. Defaults are what you use most of the time; they are saved from turn to turn for automatic reuse. Override routes are for when you want to make a change for just the current turn. They take precedence over the default settings. After the turn is over, override routes are deleted, while the default routes remain available for the next turn. All routes are shown both as table entries and also on the global map, which makes reviewing them easy to do.

Internet - NetPlay
My redesign of the SOP in 2007 added a Game Record Log where all the transformations of the game state are recorded as a series of encoded entries. These are used by both PBEM and NetPlay to keep all computers up-to-date with changes to the game state. They are currently used for Solitaire and Head-to-head play, but 110 record types still need to be converted from CWIF Windows messaging code to MWIF Game Record Log code. By the way, the total number of unique record types is ~550.

PBEM
I reviewed the 20 forms needed for entering the 22 PBEM Standing Orders. Forms for 4 of the standing orders are done, 6 have been started and 12 have only dummy stub ends in place. I remain focused on fixing bugs, but PBEM is next on my task list once I get the bugs beaten into submission.

Artificial Intelligence (AI)
The AIO decisions are primarily made using scripts written in LAIO (Language for Artificial Intelligence Opponent). This is a rule based language which I created for MWIF. LAIO is fully defined and dozens of test scripts have been written by Peter Skoglund, with help from me.

The test scripts are for setting up units for each of the minor countries in the game, from a single unit for Persia to the more complex setups for Poland, Spain, and Turkey. Peter has also created a script for setting up France in the Global War scenario. These scripts are quite sophisticated, taking into consideration which major power declared war on the minor country, the type and location of enemy units, and possible support from allies. For instance, the script for setting up the single Persian unit has logic for threats from land, air (e.g., paradrops), and sea (e.g., amphibious assaults) from all directions.

To convert the LAIO scripts into actions to be taken by MWIF, (on behalf of the AIO), requires a parser. The parser reads a script and generates a set of commands comparable to what a human player enters using the mouse and keyboard. I’ve written about 80% of the parser code, and debugged that much using the scripts created by Peter. I need to finish the last 20%, but more importantly, I need to have the parser ‘recognize’ ~300 function calls. For example, when a script references a unit’s type, the parser has to ‘fetch’ the unit type datum which is stored internally. There are numerous characteristics of units, unit stacks, hexes, and countries which the program already stores internally. For each of them, LAIO needs a symbol/string defined and the parser needs to translate the symbol, when it occurs in a script, into a function that returns the internal value.

There are 143 decision points in the sequence of play where the AIO needs to decide what to do. 122 of these use universal logic, in that they do not depend on which major power is making the decision (e.g., rail moves, strategic bombing, naval interceptions, placing partisans). For the other 21, the logic does depend on which major power is making the decision. Examples of those are: strategic plans, declarations of war, production plans, and trade agreements. I have 200 pages of text describing strategic plans. Each major power has their own section and the plans are well organized. For the French, I’ve started encoding their strategic plan as data.

The AIO makes decisions using either LAIO scripts (preferred) or by using a routine hard coded in Pascal, but data driven. Which is used depends on the expediency of writing the code. For example, there are a lot of unique decisions that do not deserve spending the time to write a LAIO script. USSR territorial claims, US entry option choices, and routing resources to factories can be handled better by Pascal code than by LAIO code. On the other hand, moving units and deciding about attacks are best done using a LAIO script. That way we can add and remove portions of a script while MWIF is executing and immediately test the effect of the changes. MWIF can parse a revised script “on the fly”, which isn’t possible for Pascal code.

For the 122 ‘universal’ decision points, I start by writing plain text that describes how the decision is to be made. I’ve done 73 of them as plain text so far. The second step is to translate the plain text into a LAIO script. All of that work remains to be done.

Once all 143 decision points have either Pascal code or a LAIO script, the AIO can execute autonomously. In practice, we will introduce the AIO decisions one at a time, evaluating how good each decision is and modifying the script/code until we are happy with it.

Player’s Manual
I finished the text for the Production Planning form. It runs to 12 pages. Here is the opening paragraph:

The Production Planning form enables you to:
• review resources, factories, and convoy pipelines,
• review the build points available for production,
• choose resource destinations.
• modify convoy pipelines,
• decide whether oil resources/points are to be used in production or saved, and
• choose which resources fulfill trade agreements.

To accomplish this the form has 3 layouts and dozens of filters. Key elements of the form are:
• A list of resources and factories belonging to a selected major power.
• Major power flags to change the selected major power.
• A Summary layout which shows statistics on resources, factories, and production and build points.
• An Expanded layout which doubles the viewing area for the list of resources and factories.
• A Route layout, which shows the hex by hex route for a resource from its hex of origination to its destination.
• An insert map, detailed or global. Both maps display the location of resources and factories. The global map can be used to review and modify convoy routes.
• Filters for displaying a subset of the resources and factories (e.g., those that are idle, traded, or use convoys).
• A default/override table for reviewing the current default/override destinations and actions (i.e., production or saved) for a resource. This table can be used to specify the default trade country for a resource.
• Radio buttons for selecting the default/override destinations and actions for resources.

The current PDF of the draft Players Manual is 368 pages long.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
The MWIF fan site still looks good.

Communications
Nothing especially new.

=====================================

9.3.8 Unlimited Breakdown
This optional rule modifies the restrictions on: (1) breaking down corps/army sized units into divisions, and (2) reforming corps/armies from divisions. When this optional rule is in effect, rather than use the division units in the counter mix for breaking down divisions, 2 new division units are created (out of thin air) when a player breaks down a corps/army unit.

This rule only applies to the major powers. Minor countries, even those that have a division unit as part of their force pools, are still unable to break down corps/army units into divisions or reform divisions into corps/armies (as is the case in WIF FE). During the Breakdown phase you can break down into divisions an on-map, organized corps or army unit that isn't in an enemy ZOC. Only the following unit types can break down into divisions:
• Infantry,
• Cavalry,
• Paratroop,
• Marine,
• Mountain,
• Armor,
• Mechanized, and
• Motorized.

Division Unit Types
When a corps/army is broken down using the optional rule Unlimited Breakdown, two (brand new) division sized units replace the corps/army unit (the parent unit). The 1st division is of the same type as the parent and the 2nd is either an infantry or motorized division (the owning player chooses).

Combat Factors
The sum of the combat factors of the two divisions is half the combat factors of the parent, rounding up. For example, a 4 strength parent unit breaks down into two divisions with combat factors of 1 each. A parent 5 breaks down into a 1 and a 2; a parent 6 breaks down into a 1 and a 2; and a parent 7 breaks down into a 2 and a 2. When one division has more combat factors, then it is the 1st division that gets the extra combat factor.

Movement Factors
The 1st division has the same movement factors as the parent.

The 2nd division’s movement factors are the same as its parent’s, with the following modifications:
• When the 2nd division is infantry:
• if the parent is INF, PARA, MAR, or MTN, same as parent.
• if the parent is MOT or CAV, same as parent, minus one.
• if the parent is MECH or ARM, same parent, minus two, but never less than 3.
• When the 2nd division is motorized:
• If the parent is INF, PARA, MAR, or MTN, same as parent, plus one.
• If the parent is MOT or CAV, same as parent.
• If the parent is MECH or ARM, same as parent, minus one, but never less than 4.

When a corps or army unit is broken down, it is not returned to the force pool (as it would be under the standard rules for breaking down units). Instead, it is placed in a separate pool, called the "BreakDown Pool". MWIF maintains a record of which divisions were created when a corps/army was broken down and will not reform the corps/army unless two identical divisions are used. They do not have to be the same divisions, just identical in type and combat factors (i.e., a 1-4 infantry is a 1-4 infantry is a 1-4 infantry).

When destroyed, divisions created by breaking down corps/armies are placed in the BreakDown Pool. Divisions that are part of the standard counter mix, and therefore either part of setup or built by the player using the normal production rules, are returned to the force pool when destroyed.

Reforming a Corps/Army from Divisions
Players can only reform corps/armies that are in the BreakDown Pool. This is a major change from the standard rules where you can reform on-map divisions into corps/armies that are drawn from the Force Pool. Units in the BreakDown Pool remain there until either: (a) they are selected as the corps/army to replace 2 division units that are reformed into a corps/army, or (b) 2 division units that were created when a corps was placed in the BreakDown Pool are destroyed. You can basically think of the later situation as the two destroyed division units reforming as a corps sized unit that is then returned to the force pool. Units in the BreakDown Pool can never be built during the Production phase while they reside there! To avoid misuse of this rule by players, if two divisions in the BreakDown Pool can be reformed into one of the corps/armies in the BreakDown Pool, they the player must do so. However, he has the choice of which corps/army is reformed. This mandatory reformation occurs during the BreakDown phase.

Because MWIF has a record of which divisions were created when a crops/army was broken down, it permits a player to reform the exact same corps/army from those divisions (or identical divisions). This is a pleasant change from the standard rules because it lets players who reform corps/armies get the exact same unit back that they had originally broken down. Under the standard rules, the process of breaking a corps/army down and later reforming it can generate a weaker corps/army than the player had at the start.

So, here is the revised rule on reforming divisions into a corps/army:

• If, during the reform phase, 2 organized divisions are stacked together on map, not in enemy ZOCs, and their factors match the factors of the original divisions that were created from a corps/army in the BreakDown Pool, the player can reform them into that corps/army.

• If more than one corps/army in the BreakDown Pool satisfies this criteria, the player gets to choose which one is reformed.

• Divisions in the BreakDown Pool can also be reformed, with the same restrictions as for on-map divisions. Indeed, they must be reformed during the BreakDown phase.

Effects on Game Play
One effect of this optional rule is that the division units included in the counter mix are only available to the player: (1) by building them or (2) when specified as part of a scenario’s setup. They are never used when units are broken down into divisions nor can they be used to reform corps/armies. Indeed, when a division unit from the counter mix is destroyed, it is treated differently from one created through breakdown. Those from the counter mix go back into the force pools, while those divisions created when a corps/army is broken down go into the BreakDown Pool when they are destroyed. Whenever divisions are used to reform a corps/army, the divisions are removed from the game.

However, for all other game play purposes there is no difference between the division units from the counter mix and those created when a corps/army is broken down into divisions.

The effect this rule has on play balance is uncertain and controversial. On the one hand it removes a somewhat artificial restriction on breaking down units that was imposed by the counter sheet limitations of WIF FE. On the other hand, it enables the Japanese player, for example, to generate a lot of divisions, place them on SCS units and invade numerous islands and other hexes in the Pacific simultaneously. Note that doing so makes the total strength of the Japanese army units much less, but that is only temporary, until they can be reformed back into corps/armies.

This change also enables the major powers to use divisions more readily for taking casualties during land combat. But that applies to all the major powers, both on offense and defense. Again, breaking down corps/armies will reduce the total combat strength of the forces in the front lines. And one last use for this increase in the number of divisions is the opportunity to hold individual hexes with less expensive division units. This can be of use to Germany in Norway, and Japan for holding islands in the Pacific, as just 2 examples. It also has potential for helping to defend the somewhat porous front line and exposed supply lines in China.
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

November 1, 2010 Status Report for Matrix Games’ MWIF Forum

Accomplishments of October 2010


Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

I have attached a JPG of the current version of the spreadsheet I created to visually track what has been done and what needs to be done. When I get all (or most of) the pale blue items transformed into dark green, I will return to working on more interesting things: new code for optional rules, PBEM, NetPlay, and AIO. If you want to know why MWIF has taken so long, count the number of dark green cells.

Hardware and Software
I reinstalled Theme Engine, which appears to be functioning correctly. When I first upgraded Theme Engine for Win7, it was a disaster. It added bitmap graphics to every button so they could be animated. Because MWIF is close to tapping out Windows graphics resources, the addition of thousands of new bitmaps for buttons caused out-of-memory errors at random places in the code. That was when I was lucky enough to get an out-of-memory error instead of some other mysterious program crash. The reason it works now is because I removed all (over 1000) TTeButtons in MWIF and replaced them with TTeSpeedButtons, which do not have animation capabilities (i.e., no bitmaps).

In the process of getting MWIF to work with Win7 I replaced all the assembler code with Pascal code (I did that back in the spring). That took some time and had to be done very carefully. My motivation for making that conversion was the number of anomalous crashes I saw that pointed to the failure occurring in the assembler code. I don’t see those crashes any more, though I can’t be certain that the assembler code was entirely to blame. On the other hand, I still don’t see those crashes after having reinstalled Theme Engine - pointing the finger of guilt more ominously at the removed assembler code.

After reinstalling Theme Engine I recompiled the MWIF custom library routines to make sure they used the most recent Theme Engine object modules.

I still need to convert the main menu and popup unit menu from standard Windows style to Theme Engine.

Beta Testing
I released versions 5.03.02 (22 fixes), 5.03.03 (27 fixes), 5.03.04 (19 fixes), 6.00.00 (26 fixes), and 6.00.01 (22 fixes), to the beta testers last month. The change in numbering from the 5.xx to 6.xx numbering was because of the reinstallation of Theme Engine. This totals 5 new versions and 116 fixes, which is slightly over my previous 3 month average for fixes (111).

Besides the normal wide range of bug reports, I spent significant time improving the Production Planning form. As the beta testers hammered on it, more flaws in the code were revealed. In particular, keeping all the pieces of the form synchronized was difficult (e.g., the resource list, the filters, the route table, the default settings table, the maps, and the various radio button group boxes). Its looking solid now but I still have a bunch of mostly minor complaints from the beta testers to investigate.

This month I went through a lot of old bug reports, tracking down all the pieces related to them and trying to reproduce them. There can be 3 pieces: a post by a beta tester, an emailed MadExcept report from the beta tester, and a saved game received a beta tester. I keep a master file of bug reports and tying all three of these inputs together isn’t always easy. My reward for this housework was the elimination of ~20 bug reports that were no longer valid (they had been fixed at some time over the past year).

Fatal errors occur occasionally, but I can fix them quickly.

Saved Games
Saving and restoring games is stable though I continue to make revisions to the format from time to time. Old saved games can still be restored going back to version 0.0.12.00.

Map and Units
Rob sent me updates of the naval unit writeups. Patrice sent me some minor changes to the unit data (to correct the spelling of Italian ship names).

Scenarios and Optional Rules
Added code to impose limits on the number of saved build points that can be used from a hex. This is a rare rule but it can be important when Murmansk gets cut off from the rest of the USSR. CWIF did not impose any limit; but MWIF now conforms to RAW. Corrected CWIF code for tracking whether a neutral major power can save an oil point. To do this I needed to create a new variable to be written out to the saved game. The rule the program enforces is that a neutral major power (e.g., the USA and the USSR) can only save one additional/new oil point per turn.

Starting writing code for the USSR-Japan Compulsory Peace optional rule. The program now identifies when the players can invoke that rule. Implementing it (changing hex control and forcibly relocating units) still needs to be coded.

MWIF Game Engine and CWIF Conversion
I updated some CWIF code concerning US Entry Options. That code appears to have been written for an older version of the rules. I reviewed the code for all those rules since I had found some that were obsolete.

I standardize the Weather phase so it has its own module. Only the Setup phase is scattered about in several different modules, with the logic flow non-standard (as inherited from CWIF). All the other 59 phases of the game have their own modules. However, there are two new phases to be added to the sequence of play - discussed next.

Having gotten Production Planning running smoothly, I discovered that finalizing those decisions before the phases for units staying at sea/returning to base presented problems. According to RAW, players should be able to make adjustments after the latter phases have occurred. Furthermore, I found the CWIF had no code for enabling players to effect Search and Seizure. After a short discussion with the beta testers, I decided on adding two more phases to the sequence of play. The new sequence of play is:
.
.
• Preliminary Production Planning
• Stay At Sea A
• Stay At Sea D
• Return To Base A
• Return To Base D
• Use Oil
• Final Reorganization
• Break Down
• Final Production Planning (new)
• Search and Seizure (new)
• Naval Repair
• Production
.
.

From a programming point of view there is no difference between the two production planning phases. We wanted to give the players an opportunity to plan their use of resources (e.g., oil) and routes to destinations before making the decisions about units staying at sea or returning to base. The second production planning phase let’s the player make adjustments after perhaps losing convoys that got tangled up in naval combats during the return to base phases. Most of the time, the players will have nothing to do in the second production planning phase and will just click on Ok - Done.

Search and Seizure, according to RAW, occurs during the Production Phase. In reality it occurs before production decisions are made, since events during Search and Seizure can reduce the number of build points available for production. Therefore, I have made it a separate phase - of its very own. By the way, the Naval Repair phase occurs only when playing the Guadalcanal scenario and takes the place of the Production phase.

Player Interface
I added code to track from which carrier a carrier air unit originates when it flies an air mission to a land hex (e.g., a ground strike). When one of these units is aborted, the program returns it to its carrier of origination automatically - which saves the player the trouble of figuring it out. Because a carrier can not be damaged when one of its carrier air units flies those missions, making the return automatic is ok. During naval air combat making the return automatic isn’t possible; since the carrier might have been destroyed in the combat.

Modified the Player Interface Settings so players can elect to skip the Peace phase every turn. According to RAW, a player may sue for peace at the end of each turn. I’ve never heard of someone doing such a thing, but the rules say it should be permitted. Therefore I have added a mandatory phase to ask each major power that is at war whether they want to sue for peace. That will get very tedious very quickly. Hence the new player interface setting for skipping the phase/question. Since I was making changes to this anyway, I merged two separate forms (Disable CAP Phases and Disable Phases) so all three settings concerning disabling phases appear on a single form.

I streamlined the process of loading units from coastal hexes by eliminating a form. This had always bothered me (as a player) and when a beta tester reported some bugs with how it executed, I took the opportunity to rewrite (and simply) the code.

Added a button to the Setup Tray so a player can see his reserves with a single mouse click. This is useful when setting up Germany and France, where holes are often left in the front line - to be filled by reserves when they arrive in the second impulse. Obviously this is a minor issue but it only took 20 minutes to code and test.

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
I updated the Rules as Coded PDF, which is now on version #35. These were clarifications for: Colon’s access to the Gulf of Panama, US Entry options, and that MWIF has the Commonwealth occupy the Faeroes Islands at the start of some scenarios. Those islands aren’t shown on the WIF FE maps, so we based this decision on the historical occupation.

I revised the text for the Production Planning form based on small changes to how that form looks and is used. Having reinstalled Theme Engine I retook several dozen screen shots of forms that have changed over the last 6 months. After some minor editing for the changes for Disabled phases, and descriptions of modified forms, the current PDF of the draft Players Manual is now 363 pages long. That includes screenshots for all the sections; I threw in a screenshot at the beginning of a few sections which had been pure text.

Tutorials, Training Videos, and Context Sensitive Help
I took the changes I made to the Players Manual and converted the text into help messages that can be called up during game play. This mostly concerned Production Planning, which is a dozen pages in the Players Manual. That text is available with the click of the Help button on the Production planning form. That’s very useful because that form has a lot of moving parts and how to use them all isn’t intuitively obvious to the casual observer.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
The MWIF fan site still looks very good.

Andy Johnson (who did the work to develop the MWIF fan site from nothing) has health problems and is unable to continue maintaining it. We are looking for someone to volunteer to take it over. The site is not part of Matrix Games, but some of the material on the site is copyrighted by Matrix Games and/or Australian Design Group, so there are restrictions on what can be shown and made available to the general public.

Communications
Nothing new (that can be reported).


Image
Attachments
StatusRep..112010.jpg
StatusRep..112010.jpg (970.86 KiB) Viewed 19729 times
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

December 1, 2010 Status Report for Matrix Games’ MWIF Forum

Accomplishments of November 2010
Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Programmer Dreams
I had a dream this past month which you may find amusing. Since the dream is all about programming MWIF, you can take it as my subconscious’ report for the year-to-date. Skip to the section on Hardware and Software if this holds zero interest for you. As background, I used to play golf 3 days a week before starting work on MWIF, but over the past 4 years I have only played twice. I had a 6 handicap so I usually shot in the 70's. Because I played on public golf courses, it was very important to not dawdle and always keep up with the group playing in front of us. This short story is as accurate a remembrance of my dream as I can recall.

The dream started with me arriving at the golf course early in the morning, and being in the first foursome to tee off that day. I didn’t know anyone else in my group, but that was common even when I was playing 3 days a week. The other guys hit their drives and then I was on the tee. I knew I would be rusty and that was confirmed when I hit a couple of drives off into the trees on the left. After giving myself two Mulligans (pretending my first two swings never happened), I decided to go with my 7 iron off the tee - the club with which I am most comfortable and therefore the most reliable. I hit a very good 7 iron shot down the middle of the fairway. Once the other guys had hit their second shots, I needed to choose a club for my second shot. The hole was a short par 4 and I had a good chance of reaching the green, although the fairway was very narrow with trees lining both sides. But I wasn’t sure of the distance to the green so I went looking for a yardage marker. That took a while since I had never played the course before and the other guys couldn’t locate a yardage marker either. I finally found a sprinkler head with 200 yards printed on it and by pacing off the distance from there to my ball I figured I had 190 yards to the hole. That’s usually a 4 iron for me, but being rusty I decided on a 3 iron.

However, when I looked in my bag there were all these extra clubs. It seemed I had put in both my old and new sets of irons, so I had two of everything. Even worse, one of the other guys in my foursome had put most of his clubs in my bag, so I was carrying about 30 clubs instead of 14. I asked the other guy what he thought he was doing, and he said that since I had such a nice new bag with extra room, I could carry his clubs, since his golf bag was old and worn. I argued with him for a while but eventually took out my new 3 iron and walked ahead of my ball to see exactly in which direction I wanted to hit it. The green was slightly off to the right so I planned for my shot to go down the right side of the fairway. Of course when I went back to my ball, I couldn’t find it.

My father showed up then. He was playing in the following foursome and we let his group “play through” since we couldn’t find my golf ball (my father always thought I did things too slowly). Then a foursome of ladies came up and they helped us look for my ball. They belonged to the Sweet Adelines (women’s barbershop quartets) and at some point they were singing. One of them asked if I was playing a Napoleon golf ball and I said, maybe (my ball had NAP printed on it). But what she had found was a rather small cardboard box and when I opened it, inside was a shoe with the brand name Napoleon on it. I then decided to look for the yardage marker again, but couldn’t find that either. Mumbling and grumbling, I decided to just hit another golf ball about where I guessed my original one had been. As I settled over the ball, calming my nerves and breathing, and running through in my head my litany of things to remember about making a good golf shot, a large RV roared onto the fairway pulling a trailer.

The RV came in from the right, crossed the fairway about 50 yards in front of us, and crashed into the trees on the left. It then proceeded to tilt towards us and rolled over twice, with the trailer becoming unhitched and rolling off to the right. A man and his wife got out of the RV with 3 kids and they were all scrambling around the two vehicles. I yelled at the guy that he was completely blocking the fairway but he just ignored me. Then a big backhoe with forklift prongs showed up and started lifting up a large fallen tree to clear the fairway. But somehow the tree got tangled up in overhead power cables which fell on top of the two vehicles, shooting sparks everywhere.

After a while all of that got cleared up but before I could hit my second shot the police showed up. They said the area was a crime scene and we wouldn’t be able to play golf on that fairway today. Not being stopped that easily, I went through the woods on the left until I came to a small clearing that looked out over a nice green valley - which was part of the first hole’s fairway. The green was on the far side of the valley and elevated. I was at the same elevation as the green and had a clear shot across the little valley. It was an odd shaped green, with a small portion on the right front which angled off to the larger portion in the back left. The whole left side of the green was protected by a string of sand traps, with another sand trap behind the green on the right side. I had a clear shot across the valley to the pin, which was in the right front.

Going back to my bag for a 4 iron, I found that instead of removing his clubs from my bag, the other guy had put in a whole lot more - there were now like 50 clubs in the bag. To hide what he had done, he had turned all the clubs upside down so only their grips were visible. It took me a long time to take out all of his clubs so I could find my own. Again I settled over the ball, calming my nerves and breathing, and running through in my head my litany of things to remember about making a good golf shot. At which point a troop of boy scouts charged into the valley and began setting up camp. There were 30 to 40 of them and I yelled at them that they had to move since I was going to hit my shot right over their heads. They grudgingly left but were immediately followed by a dozen college fraternity guys who were more difficult to get to leave. As the frat guys left, I got the distinct impression that they would be back later, to play college pranks on me.

My second shot was good and landed on the green but it was to the left and on the back side. I would have a long putt for a theoretical birdie, but most likely would make par. All of this had taken 2 hours. Given that a group is scheduled to tee off every 6 minutes, and that some groups are six-somes instead of foursomes, there were now about 100 guys backed up waiting to play the first hole. Even worse, everyone else who would play that day would also have a 2 hour delay, all due to my troubles on the first hole. Speaking of which, I still needed to finish the first hole and there were 17 more to play. The day was still bright and sunny. I then woke up and since it was 5:00 am I decided to work on the code for MWIF.

Explanation
In case you haven’t figured it out, here is some of the symbolism. Hitting golf shots = writing code. Finding the ball and figuring out the distance = defining the rules/program specifications. Golf clubs = software routines/modules. The other golfer in my group who keeps putting his clubs in my bag is Chris, who wrote the CWIF code. The RV = the upgrade to Delphi 2010 to support Win7, and the trailer = the Theme Engine upgrade. The cops = my conclusion that the Delphi 2010 debugger was unusable. The boy scouts = the beta testers finding bugs and things in the player interface that need improvement. The college guys = the WIF FE rules grognards. The golfers experiencing an intolerable delay = the players who want to buy a finished MWIF. You might want to read through the dream again and interpret some of the other images and events.

Hardware and Software
I have one problem with Theme Engine for Win7: it is taking too long to switch between major powers. For example, when choosing an action for each major power on the Allied side, the Choose Action form appears 5 times, once for each major power. When the deciding major power changes, the form refreshes to show the background colors et al for the new major power’s theme. That takes about 4 seconds, when it should be instantaneous. That’s too long given the number of times the deciding major power changes during a turn. I’ve got some ideas about why this happens and a couple of possible solutions.

I converted the Unit menu from standard Windows style to Theme Engine, but I still need to perform that task for the Main menu.

Beta Testing
I released versions 6.00.02 (20 fixes), 6.00.03 (2 fixes), 6.00.04 (21 fixes), 6.00.05 (12 fixes), and 7.00.00 (9 fixes), to the beta testers last month. This totals 5 new versions and 64 fixes, which is way under over my previous 4 month average for fixes (112). I changed the numbering to 7.00.00 because I added 3 new phases to the sequence of play - more on that below. The drop off in the number of bugs fixed was caused by my rewriting/restructuring ~6000 lines of code in addition to creating 3 new phases.

I cleaned up all known bugs related to partisans, air rebase, expending oil points, and US entry options. I tend to fix bugs in groups like this so I can work on a single section of code - it always takes a few minutes to refresh my memory about how things work for a rule. For rebasing carrier air units that are aboard carriers, I needed rule clarifications from the rules grognards and (eventually) Harry Rowland.

Version 6.00.03 only fixed 2 items because I had removed a bunch of code that should have been left in place. I needed to quickly upload a new version with the old code restored to keep the beta testers productive. This error on my part was due to the failure of my normal practice of inserting comments so I will understand what the code is doing 1 year in the future. My newly revised practice is to insert comments so I will understand what the code is doing 5 years in the future. The comments I had made in 2006 were so vague that I had misunderstood them.

I rewrote all the code for determining and finding valid rebase hexes. There were two bug reports which prompted me to do this: the search time was taking too long (minutes for a single air unit), and some valid hexes were being missed when triple the range was possible. The CWIF algorithm avoided the first problem by using Assembler code to speed up execution (I had replaced all Assembler code with Pascal code to achieve compatibility with operating system upgrades). The second bug was simply because the CWIF algorithm was wrong. I also revised the code to support clarifications from Harry on where carrier air units can rebase given where they start.

The new algorithm is far superior in that it preforms two searches simultaneously (testing against double the range when flying over enemy hexes and triple the range if enemy hexes can be avoided). It also maintains a list of hexes already examined and a list of sea areas already explored. The latter list is only for carrier air units that started on land and could rebase to a carrier at sea. Both of these lists are stored as arrays so a fast check can be made for whether a hex has already been evaluated. The CWIF algorithm made repeated searches through long lists - which is why it took so long when the range of the air units was large (e.g., > 12). I tested a naval air with a range of 22 using the new algorithm and the response time was less than a second. For most air units the response time is instantaneous. Another test I made for using triple/double range was from southern England to Gibraltar for an air unit with a range of 10. It was able to find the all-sea (no enemy) loop around an Axis controlled Iberia traversing 28 hexes.

By the way, the formula for counting the number of possible rebase hexes is 3X(X +1) + 1, where X is the range. So a unit with a printed range of 22 flying at triple its range is 3*66(66 + 1) + 1 = 13267 possible hexes, or about 1/5th of the global map. The search is much harder than simply checking each hex as a viable destination, since hexes controlled by neutral countries have to be avoided in finding a path to each hex.

Fatal errors during program execution now appear to be solely related to my recent changes to the code, so I fix them quickly.

Saved Games
Saving and restoring games remains stable. I did fix one strange bug with creating AutoSave directories that one of the new beta testers encountered.

Map and Units
Rob continues to send me updates of the naval unit writeups. I renamed the Teheran militia unit so it matches the city name on the map.

Scenarios and Optional Rules
Nothing new here.

MWIF Game Engine and CWIF Conversion
The three new phases to the sequence of play I added are: Production Planning Final, Search and Seizure, and Scrap Destroyed Units. The new sequence of play is:
.
.
• Preliminary Production Planning
• Stay At Sea A
• Stay At Sea D
• Return To Base A
• Return To Base D
• Use Oil
• Final Reorganization
• Break Down
• Final Production Planning (new)
• Search and Seizure (new)
• Scrap Destroyed Units
• Naval Repair
• Production
.
.

The Search and Seizure (S&S) phase was fairly complicated to code because there are a lot of conditions that need to be satisfied before a player can execute a search and seizure. Other annoying elements are that a resource could pass through two or more sea areas that were S&Sed, but obviously the resource would only be ‘lost’ once. More difficult to code was when a non-oil resource, an oil resource, and a build point are going through a sea area and of the 3 convoys being used, only one can be S&Sed. I arbitrarily decided that the lowest value item (non-oil resource) would be lost first to S&S. I placed the highest value on build points. This could be handled using random numbers but that seemed like more effort than the rule deserved. If you are interested, a couple of the Pascal routines for search and seizure are appended to the end of this report.

I added the Scrap Destroyed Units phase because the beta testers have been complaining for over a year about having to make a decision about scrapping every time a unit gets destroyed. That digression could occur in a couple of dozen places in the sequence of play and it was a distraction from what was immediately occurring (e.g., during an air-to-air combat). By simply placing all destroyed units in a big pile and letting the players decide which to scrap once at the end of the turn, the speed of play improves significantly.

There are still two more subphases that need to be add to Land Combat Resolution. Patrice, and others, pointed out that the decision on destroying units must be made by the defender before the attacker chooses whether to convert shattered results into retreats. And disorganizing attacking units needs to occur after the advance after combat. Currently all those decisions/events occur in one subphase and are not done in the order dictated by the WIF rules. I’ll try to get that fixed new month - at which time I will have the full sequence of play finalized and coded.

I rewrote all the code for moving units from the moving stack to a hex on the map. The CWIF code had been driving me crazy for years and I was having a very difficult time debugging land and naval moves (yeah, I know, the land moves should be easy to code). However, the CWIF code was a very long series of if statements. I restructured it using a case statement based on the current phase & subphase of the game. I did the same for Undoing unit moves. Together those routines had been roughly 3500 lines of code.

As an example of why the naval moves are so hard to code, consider a CW naval transport and the Queens located in London. During the naval movement phase the transport loads a division in the port and then both ships move into the North Sea. The transport stops in the North Sea and pick up a second division from Portsmouth. Then the Queens enters Plymouth, where it picks up an infantry HQ, goes out to the Bay of Biscay, enters Bordeaux where it drops off the infantry HQ and picks up an elite infantry corps, reenters the Bay of Biscay and thence into Cape St. Vincent. Ok, now the player wants to Undo all those moves, so it is up to the program to have maintained a record of what got loaded & unloaded where. Throw in the possibility that the Germans attempted an unsuccessful interception in the North Sea and only some of the moves can be undone. There are also rules regarding foreign troop commitments for the BEF in France, so if the HQ and infantry corps are switched, some of those moves by the Queens might be illegal. There is also the possibility that it is late in the war and some of the units are US or Free French, so compatibility between the units has to be considered. This is just for naval movement. There are more rules that apply during the return to base phases and yet more if the naval units are rebasing because they were overrun. Very complex stuff to code.

Player Interface
I changed about a dozen places in the code where a Yes/No question was asked and the player had to answer without having access to information (e.g., the map). Most of the time, these decisions are easy to make, but there are cases where the player might want to review some stuff before deciding (e.g., denying the USSR claim on the Finnish Borderlands). The changes I made enable him to now do so for the more complex situations. Basically, the detailed and global maps and all the informational forms are now available.

I created a new form for Search and Seizure. That whole phase is brand new and needs alpha testing by me before the beta testers take a crack at it. It’s hard to test since there have to be very precise conditions in place before search and seizure can be executed by a major power.

I revamped the Victory form so more room is available for showing the victory points. At times there are little messages included to explain the victory points, and more room was needed. As often happens, because I was forced to make changes, I ended up with a better looking form in the end - I’ll try to remember to post the revised one in the next couple of days.

I rewrote all the code for generating text messages as the cursor scrolls over the map with a unit (or units) in hand. These messages inform the player whether the unit(s) can move to the hex under the cursor and if not, why not. The beta testers had complained about some of the messages being wrong, or at best confusing. But the code was equally confusing - being 2500 lines in a series of if statements. I restructured it using a case statement based on the current phase & subphase of the game. In reality, my motivation for fixing these messages was that I was having trouble debugging naval moves and the erroneous messages were really not helping.

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new. I need to go through the section on the sequence of play and bring it up-to-date so it includes the 3 new phases mentioned above. I also have to add a screen shot and text for the new Search and Seizure form.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Andy Johnson (who did the work to develop the MWIF fan site from nothing) has found a new administrator for the fan site. As I write this we are still getting Paul established as a beta tester.

Communications
Nothing new.

===========================

Code: Select all

 // ****************************************************************************
 function UFilterSearchAndSeizure(const U: TUnit): Boolean;
 // ****************************************************************************
 // •	you must have an SCS, CV, or SUB in the sea area;
 // ****************************************************************************
 begin
   Result := (MajPower(U) = UFMajorCountry) and
             (U.UnitType in [utCarrier, utLightCarrier, utBattleship, utCruiser,
                             utLightCruiser, utAuxiliaryCruiser, utASWEscort,
                             utASWCarrier, utSubmarine]);
 end;
 // ****************************************************************************
 function UFilterSearchAndSeizurePrevention(const U: TUnit): Boolean;
 // ****************************************************************************
 // •	there must not be an SCS, CV, or aircraft unit with an air-to-sea factor,
 //    controlled by a major power with which you are at war in the sea area (nor
 //    a US unit that can escort there because of US entry options 11, 20, 29,
 //    38, or 50 ~ see RAC 13.3.2).
 // ****************************************************************************
 var
   Surface: Boolean;
   NavAir: Boolean;
 begin
   Surface := (U.UnitType in [utCarrier, utLightCarrier, utBattleship, utCruiser,
                              utLightCruiser, utAuxiliaryCruiser, utASWEscort,
                              utASWCarrier]);
   NavAir := (U.UnitType in AirUnitSet) and
             (TAirUnit(U).AirSea > 0) and
             (U.TransportedBy = nil);
   Result := (UFMajorCountry.Relations[U.Country] = crWar) and
             (Surface or NavAir);
 
   if Result then Exit;
 // ****************************************************************************
 // Check for US entry option exceptions.
 // ****************************************************************************
   Result := (UFMajorCountry.Relations[U.Country] <> crWar) and
             (UFMajorCountry.Side = sdAxis) and
             (UFConvoyMajPow = UnitedStates) and
             (MajPower(U) = UnitedStates) and
             (Surface or
              (NavAir and						
               USEntry.OptionChosen(useAirEscort))) and
 // ****************************************************************************
 // If unrestricted naval warfare has been declared, then all US combat units in
 // any section box in all sea areas prevent search and seizure.
 // ****************************************************************************
             (USEntry.OptionChosen(useUnrestricted) or
              ((U.Section = 0) and
 // ****************************************************************************
 // If Arm Merchantmen has been declared, then US combat units in the zero
 // section box of any sea area prevent search and seizure.
 // ****************************************************************************
               (USEntry.OptionChosen(useArmMerchantmen) or
                (USEntry.OptionChosen(useNorthAtlanticEscorts) and
                 (UFSeaArea in [EastCoast, NorthAtlantic, CaribbeanSea])) or
                (USEntry.OptionChosen(useEastCoastEscorts) and
                 (UFSeaArea in [EastCoast, CaribbeanSea])))));
 end;
 
[/color]
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

January 1, 2011 Status Report for Matrix Games’ MWIF Forum

Accomplishments of December 2010
Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

I restructured by task list so the items needed to completely debug Solitaire play have highest priority. There are 169 bugs remaining for that and I am driving to fix them all by February 1st. Since there were 460+ at the high water mark this past summer, this is doable if I do not get distracted by other issues. To kill off 6 per day is my goal. Attached is my current spreadsheet on the bugs remaining [the bug counts don’t match because the spreadsheet contains items for the other modes of play].

The other big news is that Mitchell has volunteered to help with the MWIF programming. The MWIF code has a steep learning curve but he has overcome the first hurdles of installing/upgrading Delphi, Theme Engine, and the JEDI library. He can now recompile and link the MWIF source code to generate the MWIF.exe. That is not a minor achievement. You’ll find his summary of progress below in the section on NetPlay.

Hardware and Software
Mitchell is also doing detailed timing studies on why Theme Engine takes so long to switch between major powers. Once we have figured out where the time goes (lyrics from a 1960's song), we’ll be able to make changes. It is fruitless to make changes to Theme Engine and just hope they solve the problem.

I converted the Main menu from standard Windows style to Theme Engine. So, aside from the above problem, Theme Engine now runs cleanly under Win XP, Vista, and Win 7.

Beta Testing
I released versions 7.00.01 (6 fixes), 7.00.02 (20 fixes), 7.00.04 (14 fixes), 7.00.05 (21 fixes), 7.00.06 (6 fixes), 7.00.07 (14 fixes), 7.00.08 (10 fixes), 7.01.00 (11 fixes), and 7.01.01 (10 fixes), to the beta testers last month. This totals 9 new versions and 112 fixes, which is above average for both new versions and fixes. I changed the numbering to 7.01.00 because the patch count was getting pretty high for 7.00.

I removed all the calls to Scrap Unit Digression and added the new phase Scrap Destroyed Units so it precedes the Production phase. This had the unexpected benefit of maintaining a list of destroyed units for the turn that players can review. It only took a couple of minutes to add that list to the Pools form (where you can also view units in production, in construction, repair, scrapped, etc.).

I cleaned up all known bugs related to Stay-at-Sea and Sentry status. The later is a feature of the computer game which has a dual purpose: (1) skipping Sentry units when cycling through all the units that can move in a phase, and (2) during the stay at sea phases, those marked as Sentry automatically stay at sea.

I reduced the land movement bugs from 26 to 10. Some of these dated back to 2006. See the paragraphs on Player Interface below for more details.

Fatal errors are becoming more and more scarce and quickly corrected. I fixed a rather infamous one from CWIF that occurred during Vichy formation.

Saved Games
Saving and restoring games remains stable. I had to add a few more variables to the saved game format to handle changes to the player interface for land movement (see below).

Map and Units
Rob continues to send me updates of the naval unit writeups. Otherwise the data and graphics for the map and units are unchanged.

Scenarios and Optional Rules
I added code to handle specific rules for declarations of war in the Day of Infamy scenario.

MWIF Game Engine and CWIF Conversion
I reworked all the code and internal data related to transported units. Some of this involved renaming variables and functions so that I could read the code more easily. I did find redundant code and I cleaned up a lot of other stuff that was messy. One helpful change, purely cosmetic, concerned the 250+ references to TransportedBy being equal to nil or not. I changed “TransportedBy <> nil” to Aboard Transport and “TransportedBy = nil” to Not Aboard Transport. Removing the reverse negation really helps when reading the code. That is, in the CWIF code “not equal nil” implies the unit is aboard a transport, or more simply, ‘not’ implies ‘is’. It is very easy to misread logic sequences that contain what I am calling “reverse negation expressions”.

Another example of a CWIF reverse negation expression was the Ignore Notional Unit form. The defending player was asked if he wanted to ignore the notional unit in an invasion/paradrop. If you answered No, then the notional unit was added to the defending units: ‘no’ implies ‘add’. This past October (November?) I revised that form so the question now is “do you want to include the notional unit?”, so ‘yes’ implies ‘add’. It’s now named the Include Notional Unit form.

I also built an enumeration list of the possible relationships a unit might have in regard to transporting or being transported by another unit. CWIF used “if ... then ...” logic sequences to make these determinations (in hundreds of places). With the enumerated list, MWIF code replaces those with a single case statement based on TransType. Here are my in-line comments on the enumerated list values:

TransType is used to record the linkages between units that are transporting other units, transported by other units, or have recently unloaded from another unit.
• trtyIng1 - Self is currently transporting 1 unit.
• trtyIng2 - Self is currently transporting 2 units.
• trtyIng1U - Self is currently transporting 1 unit, but it had been transporting a second. Self is a non-carrier naval unit.
• trtyUnloaded1 - Self (a naval unit) unloaded 1 unit after moving.
• trtyUnloaded2 - Self (a naval unit) unloaded 2 units after moving.
• trtyBy1 - Self is currently transported by 1 unit.
• trtyBy2 - Self is currently transported by 2 air transports.
• trtyByR - Self is currently transported by a carrier & rebased from a different carrier in the AirRebase phase.
• trtyNormalUnload - Self unloaded from a naval transport that returned to port or Self unloaded from an air transport that was aborted in the Paradrop or AirTransport phases.
• trtyFromUnload - Self (a land unit) unloaded from a naval transport in the UnloadLandUnits phase.
• trtyFromInv - Self unloaded from a naval transport in the current or immediately previous Invasion phase.
• trtyFromAirRebase - Self (an air unit) unloaded from a naval transport or carrier in the AirRebase phase.
• trtyFromCarrier - Self is a carrier air unit either flying an air mission or engaged in a naval air combat.

&#9633; In all the above cases the other units are stored in TransLink[1] and TransLink[2].
&#9633; In the trtyBy2 case, TransLink[1] and TransLink[2] both have a TransType of trtyIng1, even though they are only carrying half of the transported unit.
&#9633; In the trtyByR case, TransLink[1] is the current carrier and TransLink[2] is the carrier Self was aboard at the start of the phase.
&#9633; In the trtyFrom and trtyNormalUnload cases, the TransLink[1] value is used to undo the move.
&#9633; In the trtyFromInv case, the TransLink[1] value is used to determine from which section box the unit is invading.
&#9633; In the trtyFromCarrier case, the TransLink[1] value is used when the player wants the carrier air unit to return to the carrier from which it started the mission.


What motivated me to spend a week making these changes was the difficulty in debugging the code related to undoing air and naval moves when transported units were involved. Picking units up from coastal hexes during naval movement was particularly complex. For example, in a single move, a transport could start empty in a port, go out to sea, then go through a different port and pick up a division and then go out to sea again, stop, and pick up a carrier air unit from a coastal hex. Then the player decides to cancel/undo the move - so the program logic has to be capable of getting all the units back to their correct starting points. As you can see from the above list, that is only one of the dozens of possible air and naval moves that require special code so the move can be correctly ‘undone’.

Once all the changes to the transported unit code were made, I was able to clean up ~10 bugs related to transported units painlessly, and in the sure knowledge that the changes weren’t going to mess up any of the other cases in the above enumerated list.

I revised the code for placing units in off-city hexes when that optional rule is in effect. This change was to accommodate more than 1 major power placing units during the Reinforcements phase. The CWIF code assumed there would only be 1 major power doing that at a time, but with NetPlay there could be as many as 6 major powers doing so simultaneously. Therefore, there needed to be separate variables for each major power instead of a single variable. This affected a lot of variables, especially in save and restore game. It is also why the version 07.00.03 was never uploaded. I made the new changes to GameSaveRestore for 07.00.04.

Player Interface
I added names to the Unit Data Panel, so transported units identify which unit(s) they are carrying and transported units identify by which unit(s) they are being carried.

I identified a dozen queries where the player may want to examine the map and other forms before answering the question. For example, when Germany is deciding whether to grant the USSR’s claim on the Finnish borderlands, checking the disposition of the USSR forces is a good idea. Instead of these queries being shown on a modal form (which freezes the player interface until the question is answered), they are now shown using a non-modal form, so the player can dilly dally about looking into every unit stack on the map before making these decisions (as he might infuriatingly do in an over-the-board game).

I added double-left-click to select all naval units in the Setup Tray. This is in lieu of Ctrl A for selecting all units. The units selected are those shown using the setup tray’s filter (e.g., just battleships). The purpose here is to enable a player to select a large number of naval units for placement without having to click on individual units. Selecting all air units is difficult to design and code because of the need to decide which units go to the reserve pool. And selecting all land units doesn't make a lot of sense because of stacking limitations. So, this feature is just for naval units.

I added a unit menu item “Return from Whence” for air units that fly missions. Clicking on this menu item returns the air unit to the hex or carrier from which it started the mission. This saves a lot of time if you simply want air units to go back to their original air base/carrier. That’s especially true when you have a lot of carrier air units returning from a naval air combat. In combination with the Selectable Units form, which lists all the air units returning to base, players can complete a return to base subphase quickly, without little effort.

I clarified the anti-aircraft results form by adding some more information. I decided when a person who has been an active beta tester for CWIF and MWIF (over 12 years) gets confused, it is time to change the displayed information.

Lastly, I made final decisions concerning the player interface for land movement and wrote new code for about half of them. These problems were identified early in my work on MWIF, in 2005 and early 2006. But I had a lot of other things that needed to be done first, so I have let them simmer for years. Occasionally the topics would surface again in the beta tester development forum, but they were very thorny issues and intricately interrelated. I am now confident that I have solutions for all of them and I am working on writing the code to implement them. The problems were:
1. Partial movement of a unit such that the unit has movement points remaining. This occurs when a stack overruns enemy units and still has movement points remaining. The stack’s move can be interrupted by a digression to rebase overrun units.
2. Undoing moves.
3. Friendly and enemy units whose supply status changes during the phase.
4. Overstacking.

Our primary goal is to make MWIF play like the board game. While the WIF FE rules impose rigid restrictions on what can and can not be done, in practice over-the-board players use looser rule interpretations. It is common practice to let a player “take back” several moves during the land movement phase, as long as nothing substantial has happened and everyone can agree on where the units started the phase. Likewise, swapping units between hexes that are fully stacked is usually permitted, as long as the overstacking is corrected by the end of the ‘step’. But enabling these abilities lends itself to potential abuse by players of MWIF. Hence the need to define exactly what is and is not permitted for the above 4 items. For details, see section 8.4.5.1 of the Players Manual, which is appended to the end of this report.

Internet - NetPlay
From Mitchell (edited by Steve):

Steve asked me to see what I could do to get NetPlay fleshed out sufficiently to start testing MWIF’s multi-player modes: NetPlay and PBEM. Being new to the project, this meant coming up to speed on the Delphi IDE, the Indy socket library, and the earlier version of NetPlayComTest. After much experimentation, I developed several interim NetPlayComTest versions and tested them in small group sessions, culminating at the end of the month with uploading NetPlayComTest version 1.2.0.0 for all the beta testers to test. Feedback from the beta testers running NetPlayComTest on a variety of network setups will enable me to validate a final version of NetPlayComTest. Then that code can be integrated into MWIF’s NetPlay. [Note that NetPlayComTest will be a stand alone executable for delivery with the released MWIF product, so players can test their internet communications without having to run a MWIF game.]

A key concept for NetPlay is that one or two of the players’ computers act as a server. NetPlay supports from two to six players, with one player on each side acting as Leader for that side. Each Leader’s computer can act as a server (in the network sense) for his side, and one Leader’s computer is the game’s Master server. The Master server keeps the master record of game state, marshals communication between players and sides, makes die rolls, etcetera. Which player’s computer acts as Master and/or Leader depends on the scenario played, the number of players, and possibly the stage the game is in. For example, one server is sufficient unless there are 4 or more players in the game.

Having a player’s computer act as the game server is a different architecture from what many online games employ, where there is usually one or more dedicated servers/machines that each player logs into. While this common approach scales well and so can support massively multi-player games, it lacks the kind of flexibility desired for MWIF. MWIF contains many features that will help make the speed of play comparable to WIF, the board game, but MWIF playing sessions are still likely to be protracted affairs. To maintain maximum flexibility in the event of lost connections, players having to log off and back on for various reasons, and so on, NetPlay is designed so that any player may act as the game Master and/or side Leader as the game progresses and players (or even all players on one side) leave and rejoin a game. This architecture is a challenge to implement programmatically but doable, and it should serve well for the style of play MWIF demands.

The state of NetPlay development as of 31 December 2010 is summed up in the functionality of the latest NetPlayComTest version: up to six computers on a LAN and/or the Internet can establish communication through NetPlay and use the link to send and receive message packets reliably for extended periods.

Steve had already set up a framework in MWIF for building the necessary message packets containing game state and event information, so adding the communication functions from the test utility should bring us very close to testing MWIF multi-player modes. The next steps in NetPlay development are:
1. Add a NetPlay setup dialog to allow entry of IP Addresses associated with each player and to keep track of which players are the game Master and Leaders, and who is playing which Major Power Group. This information will persist in an associated INI file that can also be used by MWIF.
2. Set up and attempt to establish connections automatically based on information read from the INI file.
3. Attempt to reestablish communication links if and/or when they are dropped.
4. Reassign computer roles of game Master and Leaders if players, or a whole side, drops out intentionally or unintentionally, temporarily or for the duration of that gaming session.
5. Add PBEM simulation, replacing TCP message transactions with programmatically generated email messages but using the same logical player framework outlined above.
6. Integrate everything back into the MWIF code base, replacing test messages with the Game Record Log messages, support for game re-synch from the Master, chat between players and among each side, etcetera.

Please let us know what you would like to see in the way of inter-player communication support.


PBEM
Once Mitchell gets the NetPlay communications working, he’ll do the same for the PBEM communications.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
I added new subsections in the Player Interface section, specifically addressing how to move land, naval, and air units. While the description of the keyboard and mouse commands is accurate and complete, it doesn’t really answer the questions new players are likely to have about how to “get things done”. I’ve appended the new subsection on moving land units to the end of this report. I still need to write similar subsections for moving naval and air units.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Paul is now the administrator for the fan site.

Communications
Nothing new.

===========================
8.4.5.1 Land Movement
Left clicking on a selectable land unit during the land movement phase transfers it to the “moving stack”, which, if you are familiar with board war games, you can think of as “picking up a unit”. The cursor then displays the selected unit which is no longer shown in the hex it had been occupying. As you move the cursor over the map, the cursor superimposes a target symbol (circle inside a cross) onto the image of the moving unit to indicate a valid destination hex. For invalid hexes, a large X is superimposed. At the bottom of the Main form, a text message augments the cursor’s information. For example, for a valid destination hex, the number of movement points required to enter the hex is shown. If a destination is invalid, the text message explains why.

Default Path
The easiest way to move a unit is to “pick one up” and left click on a destination hex. The program finds the fastest path to the destination hex. Here fastest means the path that requires the fewest movement points. Although visually the unit appears to ‘jump’ from its original hex to the destination hex, in actuality the program moves the unit along the fastest path, just as if you had moved the unit one hex at a time.

Precise Path
If you do not want to use the program’s chosen path, you can control which hexes the unit enters by holding down the Ctrl key and left clicking on each hex in the path you want the unit to traverse. In fact, you can combine these two methods. For instance you could use the Ctrl key and click on the first hex in the path and then release the Ctrl key and click on a final destination hex several hexes away. Entering a precise path for a unit is often done by the German player when advancing through Russia to make sure that control of every hex changes from the USSR to Germany.

Group Movement
If you want to move several units as a group (e.g., to conduct an overrun) you can either select them using the Flyouts form (see section 8.4.6), the Units in Hex form (see section 8.7.1.24), or using Ctrl-Left-Click in the unit’s start hex (see section 11.8). All the units you select have to have started the impulse in the same hex. Once you have selected a group of units, you move them the same way you move a single unit.

Partial Movement and Overruns
You can move a unit to a preliminary destination hex and then pick it up again and move it to a final destination hex. In fact, this is what happens when you hold down the Ctrl key to enter a precise path. This ability is most important when you conduct an overrun. After the defending units have been destroyed, captured, or forced to rebase in an overrun hex, you can continue to move the overrunning units by picking them up again, provided they have movement points remaining. Because of the zones of control rules, for some overruns you may have to first use the Ctrl key to move your units to the hex adjacent to the hex you want to overrun and then pick them up again and click on the overrun hex.

Once you have completed moving a unit or stack of units and picked up a different unit, you can no longer go back to the first group and move them again. This is true even if the first group still has unused movement points. This is how MWIF implements the Rules As Coded rule: “You must finish moving the unit(s) you are moving before you can start moving another unit”.

Undoing Moves
MWIF is somewhat forgiving in that it usually permits you to undo your moves without regard to the order in which they occurred. For example, you can move unit A, then move unit B, and then go back and undo unit A’s move. Indeed, there is a menu item on the drop down Command menu of the Main form that lets you undo all moves. There are two important exceptions to this leniency.

1. Should you conduct an overrun, then all the moves you made prior to the overrun can no longer be undone. The overrun might even have been made by one of your allies, and occurred thousands of miles away. Regardless of where and what is overrun, as soon as an overrun is performed, all land moves made previously in the impulse become permanent and can not be undone.

2. Should an out-of-supply or isolated unit have its supply status improved (e.g., from out-of-supply to in-supply), then the program marks the unit with the Improved Supply Status as ISS. If an ISS unit moves, then all moves made prior to that action are ‘frozen’. That is, you are unable to Undo any previous moves unless you first Undo the ISS unit that moved. The reason for this rule is to prevent exploitation of the Undo move to circumvent the rules by, say, (1) moving a unit to provide supply to other units, (2) moving the newly in-supply units, and then (3) undoing move #1.

Overstacking
In general, units may not overstack during land movement. However, MWIF enables temporary overstacking, primarily to enable players to rearrange units in hexes that are fully stacked. A typical instance of this is when the French have 2 corps in every hex of the Maginot Line and want to switch which units are in which hexes. To facilitate this, MWIF permits units to be overstacked when a unit, or stack of units, ends its movement. But then the next unit or stack of units that moves has to correct the overstacking. In the case of two French corps, A and B, in Metz, and two more corps, C and D, in Strasbourg (adjacent to Metz), the player is permitted to move unit A to Strasbourg, even though that causes overstacking. But then his next move has to be to move unit A, C, or D out of Strasbourg, to eliminate the overstacking.

Temporary overstacking enables you to move a stack of units from behind your lines up to a hex in your front line (which becomes temporarily overstacked) and then continue moving by overrunning units in the enemy’s front line.

Another subtlety of land movement and overstacking is when an HQ or an engineer has been used to enable air units to overstack in a hex. Moving the HQ or engineer out of the hex would then cause the air units in the hex to be overstacked. MWIF permits this overstacking to occur, and permits it to remain in effect until the end of the land movement phase. So, if you move an HQ out of a hex, causing air units to be overstacked, later in the phase you can move another HQ (or an engineer) into the hex, thereby negating the overstacking. Failure to correct the overstacking by the end of the land movement phase means the owner of the air units has to chose which air unit(s) to destroy.


Image
Attachments
StatusSpr..312010.jpg
StatusSpr..312010.jpg (979.74 KiB) Viewed 19730 times
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

February 1, 2011 Status Report for Matrix Games’ MWIF Forum


Accomplishments of January 2011


Project Management
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.

From Mitchell:
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
From Mitchell:
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.


Beta Testing
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.

Saved Games
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.

Player Interface
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.

From Mitchell:
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.


PBEM
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.

From Mitchell:
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.


Player’s Manual
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
Nothing new.

Marketing
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.

Communications
Nothing new.
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

March 1, 2011 Status Report for Matrix Games’ MWIF Forum

Accomplishments of February 2011

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

There are 94 bugs remaining for basic solitaire play. Roughly 1/3 have to do with naval movement/combat and another 1/3 have to do with routing resources overseas. I had the count down to a low of 83 at one point this month.

Rolf was able to get a clean compile and link of MWIF, but only after much effort. It seems every time MWIF is installed from scratch on a computer system, whether by me or anyone else, there are unexpected problems. Well, I was guilty of leaving out one file when I provided the source code to Mitchell, and then managed to leave out 2 other files when I created a fresh set of source code for Rolf. But nonetheless, there were other difficulties that arose which didn’t make a lot of sense (to me). I guess setting up Delphi, the JEDI libraries, Theme Engine, MadExcept library, and the WIF Custom library involves a lot of steps which have to be performed nigh-on perfectly or else things careen off into a ditch.

I lost a few days this past month (a short month anyway) updating the chorus’ mailing list for the spring show mailing (500 new names and 800 revisions). Then there was the 30 hour span where I made 3 trips to dentists (zero amusement there). In effect, I had 24 working days for MWIF in February.

Hardware and Software
Mitchell spent most of the month delving into Theme Engine (TE) source code and running timing trials to determine why it took so long to change the theme from one major power to another. He finally fault isolated it to refreshing the scroll bars for the detailed map. I am not sure exactly why that requires 3 seconds to accomplish, but after I removed the detailed map’s scroll bars from the list of TE components, changing the deciding major power took 2 seconds instead of 5. We might be able to tweak that a little lower, but for now that’s an acceptable delay. If time permits, we might go back and see if we can get the detailed map scroll maps to work under TE without the 3 second delay for introspection.

Mitchell also tested using the new version of TE (9.20) and found it more efficient when changing the theme (although the detailed map scroll bar problem was unaffected). So we replaced TE version 9.10 with 9.20.

Beta Testing
I released versions 7.04.00 (17 fixes), 7.04.01 (16 fixes), 7.04.02 ( 28 fixes), 7.04.03 (1 fix), 7.04.04 (28 fixes), 7.04.05 ( 16 fixes), and 8.00.00 (12 fixes) to the beta testers last month. This totals 7 new versions and 118 fixes, which is my normal average for a month. Obviously version 7.04.03 fixed a major problem that I had created with version 7.04.02 - hence the immediate release of the patch with 1 fix the next day. I changed the numbering to 8.00.00 because we installed the new version of Theme Engine (9.20) and otherwise have solved most of the problems with TE. This also is a significant milestone since I am bringing both Mitchell and Rolf up-to-date with a complete new source code upload that corresponds to version 8.00.00.

Fatal errors still occur but they are fewer in frequency. About 2/3rds of the new bugs relate to recent changes I made to the code. Those are easy to fix. And the rest of the bugs are either duplicates of bugs previously reported or obscure items. For example, when an empty hex is both invaded and attacked from an adjacent hex, the odds displayed during the Land Combat Declaration phase do not include the notional unit. Change any of those conditions and the odds are shown correctly. As I said, obscure.

Here is the modification that caused me to skip version 7.03.00:
I modified the code to conform with changes from Harry Rowland (ADG) as to where naval units can set up at sea. Previously CWIF tracked each unit that was set up at sea back to either a major or minor port and counted how many were using each minor port for a hypothetical "return to base". Harry's modified rule is that there only needs to be one opening available for all units at sea. So, dozens of naval units could be ‘using' the same minor port. The code now has no minor port limitations imposed when units are set up at sea. However, at the end of setup for each major power, a check is run to make sure at least one slot is available for each naval unit set up at sea. The same slot can be used by innumerable ships. If there isn't an available slot, then the program requires the payer to correct the setup before the setup phase for that major power can be terminated. Because this change affected the format of saved games, I skipped version 7.03.00 and went directly to 7.04.00.

Most of the bugs I fixed during February involved naval movement and naval air combat. By contrast, surface and submarine combat seem stable. I currently have 9 naval movement and 16 naval combat bugs to figure out and fix. Virtually all the naval movement problems relate to interceptions and the naval combat to naval air combat. So, after fixing a bunch of stuff, I’m back to about the same count I had last month for those two phases (sigh).

Saved Games
Saving and restoring games is stable. I added the name of the current major power to the label for automatically saved games during 10 additional phases. This makes it possible to restore a game to a more precise point in the sequence of play. For example, you can restore a game partway through choosing actions for major powers rather than only at the beginning of the phase.

Map and Units
Rob continues to send me new and/or updated naval unit writeups. Happily, Adam has returned to doing new writeups for the land units. The count for missing land unit writeups is now below 90. I updated the master file of land unit writeups with both Adam’s additions and another couple of dozen that I had received over the past year. The master file is now current with all land unit writeups I have received.

Scenarios and Optional Rules
Nothing really new here. I fixed a couple of minor bugs that were scenario specific.

MWIF Game Engine and CWIF Conversion
I got the Naval Abort Queue to function correctly. There are a still a couple of small bugs remaining, but the primary functionality of choosing which units to abort as a group and returning them to base now works. Hark, the last of the 7 digression ‘phases’ (Naval Combat Abort ) has been completed!

I also fixed a bug in nested digressions so they operate as intended. For instance, when an overrun naval unit is forced to rebase through an enemy controlled sea area, a naval interception digressions occurs. After the interception is resolved, the sequence of play returns to the forced naval rebase digression in progress. The forced naval rebase digression could occur during land movement, advance after combat, invasions, conquest, or other places in the sequence of play.

Player Interface
I added a small new form that reports which scenario is being played, mode of play, and which players are playing. It is of minor importance for game play but is helpful for debugging purposes.

I modified the Choose Naval Combat form so it gives more emphasis to the list of sea areas. This was part of a general revision to the form to fix some bugs.

Internet - NetPlay
For now, NetPlay is in Mitchell’s hands. He was distracted by working on Theme Engine but should get back to the stand alone test program for NetPlay soon.

PBEM
Once Mitchell gets the NetPlay communications working, he’ll do the same for the PBEM communications.

Artificial Intelligence (AI)
Peter made excellent progress on the geographic breakdown for the AI Opponent. I revised the documentation on the command structure for the AIO so each element of the geography has a corresponding decision maker. There are 16 Theaters of Operation (TOs) that span the global map. Within each TO there is a breakdown for naval units into Sea Area Groups (which contain individual Sea Areas) and for land units into Areas of Operations (which contain Land Regions). The goal here is to provide a hierarchy of decision makers for strategic and operational decisions and a different decision maker for tactical decisions.

For instance, decisions about convoy routes span multiple sea areas and are made higher up in the chain of command, while decisions concerning a specific naval combat are made by the Fleet Admiral responsible for the sea area in which the combat is taking place. Likewise army reinforcements are shipped off to various TOs, whose commander designates which AO gets them; the AO commander designates a Land Region, whose Commanding General then decides in which hex to place the new unit.

What Peter has achieved is a finished geographic breakdown for Western Europe and the Med. He has almost completed the same for Eastern Europe. Those 3 geographic regions encompass the WIF FE European map.

Rolf and Mitchell plan to work together on completing the parser for LAIO (Language for an Artificial Intelligence Opponent) scripts. Peter has been working diligently on LAIO scripts and deserves seeing them in action, making decisions, ASAP.

Player’s Manual
I updated Rules as Coded (RAC) with a description of the Naval Abort Queue, which is a deviation from Rules as Written (RAW). I also reviewed and updated section 10 of the Players Manual so it accurately lists all the RAC deviations from RAW.

Tutorials, Training Videos, and Context Sensitive Help
I continue to make small changes to the context sensitive help messages based on feedback from the beta testers.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Nothing new.

Communications
Nothing new.
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

April 1, 2011 Status Report for Matrix Games’ MWIF Forum
Accomplishments of March 2011

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

There are 83 bugs remaining in the sequence of play. I had the count down to a low of 81 a couple of times this past month but I haven’t been able to crack 80 yet.

Rolf did some work on the LAIO parser (see the section on AI below). Mitchell has had some pressing matters in his home life and was unable to spend time on MWIF in March.

Hardware and Software
I purchased an upgrade to CorelDraw so I can run it under Win 7. I don’t use this graphics package as much as I use to, but it still is my primary tool for creating and maintaining graphics for help files (e.g., unit status indicators).

The only open item with Theme Engine concerns the scroll bars for the detailed map. At some point I want to fix that so all the scroll bars in the game are identical, but that’s no big deal.

Beta Testing
I released versions 8.00.02 (20 fixes), 8.00.03 (17 fixes), 8.00.04 (11 fixes), 8.00.05 (2 fixes), 8.00.06 (14 fixes), 8.00.07 (14 fixes), 8.00.08 (5 fixes), and 8.01.00 (20 fixes) to the beta testers last month. This totals 8 new versions and 103 fixes, which is slightly below my average number of fixes for a month. There was no version 8.00.01. Every so often I modify the format for saved games and have to skip a version number as far as the beta testers are concerned.

Obviously versions 8.00.05 and 8.00.08 fixed major problems that I had created in the previous version - hence the immediate release of a new patch the next day. I changed the numbering to 8.01.00 because the number of patches was growing too large.

The breakdown by “the date the bug was first reported” is:
2006 - 3
2007 - 0
2008 - 0
2009 - 16
2010 - 22
2011 January - 14
2011 February - 15
2011 March - 13

A quick summary would be: 1/4 from prior to 1020, 1/4 from 2010, and ½ from the first 3 months of this year. What I take from the above statistics is that I’ve cleaned up thousands of old bugs but new ones keep appearing. This reflects the ability of the beta testers to go through the sequence of play more often/faster (because there are fewer problems), which enables them to encounter situations they hadn’t seen previously.

I focused on the naval movement bugs this past month and reduced them to zero - several times (the beta testers keep me honest). So, I believe that all the code related to moving naval units is now bug-free (I’m always the optimistic programmer). There are 13 naval combat bugs and 28 having to do with routing resources overseas. The other half are scattered about in different places in the sequence of play.

In reviewing the 103 fixes for the past month about 2/3rds related to either naval movement or naval combat. Naval air combat is very complex and a bear to debug because of all the possibilities. Especially troublesome has been aborting air and naval units from the different places in the combat where that can occur (see the Players Manual section 8.4.5.4 Air Movement which is appended to the end of this report). These days my main difficulty with the other bugs scattered throughout the sequence of play is recreating them so I can figure out what is going wrong. I have 300+ saved games that let me test individual phases and subphases in the sequence of play, but things that happen rarely (e.g., Turkish units moving into Greece, conquest, surrender, and liberation of major powers) are not in my quiver of saved games.

Fatal crashes are rare, perhaps a half dozen in the past month, and I was able to fix almost all of those immediately.

Saved Games
Saving and restoring games is stable. I continue to make small changes to the saved game format as I find a need for additional variables to keep track of the game state.

Map and Units
Rob and Adam continue to send me new and/or updated naval and land unit writeups, respectively.

Scenarios and Optional Rules
I made half the sea areas illegal to enter for the half-map scenarios. For instance, when playing Fascist Tide (the war in Europe) entering the Indian and Pacific Oceans is not permitted. Doktor has been testing Fascist Tide and there have been several things I needed to fix related to the special rules for half map scenarios. Orm is also testing head-to-head/hotseat play. There isn’t a lot to that from a programming point of view. Mostly, the program needs to display a form/message that says to switch to the other player/side.

MWIF Game Engine and CWIF Conversion
I added more information to the Main form's prompt message when it is possible to move naval units (cost in movement points and range for using safest route). More importantly, I revised the code for the internal record formats on which sea areas/ports the units-in-hand can move into. CWIF used the same record layouts for air rebases, all land unit moves, and all naval moves. I split those into 3 different record types (air, land, naval) since different information was needed for each record type. That let me clarify the names of the fields in each record so they explain the data better. The changes for the air and land moves had zero effect - since they effectively were just cosmetic.

My main motivation was to make it easier to debug the naval movement code. The summary of naval movement that is appended to the end of this report (taken from the Players Manual 8.4.5.3 Naval Movement) should explain why I felt a strong need to make the code as easy to understand as possible.

The main effect on game play of the naval changes is that the program now assumes the player wants to avoid sea areas where the enemy can attempt to intercept the moving units, even if it takes more movement points. The player can always move directly to sea areas where the enemy can intercept and ‘dare' him to do so. If the enemy declines (or fails), the player can continue moving and perhaps reach his destination using fewer movement points and range.

I created a new ‘pool’: the Destroyed Units Pool. This is another off-map ‘location’ for units. It replaces the Destroyed Stack variable that I had been using. Besides maintaining standardization with all the other off-map pools, this addition makes it clear ‘where’ the unit currently resides. When players access the Pools form to review the units in the off-map pools, the Destroyed Pool is like all the others (e.g., Force Pool, Production Pools).

Player Interface
I enhanced the Drop Off Units forms to clarify what happens when a group of naval units enters a port. It was easy to get confused when some of the naval units stopped in the port, while others in the moving group picked up cargo and continued moving.

I modified the Select Units form so it includes filters for movement points and range. For example, this lets you examine a large stack of naval units and quickly select just those with 6 movement points. I also increased the size of the form so more units are visible.

I updated and improved the unit status indicators. The main change was to clarify when a unit was receiving HQ support and/or engineer support. I also updated the help page for status indicators, including the graphics which were about a year out-of-date.

Internet - NetPlay
NetPlay is still in Mitchell’s hands.

PBEM
Nothing new.

Artificial Intelligence (AI)
I changed the fundamental data structure for the map so it can hold additional information on the geographical breakdown for the AIO. This should have zero effect on game play as far as human players are concerned. The change to the Terrain data adds a new field to each land hex to store the Land Region ID #. Along with this I added a new field to the Sea Area data to store the Sea Area Group ID #. And as the final pieces, I created simple Theater of Operation, Area of Operation, Land Region, and Sea Area Group files which hold the details on each of those elements, including cross references. In practice, this means that the AI Opponent code can trace any land hex back to its LR, AO, and TO, and can trace an all-sea hex back to its sea area, SAG, and TO. The AIO uses this data to ‘understand’ the map.

The greatest advantage that a human player has over the AIO is the ability to literally ‘see’ the map. For the AIO it is just a bunch of incohesive data. Using the newly added geographical data, the AIO can assess the strength of the forces on both sides in a land region and decide whether to attack, maneuver, defend, or retreat. The same applies to AOs, SAGs, and TOs. This is my best attempt to mimic a human player simply looking at the map and making a quick assessment of the relative strengths of the two sides.

In order to validate the new data I added a (debug) line under the Main form that shows and updates the TO, AO, LR, and SAG values as the cursor is scrolled across each hex. Peter is maintaining the data for those files, but Patrice has volunteered to do the hard task: entering a LR ID # for each land hex on the map (~20,000). I got this started by entering the data for Iceland (whoop-de-do!). I did that so I could test that the software found the correct LR name for each hex.

Peter continues to made excellent progress on the geographic breakdown for the AI Opponent with advice from Patrice and myself. To date, he has finished 8 of the 16 TOs: Western Europe, Eastern Europe (up to Siberia), Mediterranean, East Africa, West Africa, Middle East, South Asia (i.e., India), East Asia (i.e. China & Japan), and is working on Southeast Asia. The last includes the South China Sea, the Bismarck Sea, the Solomons, and the Marianas.

Rolf has made some progress on completing the parser for LAIO (Language for an Artificial Intelligence Opponent) scripts. That is slow going, which is understandable. There was a good reason why I stopped working on the parser where I did: the next step was really difficult.

Player’s Manual
I added a subsection on Dropping Off Units to the Players Manual. That form is used for both dropping off units and, when in port, picking up cargo while passing through. There were also a couple of changes to bring RAC up-to-date with MWIF deviations/interpretations from/of Rules as Written (RAW).

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Nothing new.

Communications
Nothing new.



8.4.5.3 Naval Movement
Group Movement
If you want to move several units as a group, you can either select them using the Flyouts form (see section 8.4.6), the Naval Review Details form (see section 8.7.1.10), the Units in Hex form (see section 8.7.1.24), or using Ctrl-Left-Click in the unit’s start hex (see section 11.8). All the units you select have to have started the impulse in the same: (1) hex or (2) sea area and section box. Once you have selected a group of units, you move them the same way you move a single unit.

Default Path
The easiest way to move a unit is to “pick one up” and left click on a destination hex or sea area. The program finds the fastest path that avoids interception by enemy units to the destination. Here fastest means the path that requires the fewest movement points. Visually the unit appears to ‘jump’ from its original hex or sea area to the destination hex or sea area.

Precise Path
If you do not want to use the program’s chosen path, you can control which ports or sea areas units enter by holding down the Ctrl key and left clicking on each port or sea area in the path you want the units to traverse. In fact, you can combine these two methods. For instance you could use the Ctrl key and click on the first hex in the path and then release the Ctrl key and click on a final destination hex or sea area several hexes away.

Entering a precise path for naval movement should only be used if: (1) you are moving a group of naval units and want to drop some of them off in a sea area or port, or (2) you are moving into a port to pick up cargo. The disadvantage of using the Ctrl key for naval movement is that those moves cannot be undone.

Transporting Units
There are various combinations of naval units and transported cargo, many of which are only possible when playing with optional rules. See the following optional rules sections for those details:
• 9.2.1 Divisions
• 9.2.4 Frogmen
• 9.2.15 Carrier Planes
• 9.2.16 V-Weapons
• 9.2.17 Atomic Bombs
• 9.2.21 The Queens
• 9.2.27 Supply Units
• 9.5.3 Amphibious Rules
• 9.5.4 SCS Transport

Here are the possible combinations:
• Naval transports can carry 1 corps/army sized land unit, land based air unit, supply unit, or V-weapon.
• Naval transports can carry 2 ‘division’ sized units. For this rule, carrier air units and atomic bombs are considered division sized.
• The Queens can carry 1 corps/army sized infantry class unit.
• The Queens can carry 2 division sized infantry class units.
• Amphibious units can carry 1 corps/army sized infantry class unit.
• Amphibious units can carry 2 division sized infantry class units.
• Surface Combat Ships (e.g., battleships, cruisers) can carry 1 non-motorized division sized infantry class unit.
• Carriers can carry 1 or 2 carrier air units provided the summed air classes of the carrier air unit(s) is less than or equal to the carrier’s air class.

Units are typically loaded in port during the naval movement phase immediately before moving the naval units transporting them. However, it is possible to load cargo onto naval units by “passing through” a port. A third way to pick up cargo as part of the naval unit’s move is to: move a naval unit from a port into a sea area, have the naval unit end its movement in the sea area, and then pick up cargo from a coastal hex. Finally, carrier air units can be loaded onto carriers during the Setup, Reinforcements, and Air Rebase phases. Carrier air units can also change which carrier is transporting them when the carrier air unit returns from an air mission or naval air combat.

All cargo is unloaded when a naval unit ends its move in a port. The sole exception is for carrier air units aboard carriers, which are only unloaded during: (1) the Remove Air subphase of the Reinforcement phase, (2) the Air Rebase phase, and (3) when flying an air mission or in a naval air combat. To be clear about this: carriers are the only naval units that may carry cargo (i.e., carrier air units) while in port.

Enemy Interception of Naval Moves
If you enter a sea area where enemy units can intercept your moving units, enemy players with units capable of intercepting are immediately asked whether they want to intercept. Regardless of their answer, at that point no previously made naval moves can be undone. This follows the general rule that once an opponent has to make a decision, no moves made previously can be undone.

If the naval interception is not attempted or fails, you have the opportunity to decide whether to have all your units stop in the sea area, continue moving all your units, or have some of them stop and have others continue moving. If the interception succeeds, you decide whether to have all your units stop in the sea area or to fight through. If you decide to fight through and survive the combat, you have the opportunity to decide whether to have all your units stop in the sea area, continue moving all your units, or have some of them stop and have others continue moving.

Sometimes you enter an enemy sea area even though you could go around it, because you want to take the most direct route to your destination. Remember, the default route avoids sea areas where enemy units are capable of intercepting the moving units, so it is quite possible that the default route uses more range and movement points.

Undoing Moves
As long as you do not use the Ctrl key for moving units and do not enter sea areas where enemy units are capable of intercepting your moving units, you can undo naval moves freely. This includes undoing moves where units were loaded from a coastal hex. If you use the Ctrl key to move surface naval units (i.e., not submarines), then that move cannot be undone. However, other naval moves made before and after using the Ctrl key can be undone freely.

The important point is that once a naval interception is possible, no naval moves made previously can be undone.

Overstacking
MWIF usually permits overstacking in ports during the naval movement and return to base phases. However, during the return to base phases, overstacking naval units in minor ports is not permitted. If you attempt to move units into ports where overstacking, a warning message that the hex will be overstacked is displayed. At the end of these phases, all stacking limits are enforced by the program and units in excess of the stacking limits have to be destroyed by their owners.

Naval Movement - in detail
The rules for naval movement are quite complex, primarily because of the possibilities of loading cargo, dropping off units, and being intercepted by enemy forces. On top of that there may be limits imposed on the number of naval moves permitted during the naval movement phase. The following enumerates all these possibilities.

There are 5 places in the sequence of play where naval units can move:
A. Naval movement phase.
A.1 From a port to a sea area.
A.2 From a sea area to a port.
A.3 Within a sea area, to a lower section box.
B. Return to base phases, from a sea area to a port.
C. Forced rebase due to the control of a port changing sides (e.g., overrun , conquest), from a port to a port.
D. Forced or voluntary return to base from a naval combat, from a sea area to a port.
E. Return to base by French naval units at sea during the formation of Vichy France, from a sea area to a port.

• Only A uses naval activities, and even then only when the major power owning the naval units took a Combined action.
• Only A.1 and A.3 permit a naval unit to end its move in a sea area. All the others must end in a port.
• Only A.1 permits loading a unit in port at the start of a naval move. Cargo must start the impulse in the port.
• Only A.1, A.2, and B permit loading a unit in a port while “passing through”.
• Only A.1 and A.3 permit loading a unit at sea at the end of a naval move.
• Only A.1 permits dropping off naval units in a sea area (using Ctrl-Left-Click). However, this can only be done if there are sufficient naval activities available.
• A.1, A.2, B, C, and D all permit dropping off naval units in a port (using Ctrl-Left-Click). However, during A.1 and A.2 this can only be done if there are sufficient naval activities available.
• For all moves except A.3 and E the player can specify which sea areas and ports the units traverse (using Ctrl-Left-Click).
• All except A.3 and E can be intercepted by enemy units.
• All naval moves in progress can be cancelled, unless units in the moving stack were previously dropped off, or the moving stack entered a sea area where it could be intercepted (regardless of whether it was or not).
• All completed naval moves can be undone, unless units in the moving stack were previously dropped off, or since the move was completed, any moving stack entered a sea area where it could be intercepted (regardless of whether it was or not).

Resolving interceptions of naval movement has the following logic branches:
1. Interception not attempted
1.1 All units continue moving (future movement by the units cannot be cancelled).
1.2 All units stop in the sea area. Only possible during A.1, loading units from coastal hexes permitted.
1.3. Some units stop and others continue moving. During A.1 this is only possible if sufficient naval activities are available.
2. Interception attempted
2.1 Interception failed
2.1.1 All units continue moving (future movement by the units cannot be cancelled).
2.1.2 All units stop in the sea area. Only possible during A.1, loading units from coastal hexes permitted.
2.1.3. Some units stop and others continue moving. During A.1 this is only possible if sufficient naval activities are available.
2.2 Interception succeeded
2.2.1 All units stop in the sea area.
2.2.2 All units “fight through”.
2.2.2.1 All units destroyed in naval combat
2.2.2.2 Combat resolved to quiescence and some moving naval units survive.
2.2.2.2.1 All surviving units continue moving (future movement by the units cannot be cancelled).
2.2.2.1.2 All surviving units stop in the sea area. Only possible during A.1, loading units from coastal hexes permitted.
2.2.2.1.3. Some units stop and others continue moving. During A.1 this is only possible if sufficient naval activities are available.

8.4.5.4 Air Movement
Default and Precise Paths
The path that an air unit takes is immaterial, unless you are playing with the optional rule En-route Aircraft Interception.

Group Movement
Air units are always moved one unit at a time, although they may be carrying cargo.

Undoing Moves
Air unit moves can always be undone during the subphase in which they are moved, unless you are playing with the optional rule En-route Aircraft Interception.

Return to Base Moves
One convenience for returning air units to base is available on the popup unit menu. If you Right-Click on an air unit that needs to return to base, one of the popup menu items is “Return from Whence”. Clicking on that returns the air unit to the location from which it began the air mission. Exactly where in the sequence of play air units return to base is varied, as explained below.

Returning a land based air unit from an air mission to a land hex is simple. You select the unit and drop it on the hex where you want it to land. For carrier air units, a form is displayed that lets you select on which carrier you want to land the unit. If only one carrier is available, then the program lands the carrier air unit for you automatically. In situations where you have multiple carrier air units to land or if there are multiple carriers on which to land, then the displayed form lets you choose which carrier air unit lands on which carrier.

Returning from a naval air combat is similar but more complex. There are 5 points where an air unit might return to base from a naval air combat:
a aborted due to an air-to-air combat abort result,
b aborted due to its side aborting from the air-to-air combat,
c bomber aborted due to an AA fire abort result,
d "returns to base" after a naval (air) combat round, and
e entire side voluntarily aborts from a naval combat.

For the purpose of this discussion, there are 3 'kinds' of air units. What happens to each of them when they return to base differs depending on circumstances.
A Land based air units present in a sea area section box that was included in the combat.
a, c, e returns to base in a land hex and become disorganized.
b, d 'return' to the sea area section box they w in when the naval air combat began (organized status unaffected).
B Carrier air units (when playing with the optional rule Carrier Planes) were aboard a carrier that was included in the combat.
a, b, d 'return' to any undamaged carrier on which they can fit (organized status unaffected).
c can not occur.
e 'return' to any undamaged carrier on which they can fit (organized status unaffected). The carriers then abort.
C Temporary carrier air units (when not playing with the optional rule Carrier Planes) were generated automatically by the program for each undamaged carrier that was included in the combat.
a, b, d removed from the game; their carriers’ organized status is unaffected.
c can not occur.
e removed from the game; their carriers’ organized status is unaffected, but the carriers then abort.
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

May 1, 2011 Status Report for Matrix Games’ MWIF Forum

Accomplishments of April 2011

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

There are 73 bugs remaining in the sequence of play. I had the count down to a low of 71 this month. Half of these concern Production Planning (30) and Production (5), with the latter almost certainly caused by the problems in the former.

Rolf has been working on converting some old CWIF code so it will run under NetPlay. Mitchell’s home and work life have consumed his time this past month, leaving none for MWIF.

Hardware and Software
The open items for Theme Engine are: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file). Neither of these is a crucial.

Beta Testing
I released versions 8.01.01 (23 fixes), 8.01.02 (5 fixes), 8.01.03 (9 fixes), 8.01.04 (10 fixes), 8.01.05 (17 fixes), 8.01.06 (27 fixes), 8.01.07 (15 fixes), and 8.02.00 (12 fixes) to the beta testers last month. I’ll upload version 8.02.01 (10 fixes) later today. This totals 9 new versions and 128 fixes, which is above my average number of fixes for a month. I changed the numbering to 8.02.00 because the number of patches was growing too large.

I’ve decided to give you a look into what I mean by fixes. I usually try to write a summary of all those fixes, but for this month I’ll let you read to gory details. Doing this took me very little time, since I prepare these lists for the beta testers every time I upload a new version. The full set of changes for the month is appended to this report.

Beta Testing Team - 2011
Just in case there any misconceptions about this, I do not work alone. Over the years there were/are more than 60 people (unpaid volunteers) who have been involved with beta testing and other aspects of MWIF. I have been terribly remiss in not mentioning them more often. For many, I could write pages of text and still only lightly cover their contributions. In the interest of brevity, for this report I have restricted myself to just the people who have been active in 2011 (and I truly hope I haven’t omitted anyone). Furthermore, I have imposed a limit on myself of 1 sentence per person. So, in alphabetical order:

Aaron (newest beta tester) tests the program 10+ hours a day, everyday, since he started a couple of weeks ago.
Adam (beta testing many years) has done extensive work authoring new land unit writeups.
Bjorn (beta testing several years) tested Barbarossa, (by-passing innumerable bugs) to completion, amongst other accomplishments.
Christian (beta testing several years) tests a variety of phases in the sequence of play.
Dave (beta testing < 1 year) testing naval combat.
Eric (beta testing many years) tests a variety of phases in the sequence of play.
Geoff (beta testing many years) tests Guadalcanal and naval operations heavily.
Giancarlo (new beta tester) just getting started.
Graham (beta testing many years) originated the idea of unit writeups and did all the original ones for all the air units and the 67 HQs.
Jeffrey (new beta tester) just getting started.
Lars (CWIF beta tester) immediately tests every new version as soon as I upload it, diligently checking whether I have fixed the bugs he has previously reported.
Matthew (new beta tester) just getting started.
Michael (beta testing many years) tests deep into scenarios, (by-passing innumerable bugs), especially land operations, to the point that major powers are conquered, or surrender, and/or are liberated.
Mitchell (programming help) has worked on the NetPlay communications technical code and resolved very difficult problems with Theme Engine.
Nils (beta testing many years) a very thorough tester of naval operations who double checks that a bug is actually fixed after I say I have fixed it.
Patrice (CWIF beta tester) has assumed all responsibility for the map and unit data, in addition to being my primary liaison with Harry Rowland at Australian Design Group.
Paul (CWIF beta tester) one of my main resources for WIF FE rule clarifications.
Peter (CWIF beta tester) working on the AI Opponent scripts.
Rob J. (beta testing many years) has assumed complete responsibility for the naval unit writeups and has written the vast majority of them.
Rob W. (new beta tester) tests a variety of phases in the sequence of play.
Rolf (programming help) has worked on the AIO parser and converting CWIF code for use in NetPlay.
Thomas (beta testing < 1 year) tests a variety of phases in the sequence of play.

Without the help of these individuals, and all the others in previous years, I would never have been able to get this monster of a game as close to being finished as I have. Truly, giving them sufficient praise and thanks is beyond me.

Saved Games
Nothing new.

Map and Units
Rob and Adam continue to send me new and/or updated naval and land unit writeups, respectively.

Scenarios and Optional Rules
Nothing new.

MWIF Game Engine and CWIF Conversion
Did some work on getting Search and Seizure to function. It can now identify when a search and seizure is possible and which major powers get to make those decisions. I still need to write new code to effect the results of search and seizure. Because that is closely related to Production Planning and am going to wait on working on the rest of S & S until I have PP bug-free.

Player Interface
Made some good progress on Head2Head (a.k.a., HotSeat) play with the help of Orm.

Internet - NetPlay
Rolf is working on the conversion of CWIF’s Windows Messaging code for communicating over the internet with MWIF’s Game Record Logs. I need to process the set of source code changes he sent me today.

PBEM
Nothing new.

Artificial Intelligence (AI)
Peter continues to made excellent progress on the geographic breakdown for the AI Opponent with advice from Patrice and myself. To date, he has finished 12 of the 16 TOs: Western Europe, Eastern Europe (up to Siberia), Mediterranean, East Africa, West Africa, Middle East, South Asia (i.e., India), East Asia (i.e. China & Japan), Southeast Asia, Oceania (i.e., Australia), Pacific Ocean, and North Asia (i.e., Siberia). All that remains are two TOs in the Americas and two in the Atlantic Ocean.

I still need to pick up the LAIO parser where Rolf left off. But that won’t happen until I kill off the last of the sequence of play bugs.

Player’s Manual
I made a couple of changes to bring Rules as Coded (RAC) up-to-date with MWIF deviations from Rules as Written (RAW). I also inserted the bibliographies from Adam Scott and Wosung on their writeups for the land units.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Nothing new.

Communications
Nothing new.



Changes Since Versions 08.01.00
(as of April 8, 2011)

(1) I fixed the FTC problem with moving a minor country HQ into a minor country aligned to the same side (Michael, 7.01.03, Post #14; Michael, 8.01.00, Post #1).

(2) Modified the Overstacked form so only 1 unit can be selected at a time (Orm, 8.01.00, Post #17).

(3) Modified the text in RAC to clarify when rebasing a carrier air unit does not count against air mission limits (Orm, 8.01.00, Post #20). I also edited the text for the change in US entry marker distributions (Nils, 8.01.00, Post #30). The latter modification required a change in section 10 of the Players Manual which lists all the deviations from RAW.

(4) Added Auxiliary Cruisers to the Selectable Units form filters (Michael, 8.01.00, Post #35).

(5) Modified the code so the units that voluntarily abort from a naval combat force all units on the same side to abort except those belonging to a neutral major power or are uncommitted submarines (Nils, 8.01.00, Post #48; Doktor, 8.01.00, Post #82).

(6) Added code so carrier air units aboard carriers do not count towards foreign troop commitments (Orm, 8.01.00, Post #16).

(7) Corrected the determination of which resources and factories are in play for Barbarossa (Eric, 8.01.00, Post #10). This should also fix any problem with same for the half map scenarios (Guadalcanal does not use production planning). There were two problems: (1) Ukraine was not being included in the list of resources because the Ukrainian units are not part of Barbarossa, and (2) too many resources and factories were available in the summary information (e.g., Germany was getting credit for all the resources and factories in Germany).

(8) I made about 50 edits to support head-to-head play. These should have no effect on the other modes of play, but should handle all the places where the side changes. The Switch Sides form should appear in all the correct places (Orm, 8.01.00, Post #18).

(9) Fixed a weakness in checking if a unit was on a carrier where old/damaged saved games could generate a fatal crash when restored.

(10) Fixed a bug in Flyouts where picking up a transported unit did not record the hex from which is was picked up correctly.

(11) Enabled using the Naval Review Details form for selecting carrier air units for rebasing (Orm, 8.01.00, Post #19).

(12) Corrected the air mission count so it is not reduced when a carrier air unit rebases to another carrier in the same sea area section box (Orm, 8.01.00, Post #21).

(13) Made a small change to the Anti-Aircraft Fire form to enable the buttons as soon as the form is shown (Orm, 8.01.00, Post #23).

(14) Fixed the problem with Previous/Next where it would always go to the last moved unit if that unit has movement points remaining (Michael, 8.01.00, Post #32). Now it only does that if the unit just performed an overrun.

(15) Restored the missing line of code so the movement points expended to reach a hex during land movement is displayed correctly (Orm, 8.01.00, Post #96).

(16) Fixed the bug with restoring a saved game in the naval combat phases where sometimes the deciding major power/side was wrong (Lars, 8.01.00, Post #54; Orm, 8.01.00, Post #63).

(17) Removed a couple of blinks from the Load Saved Game - which were very annoying (Grotius, 7.02.02, Post #30).

(18) I inserted a call to recompute all Foreign Troop Commitments after the last unit has been set up (RedoAllFTC). I am not sure if this was the problem, but I have found that saved games worked correctly in calculating FTC, so my guess is that adding the same call that is used when a game is restored should solve this problem (Peter, 8.01.00, Post #85; Orm, 8.01.00, Post #84).

(19) Removed some CWIF code which was redundant/conflicting with new code I had added for handling multiple DOWs on/by major powers (Michael, 5.03.02, Post #18; Orm, 8.00.06, Post #44).

(20) Added a check so that after a naval interception combat in which moving units were sunk, the sunk units are not part of the Continuing On Stack (Nils, 8.01.00, Post #41).

(21) Revised page 1 of tutorial 5 so it gives some information about ASW factors (first impressions from Dr. S).

(22) Standardized the order in which the calculations are made in the Spend Surprise Points form. This should correct the irregularities in the estimated results (Nils, 8.01.00, Post #46). I left intact the ability to apply columns shifts to both your own and the enemy’s attacks simultaneously. We had had a discussion about this previously and my decision was that a player may want to see the effect of applying both shifts before deciding where to spend the available surprise points.

(23) Fixed the bug in Naval Movement where intercepted naval units, when the interception attempt failed, disappeared (Nils, 8.01.00, Post #42; Michael, 8.01.00, Post #55; Lars, 8.01.00, Post #61; Doktor, 8.01.00, Posts #81 & #98; Orm, 8.01.00, Post #95).

Changes Since Versions 08.01.01 & 8.01.02
(as of April 10, 2011)

(1) Corrected the Theme Engine background colors when restoring a saved game (Peter, 8.01.01, Post #1).

(2) Fixed the problem with FTC between minor countries (Peter, 8.01.01, Post #2). The problem here was that Ethiopia is on the Allied side but the Ethiopian territorial units are on the Axis side.

(3) Added a check that the optional rules for pilots is being used before giving minor countries extra pilots when they enter the war (Lars, 8.01.01, Post #3).

(4) Removed the diagnostic messages for naval moves (Lars, 8.01.01, Post #3).

(5) Removed a couple of spurious blinks of the whole screen when a new game is created.



(6) Fixed the problem with determining maximum sea box section after units have already been dropped off in a previous sea area (Nils, 8.01.00, Post #37).

(7) Fixed the problem in Naval Movement where after the enemy declines to intercept and units are dropped off, a selected unit could not be unselected (Nils, 8.01.00, Post #38). This also fixed the problem with unselected units not appearing as part of the Continuing On Stack.

(8) Fixed the bugs in the Select Naval Combat form in which the name of the deciding major power was wrong (Lars, 8.01.01, Post #9).

(9) Corrected the Unit Menu processing so when a land based air unit is returned to a land hex using the Return From Whence, a call is made to check for enabling the end-of-phase button (Doktor, 8.01.00, Post #107).

(10) Fixed the problem with determining maximum sea box section after units have decided to stop after being intercepted (Doktor, 8.01.00, Post #108).

(11) Added a check for a DOW on a minor country that is already in the war so an aligning major power is not asked again. This change is preparatory for implementing 2 DOWs on the same minor country in a turn.

(12) Caused a DOW on the same minor by 2 major powers in the same impulse to cause 2 US Entry Chits to be drawn (Orm, 8.01.00, Posts #112 & #114).

(13) Added code to clear the Selectable Units form at the start of NavalCombatA/D (Lars, 8.01.01, Post #13).

(14) Fixed the bug with moving loaded naval transports using the Flyouts form (Michael, 8.01.02, #1).

Changes Since Versions 08.01.03
(as of April 12, 2011)

(1) Fixed a couple more problems in dropping off units after a naval interception. The units dropped off and those continuing on no longer double count the cost of entering the interception sea area (Nils, 8.01.00, Post #39).

(2) Replaced the icons for damaged oil resources and major ports so the diagonal slash is colored red as it should be (Michael, 8.01.00, Post #115).

(3) Fixed the bug in drawing captured major ports so they are now shown as damaged (Michael, 8.01.00, Posts #70 & #115).

(4) Fixed the bug where light cruisers were selected in the SelectUnits form by mistake (Michael, 8.01.03, Post #1).

(5) Fixed the bug with moving units by rail through Sweden (Michael, 8.01.03, Post #2).

(6) Fixed the problem with Poland not being aligned to the Commonwealth (Doktor, 8.01.03, Post #5).

(7) Fixed the problem in Production where the number of build points that Germany could save was incorrect (Doktor, 8.00.00, Post #18; Doktor, 8.01.00, Post #6).

(8) I added a warning message when moving naval units into a port causes overstacking (Michael, 8.00.08, Post #28). The player can either confirm the move and voluntarily cause overstacking, or not.

(9) Added a dozen or more land units writeups from Adam.

(10) Fixed the problem with Air Rebase where undoing air rebase moves could be used to overstack air units on a carrier (Orm, 8.01.00, Post #22). I am not sure if this fixes the other problem with carrier air units ending up in the wrong hexes (Orm, 8.01.00, Posts #24, #26, #27). Unless I hear otherwise, I am assuming it does.

Changes Since Versions 08.01.04
(as of April 17, 2011)

(1) Fixed the problem with modifying trade agreements not working (Lars, 8.01.04, Post #3).

(2) Enabled the Initiate Naval Combat form’s UnitData panel to show the summary information for all units in the sea area when the cursor is not over an individual unit (Michael, 8.00.,06, Post #13).

(3) Fixed the bug with Anti-aircraft fire (Doktor, 8.01.03, emailed game).

(4) Fixed the problem with Naval Air Support so supply is recalculated after each air unit is flown for naval interception combats (Nils, 8.01.00, Post #43).

(5) Fixed the problem with intercepted naval units where after a successful interception, the search roll was applied to the wrong side (Nils, 8.01.00, Post #40).

(6) Fixed the problem with artefacts appearing when moving units (Lars, 5.02.00, Post #5; Lars, 6.00.00, Post #24, and numerous others). I had a minor celebration after solving this. I had spent time on it in August and then 4 days straight in October with limited success (I could choose between incessant blinking or artefacts). This time I spent 4 more hours split between a late night and early morning stints and got it to perform as desired. In fact, screen refresh when moving the cursor around on the map appears smoother to my eye. Note that I still do not understand exactly what is going on. The internals of how Windows processes mouse interrupts and screen refreshes is enclosed in a black box from my point of view.

(7) Fixed a problem in air-to-air combat where carrier air units were returned to carriers prematurely. This only happened after a non-carrier air unit aborted from an air-to-air combat (Nils, 8.01.00, Post #45; Nils, 8.00.02, Post#14; Doktor, 8.00.00, Post # 2).

(8) Added code so carrier air units that are still flying at the end of a naval combat round perform a return to base digression. For clarity, this phase of the game is shown as “Return to Carriers”, although it executes using the return to base digression code ().

(9) Removed the check after combat losses in an air-to-air combat where bombers were cleared through because there were no enemy fighters. This check now only occurs at the start of an air-to-air combat round (Nils, 7.02.00, Post#43; Orm, Rule Questions, Post #721).

(10) I believe I fixed (in a previous version) the problem in Naval Combat where after both sides have aborted from a naval air combat, only one side got to return their units to base. The other side’s units still needed to abort, but the first side got to select another sea area for combat (Nils , 7.04.05, Post #17 ).

(11) Fixed a bug where carrier air units that had returned to their carriers were still marked as ‘flying’.

(12) Added a check so carrier air units are not shown in the Choose Carrier form in the list “Ineligible Carrier Units”.

(13) Fixed a bug in the Naval Combat Results form where carriers were shown transporting carrier air units that were “in the air”; that is, the carrier air units were flying in a naval air combat.

(14) Added a line of code so when convoys belonging to another country than the controlling major power are split, the newly created convoys have both the same Source Country and the same Current Country (Michael, 8.01.04, Post #).

(15) Added a check for carriers that have aborted during the current naval combat so their carrier air units can no longer be used in subsequent naval air combats (Lars, 2.01.00, Post #47). Note that if a carrier that aborts enters a new sea area and another naval air combat occurs, its carrier air units are available to fight.

(16) Fixed the bug in Naval Combat where land based naval air units that aborted as part of a side aborting could not be returned to base (Lars, 7.04.01, Post #25; Grotius, 8.00.00, Post #11).

(17) Solved several problems in Naval Combat where a Return to Base Digression from an air-to-air combat brought the game to a halt (Nils, 8.00.02, Post#14; Doktor, 8.00.08, Post #25; Nils, 8.01.00, Post #44).

Changes Since Versions 08.01.05
(as of April 24, 2011)

(1) Added code to destroy all transported units when a naval unit is destroyed (Lars, 2.01.04, Post #46).

(2) Fixed the Surrender code so major powers that surrender can still be incompletely conquered (Michael, 8.01.04, Post #38).

(3) Fixed the problems with US Entry causing the program to hang when playing the half map scenarios (Doktor, 8.00.08, Post #37; Doktor, 8.01.02, Post #5).

(4) Fixed the code so naval units could be overrun and forced to rebase multiple times (Orm, 8.01.05, Post #7; Lars, 8.01.05, Post #110).

(5) Fixed a problem with the Flyouts form where a transported unit could be selected during Land Movement - and probably during other phases when they should not have been selectable (Aaron, 8.01.04, emailed bug report.).

(6) Added another check for a valid route when the Animate Route box is checked in Production Planning (Aaron, 8.01.04, emailed bug report).

(7) Corrected a MadExcept error in the Production phase when a Supply Unit was built (Aaron, 8.01.04, emailed bug report).

(8) Fixed a bug in the Naval Abort Queue form where clicking on a flag referenced the wrong major power (Aaron, 8.01.05, emailed bug report). This fixes the problem that Nils encountered with the buttons doing nothing (Nils, 7.02.01, Post #10; Nils, 7.04.03, Post #52).

(9) Added another check to avoid MadExcept errors when closing the program (Rob W., 8.01.03, emailed bug report).

(10) Added some more AutoSave locations: before each major power decides Choose Action, Return To Base, and Stay At Sea. These all contain the name of the major power (Orm, 8.01.05, Post #9).

(11) Added a line of code to fix the problem with Return From Whence not enabling the end-of-phase button (Doktor, 8.01.05, Post #29). I am not sure that this solves the problem, but if it doesn’t, then I would like a saved game so I can find a fix that does.

(12) Enabled the AOI territorial to be placed on the map as a reinforcement (Michael, 8.01.05, ).

(13) Added a text message to the form that reports when reinforcement units are being moved to arrive the following turn because presently there is no hex in which they can be placed.

(14) Fixed a couple of problems with how reinforcement units that are unable to be placed on the map are processed. This resolves a bug from 2006!!! (April 3, 2006, Terje437; Lars, 7.04.00, Post #9).

(15) Fixed a bug so when multiple neutral naval units are moved in a stack, the count of naval unit moves used isn’t decremented multiple times (Aaron, 8.01.05, Post #75).

(16) Fixed a bug so zero factor partisans can be overrun (Lars, 8.01.05, Post #57).

(17) Disabled bringing up the Plot AA Fire form if it is already visible. This prevents ‘firing’ the same unit multiple times (Aaron, 8.01.05, Post #78).

(18) Fixed a bug in Plot AA Fire where the selected hex was not highlighted. I also widened the form so the effect of the AA fire was fully visible.

(19) Added code to initialize the production points received from Food In Flames (Aaron, 8.01.05, Post #98 and emailed bug report #24).

(20) Added a check for visible component in the Production Planning form to avoid a MadExcept error (Aaron, 8.01.05, bug report #13).

(21) Added a check for a non-nil resource when displaying Routes in the Production Planning form (Aaron, 8.01.05, Email bug report #14).

(22) I am ignoring a MadExcept error that occurred after using the Debug Place form. Apparently some internal variables got messed up - which the Debug Place is quite capable of doing (Aaron, 8.01.05, email bug reports #20 and #21).

(23) Added a check in Production Planning when sorting a resource with no owner (not controlled by a major power), to avoid a MadExcept error (Aaron, 8.01.05, email bug reports #22 and #23).

(24) Removed the Netherlands East Indies from the list of valid countries for the Fascist Tide scenario (Doktor, 8.01.05, Post #105).

(25) Fixed the background color for the Selectable Units form (Nils, 8.01.05, Post #55).

(26) Added a few more checks for nil variables when destroying the game. This time it was for when the Plot AA Fire form was still visible.

(27) Made numerous changes to enable plotting AA fire when a single AA unit has multiple target hexes available. However, the Cancel button doesn’t work correctly on that form yet.

Changes Since Versions 08.01.06
(as of April 27, 2011)

(1) Added a line of code so Partisan units do not show up in the Scrappable list (Lars, 8.01.05, Post #115).

(2) Added a couple lines of code so when the flags are clicked on in the Naval Abort Queue form, the Current Flag changes and so does the internal variable tracking the current major power - so it matches LocalMajorPower, i.e., the current decision maker (Nils, 8.01.06, Post #4).

(3) Finally fixed the bug in Plot AA Fire so the Cancel button works correctly (Aaron, 8.01.05, Post #78).

(4) Fixed the bug with counting movement points for naval units after dropping some units off in a sea area (Nils, 8.01.05, Posts #54 & #103).

(5) Fixed a problem with Food in Flames counts (Aaron, 8.01.05, Post #11).

(6) Fixed the problem in Naval Combat abort digression where after aborting a NAV, the game stopped (Doktor, 8.01.05, Post #44; Nils, 8.01.05, Post #53; Lars, 8.01.05, Post #58; Aaron, 8.01.05, Posts #47, #49, & #71).

(7) Updated the Sequence of Play form to include the new phases added to the End of Turn Stage a few months ago: production planning final, search and seizure, and scrap destroyed units.

(8) Fixed the problem with finding a new home country when a major power surrenders (Lars, 8.01.05, Post #114).

(9) Added a line of code so once naval units are removed from the NavalAbortQueue form they are also removed from the NavalAbortQueue itself (Aaron, 8.01.05, Post #121; Cad908, 8.01.06, Post #31).

(10) Updated the AIO’s SAG data with the latest from Peter (April 26, 2011).

(11) Fixed the Search and Seizure code so it correctly displays where S & S can be performed. You still can’t actually execute a S & S, but at least the program identifies where it is possible and who the interested parties are (Aaron, 8.01.05, Posts #81 & #83).

(12) Removed US Entry Options Occupy Greenland & Iceland and Occupy Northern Ireland from the DOW Minors form Special Actions. Instead these are processed like any other US Entry Option (Michael, 8.01.06, Post #23; Aaron, 8.01.05, Post #27).

(13) Eliminated the DOW Minors phase for the US player unless he has chosen the US Entry option to declare war on minors (Michael, 8.01.05, Post #6).

(14) Fixed a bug in Use Oil where the unit selection was always on the first unit and the program did not reset the selected unit when a different one was clicked on. This also solved the problem with using the mouse wheel to scroll the unit list. There was no bug related to reorganizing the French units - it is simply that the units’ changed organization status is not effected until the end of the phase by all major powers (Doktor, 8.01.06, Post #9; Doktor, 8.01.05, Post #52).

(15) Made several changes to Vichy Creation so stacking is checked. Previously, in some situations, stacking was not checked when determining possible destination hexes; but then it was checked when the player tried to actually put the unit in the destination hex. This could result in the only ‘legal’ hex being one in which overstacking would occur. I straightened this all out - I hope (Lars, 8.01.03, Post #18; Lars, 8.01.05, Post #17; Cad908, 8.01.05, Post #36).

Changes Since Versions 08.01.07
(as of April 29, 2011)

(1) Added a check for no assigned destination when saving oil during Production Planning. This prevents a MadExcept error (Aaron, 8.01.06, emailed bug report #37).

(2) Added a check when creating Vichy France for a French controlled possession having just been conquered. Previously the newly conquered possession was processed to determine which Axis major power gained control of it. That caused a MadExcept error (Aaron, 8.01.06, emailed bug report #43).

(3) Removed some of my diagnostic messages when creating Vichy France.

(4) Fixed the problem with NEI being conquered at the start of Missed the Bus (Aaron, 8.01.07, emailed bug report).

(5) Updated the bibliographies for the unit writeups with those used by Adam Scott and Wosung.

(6) Added a check for nil stack in the Selectable Units form to avoid a MadExcept (Aaron, 8.01.07, emailed bug report #48).

(7) Aaron has been trying to recreate some old bugs for me. He says the following 2 no longer occur: Conquest of Rumania by the USSR - after demand for Bessarabia was denied, caused a MadExcept error (Lars, 7.02.01, Post #37); and Germany unable to enforce - Finnish-Russian peace (Michael, 2.00.02, Post #34).

(8) Fixed the problem with Head2Head play in Production Planning Prelim where switching sides once one side had complete the phase did not occur (Orm, 8.01.06, Posts #2 & #20). This also affected a lot of other phases: Production Planning Final, Scrap Destroyed Units, Search and Seizure, Intelligence, Production, Use Oil, Neutrality Pact chit draws, Reform, Breakdown, Naval Repair, Partisans, Factory Destruction, Reinforcements, Lending, when terminating a Naval Combat, when choosing a carrier on which to land at the end of a Naval Air Combat, and when choosing a plane role for a naval air combat.

(9) Added a check for no units present before updating a stack viewer (Michael, 8.01.07, emailed bug report). This occurred during the end of the Factory Destruction phase.

(10) Added a check to avoid a MadExcept error when updating the Flyouts. This came about during the Surrender Phase but what the original cause of the problem was is not clear (Aaron, 8.01.07, emailed bug reports #52 and #57).

(11) Added a check to the Units In Hex form to avoid a MadExcept error when there are no units in the unit list. This occurred during the Surrender Phase, although I have no idea what was its original cause (Aaron, 8.01.07, emailed bug report #56).

(12) Added a check for completely conquered major powers so they do not participate in the Choose Action, Use Oil, Production Planing Prelim & Final, and Production phases (Aaron, 8.01.07, emailed bug report).

Changes Since Versions 08.02.00
(as of April 30, 2011)

(1) Added some more checks to Flyouts to avoid MadExcept errors (Michael, 8.02.00, emailed bug report).

(2) Added some more checks to Production Planning to avoid MadExcept errors when no default destination has been defined (Dave, 8.02.00, emailed bug report).

(3) Updated the land unit writeups with the latest from Aaron (April 30, 2011).

(4) Corrected the bug where the USSR was permitted to DOW Rumania even though they had not yet claimed Bessarabia (Orm, 8.02.00, Post #5).

(5) Fixed a bug in Head2Head play where multiple switches between the sides could lose track of which major power on a side should be deciding (Orm, 8.02.00, Post #7). This occurred in the following sequence: USSR claims Finnish Borderlands, switch to Germany, Germany denies the claim, switch to US, US draws a chit, switch to Germany to report how many chits removed, switch to USSR, USSR continues DOW on minors. The program had been partially switching to Commonwealth at the last point.

(6) Added a check for moving convoys so that they do not automatically go into sentry mode when stopping in a port. They still automatically go into sentry mode when stopping at sea (Michael, 8.02.00, Post #19).

(7) Fixed a nasty little bug where if a unit left port loaded (e.g., a carrier air unit on a carrier), stopped in a sea area so another unit in the stack could load a unit from a coastal hex, then the original transport and its cargo became disassociated (Lars, 8.01.06, Post #30; Lars, 8.02.00, Post #20).

(8) Added a check to the Flyouts form to avoid a MadExcept error (Aaron, 8.01.07, Post #20, BugReport50).

(9) Corrected a bug in USA DOW on Japan where failure was reported as a failed attempt to DOW France.

(10) Fixed a bug where an extra entry chit was drawn when the USA failed in an attempt to DOW an Axis major power (Michael, 8.01.07, Post #24).
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

June 1, 2011 Status Report for Matrix Games’ MWIF Forum


Accomplishments of May 2011


Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Rolf did a lot of work on converting old CWIF code so it will run under NetPlay - I incorporated that into the master source code this month.

Hardware and Software
The open items for Theme Engine remain unchanged from last month: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file). Neither of these is important.

Beta Testing
I released versions 8.02.01 (16 fixes), 8.02.02 (1 fix), 8.02.03 (15 fixes), 8.02.05 (7 fixes), 8.02.06 (18 fixes), 8.02.07 (17 fixes), 8.03.00 (9 fixes), 8.03.01 (16 fixes) and 8.03.02 (16 fixes) to the beta testers last month. This totals 9 new versions and 115 fixes, which is slightly under my average number of fixes for a month. Mostly that is because the one change for version 8.02.02 was to incorporate all the modifications that Rolf provided, which converted CWIF code to MWIF Game Record Logs to support NetPlay. More on that below.

There are 75 bugs remaining in the sequence of play. Most of these are in the End-of-Turn phases. For example, Production Planning has 26, Production has 2, Conquest/Surrender has 3, Vichy has 3, and Liberation has 6. As for the impulse phases, Naval Combat has 12, Land Movement 4, and Air Missions 8. The air mission bugs are roughly half for very unusual circumstances and roughly half not reproducible. I am gradually transferring “not reproducible” bugs to their own category. I keep them around for a while to see if someone reports the same problem occurring again. Eventually I remove them completely as inexplicable - and probably a consequence of some other bug that had occurred earlier in the game.

Saved Games
Nothing major, just a few small tweaks to the format to support new variables and 1 bug fix.

Map and Units
Rob and Adam continue to send me new and/or updated naval and land unit writeups, respectively. I also corrected some data problems for City Based Volunteers.

Scenarios and Optional Rules
I made some progress on City Based Volunteers (there is still more to do) and fixed the remaining reported bugs in Warlords. I also did quite a bit of work on fixing bugs in the intersection of the Off City Reinforcements rules with other optional rules (e.g., Territorials). Both of those are now bug free to the best of my knowledge. There was also a bug in the later scenarios for setting up the Polish mechanized unit.

MWIF Game Engine and CWIF Conversion
Set NetPlay below.

I (well, actually it is usually a beta tester) keep finding places where the CWIF code did not handle all possible cases. These are unusual circumstances where the WIF FE rules are stretched to their breaking point.

For instance, minor country units are not permitted to enter the home country of another minor country on the same side unless Foreign Troop Commitment requirements have been met. That rule stops Hungarian units from entering Rumania, as one example. But in the case where the second minor country has been completely conquered, it seems that entry should be permitted. In one of the beta testers’ games the USSR had conquered Persia (which aligned to Japan) and then Italy aligned Iraq and had Iraqi units ready to enter and liberate Persia. Here the general rule would prohibit Iraqi units (minor country aligned to Italy) from entering Persia (minor country aligned to Japan, on the same side as Italy). But since Persia is completely conquered, it is now ‘owned’ by the USSR, with which Italy is at war, hence the Iraqi units are free to enter Persia. At least that is how I have coded it. My change is that if a minor country on your side has been completely conquered, then the FTC requirements no longer apply.

Another example is when the Collapse of Vichy France causes Vichy France controlled minor countries to become owned by an Axis major power which has a unit present in the minor country. For instance, if Italy has a unit in Vichy France controlled Tunisia, then the rules state that Tunisia goes to Italy. But the rules say nothing about if there are both German and Italian units present. I decided to count the number of units and ‘give’ the country to the Axis major power with the most units present.

Both the above examples are not covered by the WIF FE rules, so I put in additional code to cover these gaps in (what I consider) a reasonable manner.

Player Interface
I had to update the Unit Status Indicators yet again. There was a ‘hole’ in the logic so that land based air units at sea during naval combat, which were not participating in the combat, were shown without any status indicator. I added a new value for these units to indicate that they are still ‘flying’, if they are not part of the naval combat.

One of the goals I have for Production Planning is for a player to set up all his convoy routes and then use them turn after turn, with only minor tweaking necessary. That objective ran into trouble with the 4 NEI oil resources, where often in a game 2 are suppose to go to Japan and 2 to the Commonwealth. The difficulty was that which oil resources are assigned to whom might change from turn to turn, so the oil that had been routed by the Commonwealth to India last turn, can end up in being assigned to Japan in the next turn. Really this is a big mess to sort out in any simple way. The presence of partisans might prevent one or more of the oil points from being available. Combine that with the requirement that Japan gets its 2 oil points first and which major power sets up the partisans, and every neat little solution falls apart. I’m still working on this - for now I am simply sending the Palembang oil points to the Commonwealth and the other 2 to Japan. I’ll come back to this someday; but I do not deem ‘fixing’ this as crucial for releasing the game.

Internet - NetPlay
Rolf did a lot of work converting 20 routines from CWIF code to MWIF Game Record Logs. He tackled some of the most difficult items which involve moving units. There are less than 80 remaining to be converted. I will finish those off this month, hopefully with Rolf’s help.

Next month I plan on spending about half my time on NetPlay and half on fixing bugs in the sequence of play. It would be nice if I could get the code to the point that two beta testers could start running Barbarossa over the internet in June.

PBEM
Nothing new.

Artificial Intelligence (AI)
Peter is close to finishing the geographic breakdown for the AI Opponent. He has just one left to do: Atlantic South America. I still need to pick up the LAIO parser where Rolf left off. But that won’t happen until I kill off the last of the sequence of play bugs.

Player’s Manual
I made a couple of changes to bring Rules as Coded (RAC) up-to-date with MWIF deviations from Rules as Written (RAW). I also updated the bibliographies from Robert Jenkins for his writeups for the naval units.

Aaron has been reading through the largest section of the Players Manual: 8 Players Interface. He has been making some edits to the text, which he sends me as replacement paragraphs. There is also a lot of work remaining on updating screenshots of the forms. As Aaron as noted, I keep making small tweaks to them, so the accompanying text usually needs comparable modifications. I am not making a major push on this right now, but I like to keep whittling away at it so the effort required to polish it up for final release will be minimal.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Nothing new.

Communications
Nothing new.
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

July 1, 2011 Status Report for Matrix Games’ MWIF Forum

Accomplishments of June 2011

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Rolf fixed a couple of bugs in the sequence of play (yay!). Mitchell is revising the stand alone program NetPlayComTest, which he should be ready to incorporate into MWIF proper the first week of July.

Hardware and Software
The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file). Neither of these is important. I bought Aaron a copy of HyperSnap so he could retake all the screenshots for the Players Manual.

Beta Testing
I released versions 8.03.03 (3 fixes), 8.03.04 (15 fixes), 8.03.05 (3 fixes), 8.03.06 (9 fixes), 8.03.07 (15 fixes), 8.03.08 (3 fixes), 8.04.00 (9 fixes), 8.04.01 (2 fixes), 8.04.02 (14 fixes) and 8.04.03 (6 fixes) to the beta testers last month. This totals 10 new versions and 79 fixes, which is way under my average number of fixes for a month. That’s because some of those ‘fixes’ were changes to multiple places in the code to accommodate NetPlay. In total, I made 79 changes to convert the last of the CWIF code to MWIF Game Record Logs to support NetPlay. Those changes for NetPlay sometimes introduced fatal bugs - hence the quick uploads or new versions that contained only 2 or 3 fixes.

There are 83 bugs remaining in the sequence of play. I keep driving the number down to the low 70's and the beta testers drive it back up to the low 80's. Sooner or later they have to run out of obscure things to find. During the past month I made changes for:
• Splitting convoy units when using the Pools form, so the arrival year is now correct.
• Japan sending a saved oil point to Italy and Italy using it in production.
• Building units ahead where sometimes the program mistakenly took a unit even further ahead than intended.
• Selecting which one of multiple conquered units arrives as a reinforcement.
• Checking French Foreign Troop Commitment in the United Kingdom after the UK has been conquered and some hexes retaken by the US. Since the US owns the hex, the French do not have to check FTC. When the Commonwealth retakes a hex, the French do have to satisfy FTC.
• Collapsing Vichy France so Vichy French naval units in the Construction and Repair pools are transferred to the ownership of the major power that collapsed Vichy France.
• Checking the Naval Combat Abort Queue processing so units that do not cooperate can no longer be moved into the Chosen to Abort Group. This prevents problems later when they would be unable to stack in the same port.
• Processing the naval abort queue so if a second naval combat occurs while there are still units in the queue from the first naval combat, then any newly aborting units are added to the front of the queue. For example, if there are 2 units in the abort queue from the first combat when a second naval combat occurs that causes 5 more units to abort, the 5 new units in the abort queue are processed before the 2 from the earlier combat. The logic here is that the naval combat abort queue is a LIFO (last in first out) queue as far as a series of naval combats is concerned. However, within each combat it is a FIFO (first in first out) queue. I decided on LIFO for multiple naval combats since that is the way the Fighting Through stacks are processed. For example, suppose that the first naval combat was a naval interception combat with 6 units that aborted, followed by 4 of the aborting units moving as a stack, being intercepted, and provoking a second naval interception combat. From the second interception combat there are 5 units that are added to the 2 units still in the naval abort queue. The processing sequence is now: (1st) 5 newly aborted units, (2nd) naval moving stack of 4 units that provoked the second combat - assuming some have survived, (3rd) 2 remaining units in the naval abort queue from the first combat, and (4th & last) the naval moving stack that provoked the original interception combat - again assuming that some have survived. Clear as mud, eh what?

The queue numbers for units that abort from the first naval interception combat begin at 1001 and go up by 1 as each group of units aborts from the combat. For instance, there might be units from both sides that abort in the first round and they would be numbered 1001 and 1002 (different numbers for each side). In the second round there might only be units from one side that abort, which would be numbered 1003. And so on. If after the first combat reaches quiescence there is a second combat due to aborting units moving through another sea area and being intercepted, then units aborting from the second combat will have queue numbers starting at 2001. This numbering scheme enables the program to have all the units from the second combat abort/move before the units remaining to abort from the first combat. It also permits the program to detect when all the aborting units from the second combat having been returned to base so the moving stack that provoked the second combat can be returned to base before the remaining units in the abort queue. Note that if a naval combat is initiated during a naval combat phase, then the queue number for units that abort from that combat start at 1.

Saved Games
Nothing new.

Map and Units
Rob and Adam continue to send me new and/or updated naval and land unit writeups, respectively.

Scenarios and Optional Rules
Michael has prepared 5 Fast Start saved games. Here is an edited except on that from the Players Manual:

Many people like to jump into a new computer game as soon as it is installed, picking up the rules as they go. To facilitate this, MWIF comes with Fast Start saved games for 5 of the most commonly played scenarios: Barbarossa, Guadalcanal, Fascist Tide, Global War, and Missed the Bus. To access these games, click on the Restore a Saved Game button and select one of those 5 scenarios. Note that all of the Fast Start saved games use the solitaire mode of play and the Novice set of optional rules.

The Fast Start games begin at the first major decision of the scenario. For instance, Barbarossa starts with Germany deciding whether to align Hungary or Finland. Global War starts with the Commonwealth about to set up the Poles. These saved games are particularly useful for newcomers to the World in Flames game system, since they begin after the possibly intimidating Setup phase; Lend Lease, Scrap Units, and Unit Setup subphases have already been performed. Fast Start games also use very few optional rules, allowing new players to get a feel for the basic game without having to deal with the more complex optional rules.


I am making some hard decisions about which optional rules will be in the initial release. There are 56 optional rules already coded and debugged. I have 7 more that I would really like to include in the first release, some of which are already mostly coded. That leaves 17 that will definitely not be part of the initial release. See the last section of this report for the list of those 7 and 17.

MWIF Game Engine and CWIF Conversion
I finished converting the last 79 places in the sequence of play where CWIF used Windows messaging to communicate over the Internet. The new code uses Game Record Logs and Indy10 (a Delphi software library that employs TCP/IP for internet communications). The number of unique calls to SetGRL is just under 400. You can translate that as 400 unique record types, one for each decision/event that occurs in the sequence of play (for an example of what one of these record type looks like, see the end of this report). That number will probably go up once we get into testing NetPlay. I have embedded notes in the source code to check a half dozen places where I believe another GRL needs to be created. There are also a bunch of optional rules that will need their own personal GRLs (e.g., Guard Banner Armies, Kamikazes, and Naval Supply Units).

On average, each conversion required about 50 edits, spanning a dozen different modules. That comes out to around 4000 edits for GRLs last month, and having to jump around from module to module for each conversion increased the likelihood of me making errors. The beta testers found about ten, which from their point of view popped up in code that had previously been functioning without problems. But the conversions are essential for NetPlay and PBEM (that is: whenever more than 1 computer is being used). The hardest conversions to make were for moving units, especially naval moves, because of all the information required to keep track of exactly which units are moving through which hexes to reach their destination. Once the units arrive at their destination, what happens next depends on where they started and various other conditions. For instance, did the naval units start at sea? Were they out of supply? Were they intercepted in their arrival sea area? And so on.

Another group of GRL conversions had to do with bidding for major power groups at the start of the game. That code will not be tested until NetPlay is up and running. Which should happen this month (July).

Player Interface
Nothing major here. I modified the code so the UnitData panels and the Status Indicators show when a unit is flying a night mission and/or at extended range. This helps when returning air units to base after an air mission since now you know which ones flew at extended range. It also is of value when choosing targets in an air-to-air combat and for anti-aircraft fire.

Internet - NetPlay
I finished converting the CWIF code to MWIF Game Record Logs, as discussed above.

Mitchell started working with Aaron testing NetPlayComTest, version 2.0. A few problems with handling disconnects and the like had been discovered the last time Mitchell worked on debugging this with Paul earlier in the year. Mitchell’s goal for version 2 is to solve those problems.

For those of you who don’t know, NetPlayComTest is a stand alone program (written by me and improved by Mitchell) which uses Indy10 to send and receive messages over the internet. It deals with all the issues of establishing communications between two or more computers. Then it permits the users to send messages back and forth. Its original purpose is to test the software for use by MWIF proper. But it will also be included in the released product so players can test their communication links without having to run the game itself. If as a player you can get NetPlayComTest to work for communicating between all the players in your game, then MWIF should run NetPlay without problems. Some of the issues it needed to deal with are IP addresses, port numbers, and firewalls - all that good stuff.

Mitchell is also taking a serious look at the MWIF code’s side for handling Internet messages. Once a player has made a move and a GRL (Game Record Log) has been created, Message Control passes it to Mitchell’s NetPlay code for transmission. At the other end, NetPlay receives the message and hands it off to Message Control on the second computer for processing. The design for Message Control is as Spartan as I could make it. So far the feedback I have gotten from Mitchell is that Message Control does not need to be modified.

I am a firm believe in compartmentalization for software. The purpose behind those 400 GRLs is to isolate and completely remove the NetPlay and Message Control code from all the details as to how the game/simulation operates. NetPlay gets a simple string value with an identifier (ID number). It then sends it to its twin on another computer. That the game being played is World in Flames never enters into the NetPlay code. The data it sends and receives could just as easily be orders for tulip bulbs.

PBEM
Nothing new.

Artificial Intelligence (AI)
Peter finished the geographic breakdown for the AI Opponent. It looks great.

I have asked him to look into the Data Structures necessary for AIO strategic plans. I had already done some preliminary work on that. The goal is to design variables for holding all the information necessary to define a strategic plan for a major power. The 3 main elements are: (1) objectives to hold/take, (2) geographical areas to defend/attack, and (3) time lines for declarations of war/offensives, with accompanying production schedules. Some of the data will define conditions for when something should happen (e.g., when to start building garrison units). Defining data structures for conditionals is always difficult, but Peter and I already did some of that when we were working on setup scripts.

Player’s Manual
Aaron has been editing the largest section of the Players Manual: 8 Player Interface. As he makes changes he sends me replacement paragraphs. He has also taken on the major task of retaking all the screenshots needed for the Players Manual. He tells me the most recent count is 206, of which he has done ~150.

The biggest editing changes he has made have been for Production Planning. That form is very complex, since the tasks of fulfilling trade agreements, routing resources to factories, and saving oil/build points can potentially span the entire world map. Those are also critical tasks, since they directly affect production. Every player wants maximum control over these decisions, and a clear understanding of what is happening for his major powers as well as those commanded by other players.

What Aaron and I decided upon was to add a dozen or so small insert figures that are pieces of the overall Production Planning form. This means that when the text discusses, say, Filters for the resources and factories list, a little picture of the Filter radio buttons is shown. The overall effect is that it is much easier to understand the text by referring to the little figures instead of having to look back to a previous page and locate where the Filters are on the full-page form. I am now real happy with how this section reads, instead of being anxious about it being incoherent.

Tutorials, Training Videos, and Context Sensitive Help
I reviewed the training videos I made about 2 years ago. All 9 of the chapters I have recorded have small discrepancies when compared with the current version of the game. But to my eye those are mostly minor differences, and not worth re-recording an entire chapter (some of them are over 30 minutes long). I need to redo chapter 6, since it references the production planning form and uses a completely out-of-date screenshot of that form. But the other 8 chapters I think I’ll leave as is. I still have 3 more chapters to do: 10, 11, and 12, which cover naval movement & combat, production, and politics (i.e., declarations of war et al).

By the way, Erik Rutins of Matrix Games is reviewing my existing Training Video chapters and will either bless my decision to leave them as is, or tell me I need to redo them.

I updated the Status Indicators Help page to include Extended Range, Night Missions, and Flying at Sea when Not Engaged in Combat.

Historical Video, Music, and Sound Effects
Dave and Erik of Matrix Games are working on getting the sound effects and music to me so I can insert them in their proper places in the sequence of play.

Marketing
Nothing new.

Communications
Nothing new.

----------------------------------

Optional rules not yet coded, that hopefully will be included in the initial release:
5.1 Unlimited breakdown
5.2 Rough seas
5.3 Naval Supply Units
5.4 Convoys in Flames
5.5 Guards banner armies
5.6 Kamikazes
5.7 City based volunteers

Not included in the initial release:
5.8 Flying bombs
5.9 V-weapons
5.10 Atomic bombs
5.11 Partisan HQ
5.12 Frogmen
5.13 Japanese command conflict
5.14 Hitler’s war
5.15 Naval offensive chit
5.16 USSR-Japan compulsory peace
5.17 Recruitment limits
5.18 Oil tankers
5.19 No ZOC During Surprise Impulse
5.20 Bounce combat
5.21 En-route aircraft interception
5.22 Limited aircraft interception
5.23 The Ukraine
5.24 Intelligence


---------------------

TRL_TNM = record // Try making a naval move.
MsgID: Integer;
EntryNum: Integer; // Game record log entry number - increments each time an entry is written.
TransNum: Integer; // Game record log transaction number - increments each time a group of entries are sent.
By: Byte; // Who originated the GRL (e.g., major power ID).
PlayerID: Byte; // Which player originated the GRL.
UUnitPlace: Byte; // New Location for the naval unit stack. This may be to an off-map pool or On Map.
UColumn: Integer; // Only used when moving on the map.
URow: Integer; // Only used when moving on the map.
UProdTurn: Byte; // Only used when moving into the production pool; denotes arrival turn.
UOldUnitPlace: Byte; // Old Location for the naval moving stack.
UOldColumn: Integer;
UOldRow: Integer;
UOldProdTurn: Byte;
USentry: Byte; // Whether the stack goes into sentry mode when it stops in a sea area.
UHostile: Boolean; // Whether the stack makes Vichy Hostile when stopping in a port.
UStartedAtSea: Boolean; // Whether the stack originally started its move at sea.
UUndoSave: Boolean; // Whether the move can be undone by the player later.
UCheckInterception: Boolean; // Whether the moving stack might be intercepted in New Location (if a sea area).
ULoadedInPort: Boolean; // Whether the moving stack has loaded a unit in port before it started moving.
NavalMPUsed: Byte; // How many movement points are used to reach New Location.
NavalRangeUsed: Byte; // How much range is used to reach New Location.
NoNavalMoveCount: Boolean; // Whether the move counts against naval movement activity limits.
NavalUnitCount: Byte; // The number of naval units in the moving stack.
UnitCount: Byte; // The number of units in the moving stack.
Units: TMovingUnitArray; // The ID numbers of the units in the moving stack.
end;
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

August 1, 2011 Status Report for Matrix Games’ MWIF Forum


Accomplishments of July 2011


Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Rolf fixed a couple of bugs in the sequence of play. Mitchell finished the stand alone program NetPlayComTest which I incorporated into the main source code. He is also making progress on the sequence of events for one player starting a NetPlay game and other players joining the game in progress.

Hardware and Software
The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file). Neither of these is important.

Beta Testing
I released versions 8.04.04 (15 fixes), 8.04.05 (31 fixes), 8.04.06 (37 fixes), 8.04.07 (8 fixes), 9.00.00 (13 fixes), and 9.00.01 (5 fixes) to the beta testers last month. This totals 6 new versions and 109 fixes, which is slightly under my average number of fixes for a month.

There are ~90 bugs remaining in the sequence of play. My lack of progress on reducing this is because I have been finishing up the Players Manual and doing work on the optional rules and the Interactive Tutorials. During the past month I made the following changes:
• Eliminated a MadExcept error (i.e., fatal crash) that had been plaguing us for most of this year.
• Fixed a bug in how Flyouts were closed which had been causing MadExcept errors for several months.
• Fixed some bugs in Liberation caused by scenario initialization of when the countries were conquered.
• Revised the Main form drop down menus to include menu items for Supply Sources & Paths and NetPlay forms.
• Fixed a half dozen bugs caused by the Game Record Log changes in June.
• Fixed several bugs in how the Sequence of Play form appears. Numerous additions to the SOP had rendered it out-of-date.
• Made changes to the Status Indicators to show when units are using an Offensive Chit bonus and when the Naval Supply Unit is upgrading a minor port.
• Fixed a half dozen small problems with land combat resolution, only a couple of which had any serious effect on the outcome of the combats.
• Fixed several bugs related to US Entry Options that were found by Rob W.
• Enabled adding US naval units to a combat while the US is neutral - this involves several US Entry Options.

Rob W. went through all the US Entry Options and US Entry Actions to make sure the code functions correctly. As any experienced WIF player would expect, several questions about rule interpretations arose. After adjudication, Rob ended up identifying about a dozen bugs that needed to be fixed; only a couple of which concerned US Entry Actions. What was really impressive about Rob’s work here was getting the game to the point where each of these could be tested. He now has saved games for each of them so he can determine whether my corrections work or not.

Saved Games
Nothing new.

Map and Units
Rob and Adam continue to send in new and/or updated naval and land unit writeups. Happily, Jimm has returned to working on the land unit writeups (Italians). Aaron keeps all those master files and send me replacement files periodically.

Scenarios and Optional Rules
I worked on the 7 optional rules that I want to include in the first release. In particular I added 4 more subphases to naval combat: Voluntary Abort by Walther Submarines, Kamikazes, and 2 ASW Pre-fire Attack subphases. In preparation for finishing up these 7 optional rules I analyzed what changes would have to be made to data structures and forms. None of them required a new dedicated form, but several of them require using a tailored variation of the ubiquitous Unit Dialog form. For instance, when the Japanese player chooses whether his naval air bombers are flying as kamikazes, a Unit Dialog form will appear with all the possible bombers and the player will select which ones should wear head scarves.

The only optional rule of these 7 which is difficult to code is Convoys in Flames, and that’s because it has so many pieces. The other 6 are: Kamikazes, Naval Supply Unit, Unlimited Breakdown, City Based Volunteers, Rough Seas, and Guard Banner Armies. The last will also need a tailored Unit Dialog form.

MWIF Game Engine and CWIF Conversion
Added some missing code for the factory destruction phase. That is a little tricky because there are a couple of occasions when a player might want to destroy his own blue factories. The two that come up are: France destroying a factory in Vichy France before Vichy France is declared, and the USSR destroying a factory in the Ukraine before Germany declares the Ukraine as a separate country.

Player Interface
I created a new form for displaying the US Entry Actions. This is purely informational but I think it is a much cleaner presentation of the information and should make the concepts easier for new players to understand. I added a couple of shortcut keys for accessing the US Entry Pools and US Entry Action forms. The third in this group is the US Entry Options form. Together with the new section on US Entry that Aaron put together (see Players Manual below), this crucial concept of the game should be easier to learn and figure out while playing. I updated the Help page for the Keyboard and Mouse Commands to reflect these changes.

Internet - NetPlay
Mitchell sent me a final version of NetPlayComTest and I added it to the source code. I also converted it to use Theme Engine for the form’s components so it matches all the other forms in the game. Together Mitchell and I worked out the data structures and protocols for sending Game Record Log messages between players. These were the fine details of how it all works. Presently Mitchell is coding that up for testing.

I made a preliminary pass at revising the Chat form. CWIF had 3 forms for sending a single message: Chat, New Message, and Recipients. I have reduced that to a single form. The list of who receives a message isn’t very long, since is a maximum of 6 players in a game. The form now just has a checkbox for each player.

PBEM
Nothing new.

Artificial Intelligence (AI)
Peter continues to work on the data structures for AIO strategic plans. That is slow going because he keeps coming up with questions for me to answer and I haven’t had enough time to be as responsive as I would like. But some progress is being made. It isn’t easy to take all the amorphous advice provided by the forum members and render it into a rigidly structured outline for processing by a computer program.

Player’s Manual
Aaron finished editing the Players Manual gigantic Player Interface section. He also took new screenshots for the entire Players Manual. As of his latest count, 238 screenshots are final and 11 still remain to be done. The missing ones are for NetPlay (4), Screen Layouts (6), and Supply Sources & Paths (1).

After querying the forum members Aaron wrote up a new section on advice to players for section 3.4 of the Players Manual. Composer99 provided the heart of this material. I made some final edits and now new players will have a better chance of understanding the US Entry Options, Actions, and Pools.

The beta testers were provided with the latest and greatest version of the Players Manual and given the opportunity to make suggestions over a period of 2 weeks. Aaron collected their comments and added a bunch. I went through all 400 pages of the Players Manual and made over 500 edits of my own. After typing in all the changes I uploaded the Players Manual with all the new screenshots for the Matrix Games Editor to begin working on.

There is only 1 hole in the text for the Players Manual: NetPlay instructions for starting, joining, and resuming a NetPlay game. There are a couple other bits associated with that too: chatting with other players and monitoring internet communication links.

I also uploaded the final version (number 46!) of the Rules as Coded (RAC) document for the Editor’s to-do list.

Tutorials, Training Videos, and Context Sensitive Help
I wrote some sample pages for the Interactive Tutorials. Each tutorial will have a dozens or so pages with 6 lines of instructions on the ‘front’ of each page and 7 lines of commentary on its ‘back’. The player can toggle between the front and back of each page, seeing either very terse instructions or commentary. The latter is the equivalent of a “voice over”.

The design for the Interactive Tutorials and the code to implement them is done except for a slight glitch. What really remains to do now is generating the 100+ pages of instructions with commentary.

Historical Video, Music, and Sound Effects
David Heath expects to send me the complete set of music and sound effects files in a couple of days. Then I can place them into the sequence of play and hear how they work. My design calls for letting the player set how often the sound effects et al are played. That can range from never, to periodically, to always. Periodically would be like “every 10th time an armored vehicle moves play the sound effect.”

Marketing
Aaron is working with Sean Drummy of Matrix Games on updating the World in Flames screenshots displayed as part of the game’s description in Matrix Games’ list of products. I did the 34 that are presently there, but that was several years ago. So virtually all of them are out-of-date, and Aaron should be able to come up with another dozen new additions.

Communications
Nothing new.
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

September 1, 2011 Status Report for Matrix Games’ MWIF Forum


Accomplishments of August 2011

Project Management
I monitored all the threads in the MWIF World in Flames forum daily - well, almost every day.

On August 1st I was diagnosed with a detached retina in my left eye due to an ocular melanoma. Only 6 lucky people in a million get this cancer (roll a 10 die sided die 6 times; the first 5 times it has to come up 0 and the last time it has to come up less than 6). Technically it is a skin cancer since it occurs in the choroid tissue of the eye. In brief, the retina is the back lining of the eye which receives light that has passed through (in series) the corona, pupil, lens, and transparent vitreous tissue. The retina is attached to the choroid which is the inner layer of the eye’s skin tissue. The outer layer is the ‘white’ of the eye that you see when you look in a mirror.

The cancerous growth on my choroid eventually separated the retina from the choroid and let some quasi- liquid intrude between the two. From my point of view, things were normal on Friday, on Saturday my left eye added a yellow tint to everything it saw, on Sunday I lost the upper half of my field of vision in my left eye, and on Monday (August 1st) I was diagnosed with an ocular melanoma by a retinal specialist.

I flew to Philadelphia on August 13th and underwent surgery at Wills Eye Hospital on August 18th. The treatment for this melanoma is to insert a ‘plaque’ into the eye, next to the melanoma. The plaque is made out of gold and contains micro-radioactive nodules on one side. It is left in the eye for 4 days after which the radiation has killed all the cancer cells and the plaque is removed (i.e., on August 22nd). No, I didn’t get to keep the gold.

The melanoma was 10.5 mm by 11 mm by 5.1 mm thick (at its thickest point). This is considered to be on the low side of medium, based on the thickness. They do not treat melanomas smaller than 2 mm. Medium ranges from 4 mm to 8 mm. The plaque was 14 mm by 14 mm, roughly square. To insert it, they cut into the white of the eye and shove it in, perhaps using a rubber mallet - I don’t know for sure since I wasn’t paying attention at the time. I now have 2 really nifty scars (one vertical and one horizontal) on the left side of my left eyeball.

This is considered an out-patient treatment and I was required to stay at the Watermark hospice in Philly, confined to my room, while the plaque was in place. I also had the delight of having my eyelid sewn shut and wearing a lead eyepatch to prevent radiation ‘leakage’. At the time I felt like a Marvel Comics villain that emits deadly rays from his eye. The weirdest part of this story is that my brother was also at the Watermark for a 3 week stay while I was there (he had cellulitis). His suggestion was that I get a hook for a hand, a pegleg, and a parrot to complete my ensemble.

There were no complications and I returned to Honolulu on August 23rd. I am taking eye medication 4 times a day (mostly to prevent infection) and will continue to do so for the next 3 weeks. After 6 months my body is expected to have cleared out all the dead cancer cells and my local retinal surgeon can consider the possibility of reattaching my retina. But there isn’t a lot of hope for the vision in that eye improving substantially. Right now its visual field ranges from 40% to 50%, with the upper half of its world mostly black. While detached, the retina doesn’t get the blood that it needs and it kind of crumples up. The main gain in the future will be the removal of the liquid between the retina and the choroid. Counterbalancing that is the fact that radiation doesn’t kill off only the cancer cells, it does damage to the other parts of the eye in the immediate vicinity too. Exactly what good stuff gets radiated and how badly is more or less random.

I need to have cancer screenings every 6 months for the rest of my life. For now, all the tests have come back negative. The vision in my right eye is good but the left eye is sending ‘static’ to my brain; so even when my left eye is closed, I get a flickering image superimposed on my right eye. Reading text on a computer screen is problematic at best and I am forced to take a break after an hour or so: an hour on, an hour off.

All in all I lost about half the month of August due to vision problems as far as working on MWIF was concerned. For instance, while in Philly I only had my portable computer with me, so I was unable to work on the source code: no debugging and no code changes.

On the plus side, last month Aaron took over responsibility for maintaining my task list. He’s transferred it to a spreadsheet and does daily updates to it, reflecting my changes from the previous day and new bug reports from the beta testers. This has saved me tons of time and I find working with the spreadsheet much easier than the bland text file I had been using. All-in-all, this change has offset my decrease in working hours so I am actually getting more done each day than I had been previously.

Hardware and Software
The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file). Neither of these is important.

Beta Testing
I released versions 9.00.02 (24 fixes), 9.00.03 (2 fixes), 9.00.04 (13 fixes), 9.00.05 (15 fixes), and 9.00.06 (15 fixes) to the beta testers last month. This totals 5 new versions and 69 fixes, which is way under my average number of fixes for a month, but actually a higher daily average if you allow for me being out of action for half the month.

During the past month I made the following changes:
• Fixed a group of bugs related to using the optional rule Fractional Odds with the 1D10 land combat CRT. That combination of rules hadn’t been tested very much - if at all.
• I fixed two obscure bugs related to the Axis aligning Yugoslavia, and Germany setting up Rumanian units when that country is aligned because the Hungarian and Bulgarian claims are denied.
• I fixed several minor bugs with the Scrap Units form concerning City Based Volunteers and how many engineer units are needed for set up.
• I added some code so partisan units that are placed at the end of setup can never overrun enemy units. My solution here was to forbid major powers from setting up units such that they might be overrun. The effort required to write code to handle overruns during setup seemed far in excess of any potential gain to ‘game play’. The program now tells a player about any potential overruns and forces him to fix the problem so his units will not be overrun by partisans.
• I eliminated the possibility of France creating and using default scrap lists after France has been Vichied. That was because the list of units in the French force pool gets drastically reduced using random selection.
• I fixed several bugs in head-to-head play having to do with restoring saved games.
• I added code so players are informed during the reinforcement phase when units arrive and are move into the Construction Pool.
• I added code to handle obscure cases when Germany has been incompletely conquered: when no hexes are available to save build points and when replacement naval units are available but the naval unit to be replaced is in the Conquered Pool.
• I fixed some minor bugs in the setup tray related to theme colors and the use of the check box for centering the detailed map on a setup location.
• I fixed several bugs related to naval air combat; some to due with AA fire, and others to do with aborted air units.

I think the above list gives the flavor of the bugs I have been fixing. Some of them are minor, but annoying, others are major, but obscure. The primary areas where I still need to work on fixing bugs are: naval combat, land movement (mostly to do with undoing moves), US Entry (recently exhaustively tested by Rob W.), and Production Planning.

Saved Games
The new item here is that Aaron is making a concerted attempt to build a large library of saved games for testing the numerous phases in the sequence of play. Of course this is complicated by the number of different scenarios and optional rules, as well as the modes of play (e.g., solitaire, head-to-head, NetPlay). But he has made a good start on this and is cajoling other beta testers into sending him the saved games they use for testing. From my perspective, the best part of this are the saved games related to specific bugs. Those let me immediately reproduce bugs so I can both fix them and prove to myself that my changes work.

Map and Units
Rob and Jimm continue to send in new and/or updated naval and land unit writeups. Aaron keeps the master files and sends me replacement files periodically.

Scenarios and Optional Rules
I added code so the only legal sea areas in the Barbarossa scenario are the Black, Baltic, and Arctic Seas. I also made some preliminary changes to support the Unlimited Breakdown optional rule.

MWIF Game Engine and CWIF Conversion
While in Philly, I wrote out pseudocode to complete my revision of the Supply Determination routine. I need to type that in and start testing my full implementation of calculating which units are in supply using the various optional rules. The code already works for calculating which secondary supply sources are in supply so all that remains is to trace a path from each unit to a valid supply source - or determine that none exists.

I fixed a couple of bugs that had to do with nested digressions. A problem arose when a naval combat caused units to abort and on their way to a port, they were intercepted, resulting in a Naval Abort digression branching to a Naval Interception digression. The trick is to resolve all the digressions and get back to the next naval combat. Similar to that was when a Naval Interception digression resulted in a naval combat and as part of a naval air combat round, AA fire caused one of the naval air units to abort. In this case and Naval Interception digression branches to a Return to Base Digression (by the air unit). I think I have these nested digressions fixed now - but I have thought that on previous occasions too.

Player Interface
Nothing new.

Internet - NetPlay
Nothing new. I will begin working on NetPlay daily starting this weekend.

PBEM
Nothing new.

Artificial Intelligence (AI)
Peter continues to work on the data structures for AIO strategic plans. Much of this is coming together. For instance, last week he was grinding out the conditions under which France should surrender. I answer his questions from time to time but the bulk of this work is being done by Peter.

Player’s Manual
This is in the hands of the Matrix Games editor. I made a bunch of edits in the last week of July and messed up a lot of the small details. So in early August I made ~40 corrections to my corrections. But since then I have done nothing on the Players Manual, other than tweaking Rob’s bibliography for the naval unit writeups. The only missing section in the Players Manual is for setting up a NetPlay game.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
David Heath has uploaded the music and sound effects files to the Matrix Games FTP site, but apparently he placed them in a location which, due to security, I can not access. Hopefully this will get straightened out soon.

Marketing
Aaron continues to work with Sean Drummy of Matrix Games on updating the World in Flames screenshots displayed as part of the game’s description in Matrix Games’ list of products.

Communications
Nothing new.
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

October 1, 2011 Status Report for Matrix Games’ MWIF Forum


Accomplishments of September 2011

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

My eye is gradually getting better from its surgery for a melanoma, but I had a kidney stone (6.7 mm) removed last month. That was a somewhat drawn out process with a week of confusion where I thought I had indigestion from having eaten bad food, to a trip to the ER where a picture of the stone was taken. Then there was a 10 day hiatus before the lithotripsy surgery. The surgery itself didn’t go as planned because the stone had moved during the intervening 10 days so instead of use an external parabolic sound blaster to break the stone apart, a laser was used (going in through the urethra). The week post surgery was the most painful period, partially because of the stent that had been inserted in my left ureter. Urine is generated in the kidney, passes through the ureter (~8-10 inches) to the bladder and exits through the urethra). Removal of the stent occurred two days ago and I’m gradually coming out of the drug haze I have been in for the last week or so.

All-in-all my kidney stone experience can be summed up as piss, pain, pills, and blood for color. I lost half of September mucking around with that health issue. This pattern of a surgical operation each month is something I hope to put an end to immediately.

Hardware and Software
Delphi died on me about a week ago, which halted all work on debugging until I could reload it from scratch. In the process of getting that done, I established a contact at Embarcadero (which currently owns Delphi) and he gave me some advice on how I could perhaps fix the problems I have had with Delphi over the past 20 months. I’ll test out his ideas next week.
The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file). Neither of these is important. Fixing Delphi might fix the problems with Theme Engine. Or, the problems with Theme Engine might be what is wrong with Delphi.

Beta Testing
I released versions 9.00.07 (13 fixes), 9.00.08 (19 fixes), 9.00.09 (6 fixes), 9.01.00 (18 fixes), 9.01.01 (3 fixes), 9.01.02 (10 fixes), 9.01.03 (10 fixes), 9.01.04 (24 fixes), and 9.01.05 (14 fixes) to the beta testers last month. This totals 9 new versions and 117 fixes, which is back up to my average number of fixes for a month, but a quite higher daily average after allowing for my health problems. That is almost entirely due to the help I am getting from Aaron and the beta testers in fault isolating bugs, reporting them in detail, and providing saved games so I can recreate them immediately.

I enabled the beta testers to change many of the optional rule settings on-the-fly. This will not be part of the released product but it gives the beta testers help in setting up saved games for testing how the game performs with various optional rules On/Off.

See the section Rule Precision below for some insight on what bugs I have been fixing recently.

Saved Games
Aaron continues to be aggressive in building a library of saved games for testing purposes. I have found them to be of tremendous benefit in recreating and debugging problems reported by the beta testers.

Map and Units
Rob and Jimm continue to send in new and/or updated naval and land unit writeups. Aaron keeps the master files and sends me replacement files periodically. I corrected the last known bug in calculating land movement costs: moving from a desert hex to an all lake hexside during snow.

Scenarios and Optional Rules
I made an adjustment to the Production form for Barbarossa - there is no lend lease for that scenario. I have also started making corrections to the code for the odd rules associated with the half map scenarios: Fascist Tide and Day of Infamy. In particular, I intend to use the Azanian Sea (for Fascist Tide) and the Eastern Med (for Day of Infamy) as holding areas for the “Transfer Pool”. This way when a naval combat has to occur in the Transfer Pool, the players will be able to see the units therein just as for any other naval combat. After making changes this month, the victory cities for those two scenarios are now correct and so are the lists of which countries are ‘legal’ when playing those scenarios.

Rule Precision
This is a new section (replacing CWIF and MWIF Game Engine). What the beta testers and myself are spending quite a lot of time on recently is making sure the rules are being implemented correctly. That often resulted in a need for a more precise definition of WIF FE rules. Here is a sampling of the items we worked on this month:
• Imposed a setup restriction on the Communist Chinese units so they have to be within 9 hexes of a Communist controlled city. The number of hexes is greater than what is stated in WIF FE because of the change in scale for China.
• Vichy France can be hostile to and/or at war with Allied major powers. I revised the Relations form so those conditions are shown accurately.
• Fixed a bug in declaring Vichy France when non-French naval units are forced to rebase. This is the one place in the rules where ‘overrun’ naval units have to rebase to the nearest port, but can be intercepted when doing so. In all other cases the units either can not be intercepted or else they have the freedom to choose any port within twice their range.
• Fixed a bug where liberating France while Vichy France still exists wasn’t converting all Metropolitan Vichy France hexes to French control.
• Fixed a bug so Vichy units can only move into hexes controlled by Vichy or by a country with which Vichy is at war.
• Changed the production form selection of repaired Auxiliary Cruisers so which one is repaired is randomly selected. In all other cases, the player can choose which naval unit to repair.
• Land units can only be loaded on air transports if they are organized (Harry Rowland clarified this rule).
• Changed the code so when the US claims Greenland/Iceland/Northern Ireland, units belonging to other Allied countries therein are relocated to the nearest hex, rather than rebased. As part of claiming Northern Ireland, the US is permitted to place convoy reinforcements in Ireland - but not any other type of unit.
• Fixed a bug where the US was being permitted to DOW another major power after failing in an attempt to DOW a major power during the same impulse.
• When the US DOWs both Germany and Italy in the same impulse, two separate die rolls for US Entry are made. Furthermore, those die rolls and the mandatory movement of US Entry markers from the Entry Pool to the Tension Pool are made prior to the implementation of the optional movement of markers due to the automatic execution of US Entry Options. The automatic execution of US Entry Options only occurs if the US is at war with both Germany and Italy (or those countries have been completely conquered). This is another instance where Harry Rowland clarified the rule. There are a couple of more subtleties to this rule which are now coded correctly in MWIF.
• Implemented the following rule interpretation: Unit U is not permitted to fly to a naval combat sea area if:
(1) U's controlling major power is surprised by all the enemy units in the sea area, or
(2) all units friendly to U in the sea area are neutral or surprised [by all enemy units in the sea area].
• Fine tuned the code so land based air units that voluntarily abort from a naval air combat are handled differently from those that abort under any other circumstance. If they voluntarily abort from an air-to-air combat, then they return to the sea box section from which they entered the naval combat. If they otherwise abort, they must return to base (i.e., to a land hex) where they are disorganized.
• Removed the ability of land attacks being declared against a hex containing only enemy supply units.
• Enabled conducting ground strike and carpet bombing missions against a hex containing units with which you are not at war, if the hex is controlled by a country with which you are at war.
• AA units that fire during the ground support phase are not disorganized until after the Advance After Combat subphase.
• Fixed a bug where attacked partisan units were able to receive ground support from countries other than their controlling major power.

As you can tell from the above list, many of the ‘bugs’ now being reported by the beta testers are due to 2 things: (1) they are rigorously testing how the program performs under a variety of obscure circumstances, and (2) they are going through the rules with a fine tooth comb.

Player Interface
Added some graphics to visually indicate that captured red factories are not producing. I still need to figure out how to visually indicate when a factory has lost a production point.

Internet - NetPlay
Nothing new. My health keeps interfering with me starting work on this.

PBEM
Nothing new.

Artificial Intelligence (AI)
Peter sent me his final list of Areas of Operation and Land Regions. I was able to partially review and modify those. Currently there are 126 AOs and 320 LRs. The Sea Area Groups are now complete and Peter is turning his attention back to Strategic Plans for France.

Player’s Manual
I have a couple small edits for this which I need to forward to the Matrix Games editor.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
David Heath has uploaded the music and sound effects files to the Matrix Games FTP site, but I still haven’t been able to locate them.

Marketing
Aaron continues to work with Sean Drummy of Matrix Games on updating the World in Flames screenshots displayed as part of the game’s description in Matrix Games’ list of products.

Communications
Nothing new.
Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: MWIF Monthly Reports

Post by Shannon V. OKeets »

November 1, 2011 Status Report for Matrix Games’ MWIF Forum
Accomplishments of October 2011

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Aaron has been set up as a second moderator for the World in Flames forums (both open and development). Way back in the beginning of this project, Graham was serving in that role but his real world issues have severely limited his availability.

No new surgery for me in October - a good month. My kidney stone is passed and past. I have an office visit with that doc scheduled to determine how to change my diet based on the lab’s urine analysis. The probability of a second kidney stone jumps to 20% (from 10%) after you have the first one. I really want to avoid that, even if it means not eating chocolate ever again. My left eye continues to improve after its surgery, although that doc says it will take another 4 months (at least) until it reaches its new normal. The new normal is likely to be 40% good vision and 60% partially occluded. The occluded vision includes the focal point, which is bad. Right now I have retinal fluid between the retina and the choroid, which causes a flickering image of constantly moving gray amoebas outlined in yellow light to appear in the occluded portion of my left eye. The flickering is also ‘seen’ by my right eye, so reading text is difficult. Once the natural, small ‘pumps’ within the eye remove the fluid, the flickering should go away - that is where the 4 months comes in.

Hardware and Software
Delphi 2010 is still misbehaving. When I get a chance, I’ll submit a full report on what is wrong to Embarcadero (which currently owns Delphi). I have the choice of paying them to fix their product, or merely asking them to do so. The latter choice comes with no guarantees that they will. But then neither does the former really.
The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file). Neither of these is important. Fixing Delphi has a low probability of fixing the problems with Theme Engine.

Beta Testing
I released versions 9.01.06 (27 fixes), 9.01.07 (12 fixes), 9.01.08 (8 fixes), 9.01.09 (11 fixes), 9.02.00 (24 fixes), 9.02.01 (5 fixes), 9.02.02 (10 fixes), 9.02.03 (16 fixes), 9.02.04 (3 fixes), and 9.02.05 (12 fixes) to the beta testers last month. This totals 10 new versions and 128 fixes, which is above my average numbers for a month. My improved effectiveness is due to good health and the help I get from Aaron and the beta testers (a new a capella group?) in fault isolating bugs, reporting them in detail, and providing saved games so I can recreate them.

About half the new bugs are due to recent changes I make. As always I have to decide when to stop reading over the code and quit running tests. I can’t afford to spend excessive time checking my changes or else I would get very little accomplished. On the other hand introducing new bugs is a pain for everyone; “com ci, com ca”.

Most of the remaining bug reports are due to: (1) rigorous testing how the program performs under a variety of obscure circumstances, and (2) going over the rules with a fine tooth comb. See the Rule Precision section below for specific details.

Saved Games
Aaron and the beta testers are building up a large library of saved games for testing purposes - that’s a big help to me.

Map and Units
Rob and Jimm continue to send in new and/or updated naval and land unit writeups. Aaron keeps the master files and sends me replacement files periodically.

Scenarios and Optional Rules
I fixed ancient bugs in setting up game data for Day of Infamy, so New Caledonia now goes to Free France and Vichy France gets French Polynesia and aligns Madagascar. Japan is able to align Madagascar as long as Madagascar is controlled by Vichy France. What was so difficult about getting this code correct (almost a full day) was that Vichy France doesn't officially exist in the scenario. I need to add code for the external/European event of Germany collapsing Vichy France occurring at a fixed point in the game.

I still need to make modifications to the code for the Transfer Pool in the half map scenarios Fascist Tide and Day of Infamy.

I added the +2 penalty when trying to intercept auxiliary cruisers (Convoys in Flames). This was a bear to get correct because of the complexity of the rules concerning search roll modifiers and search numbers.

Rule Precision
What the beta testers and myself are spending a lot of time on is ascertaining precise definitions of some WIF FE rules. Here is what we worked on this past month:

• If France is liberated while Vichy France still exists, the major ports previously held by Vichy are undamaged when converted to French control. Usually when a major port changes control from one side to another, it becomes damaged. The problem our rule interpretation avoids is having newly acquired French naval units overstacked in, say, Toulon.
• When the US player has the option to move, or not to move, markers from the Entry Pools to the Tension Pools and there is more than one marker to be moved for an entry option, he has to either move all the markers for the entry option or none. The US player gets this choice when US Entry Options are made automatically after the US goes to war with Axis major powers.
• The movement of Commonwealth naval units out of Northern Ireland, when the US occupies Northern Ireland is a ‘relocation’ to the nearest port, rather than a rebase.
• I changed the test for conditions under which the Nazi-Soviet pact can be broken. Specifically, setting up or moving units within one of the countries listed for breaking the pact (e.g., Turkey, Sweden), no longer qualifies for breaking the pact, regardless of to whom the minor country units are aligned. Basically, as long as the only units you move in the specified minor countries belong to the minor country itself, then the conditions for breaking the pact are not met. But if you move a unit from a different country into one of the listed minor countries, then the other side can break the pact. For example, if the USSR DOWs Turkey, which is then aligned to Germany, and Germany moves the Rumanian HQ into Turkey, then the USSR can break the pact. However, moving an Italian unit into Turkey would not affect the status of the pact, since Italian units are not controlled by Germany. This applies not only while setting up units, but throughout all phases of the game (e.g., including air units returning to base).
• Any carrier air units aboard a captured carrier are destroyed, along with their pilots.
• Allied units in Italy that count towards the conquest of Italy garrison value must be controlled by a country at war with Italy.
• Vichy France can not build pilots or offensive chits.
• Overrun naval units in iced-in ports, although having rolled well and being permitted to escape, are instead destroyed.
• Which major power decides about continuing to fight or abort from a naval combat is redetermined at the end of each round and is awarded to the major power on each side that has the most units still capable of fighting in the sea area.
• The requisite conditions have to be met before the US can occupy Greenland and Iceland even when that US Entry Option is ‘automatically’ selected due to the US going to war with both EuroAxis major powers.

I am still mulling over what to do with Belgian convoys in Brest (Belgium aligned with France) when Vichy is declared. As French controlled units they should rebase to the nearest Free French or Vichy French port - which one is the choice of the major power controlling Vichy France. But if they go to a Free French port they are likely to violate the Foreign Troop Commitment restrictions since they would belong to one minor country aligned to France and be moving into a port owned by a another minor country aligned to France. That almost forces them to move to a Vichy French port, where (I guess) they would become owned by Vichy France. Murky waters.

Player Interface
I created a small new form for the Liberation phase. All it does is ask a player if he wants to liberate, revert, or ‘neither’ when he controls the capital of a country that was on his side originally. The change here is to include the option to revert. Liberation of a minor country means it is aligned to its liberating major power. Reversion means it is aligned to the major power to which it was originally aligned. If you do neither, then it is conquered by the major power controlling the capital. This is a ‘nag’ form, since if you choose neither, then you will be asked the same question again at the end of the next turn. I really dislike having ‘nag’ forms in the sequence of play but I couldn’t come up with another solution and still remain true to WIF FE, where you can liberate/revert a minor country during a later turn if you so desire.

Remaining on my to-do list is figuring out how to visually indicate when a factory has lost a production point.

Internet - NetPlay
Nothing new last month but I will start work on NetPlay this coming week.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new. I need to finish checking the names for the Areas of Operation and Land Regions so they conform to the ‘standard’ I am trying to establish.

Player’s Manual
I have a handful of small edits waiting the Matrix Games editor. He should begin working on the Players Manual and the Rules as Coded documents at the end of November. Currently he is busy finishing up editing material for the new games Matrix Games is releasing this Christmas season.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
I have gotten the music and sound effect files from Dave and they look/sound good. I am missing one sound effect (truck engines) and a couple of the music pieces (for China and Italy), but Dave is working on filling in those holes. I should be able to get the sound effects implemented this month. For more details on sound effects, see the attachment below.

Marketing
Nothing new.

Communications
Nothing new.



Sound Effects for MWIF

The list below are actual files (WAV). In practice they will sometimes be combined and oftentimes run in a loop. The simplest use is a single Click when a player selects/picks up a unit. If he is picking up a group of units, then a single Stack Click is heard.

Looped sounds (i.e., continuous play) occur most often when moving the cursor over the map. Depending on the terrain type and the weather, different sounds are played if there are no units “in hand”. When the player has a unit or units “in hand” and is repositioning them on the map, the sounds depend on the type of unit and phase of the game. Note that no sound is played if there are no units in hand and the cursor is over water. The same is true most of the time a form is open for review or decision making.

When the combat resolution forms are open, the sounds depend on the type of combat and may be combinations of individual sound effect files. For instance, ground strikes combine the dive bombing sound of a Stuka with explosions. I want to spend some time playing around with this to decide on combinations and the duration of each sound segment.

Of course all sound effects can be turned off. Historical videos are used for invasions and paradrops (rare occurrences) and major events (e.g., conquering a country). Once I get the sound working the way I want, I’ll add in the videos and the music.

1. Click Selecting a unit
2. Stack Click Selecting a stack of units
3. Fine Examining non-jungle land hex during fine weather
4. Jungle Examining jungle hex during fine weather
5. Snow Examining land hex during snow
6. Blizzard Examining land hex during blizzard
7. Rain Examining land hex during rain, or sea hex during rain/snow
8. Storm Examining land hex during storm, or sea hex during strom/blizzard
9. Morse Code Sending messages to other players
10. Tanks Moving Armor/mechanized units in hand
11. Trucks Moving Motorized units in hand
12. Boots marching Foot infantry in hand
13. Hoofbeats Cavalry in hand
14. Partisan Attack Partisan in hand.
15. Aircraft Engine Light Aircraft (other than strategic bomber) in hand
16. Aircraft Engine Heavy Strategic bomber in hand
17. Ships Moving Through Water Naval unit in hand
18. Trains Moving Units in hand during rail movement phase
19. Artillery Fire Land combat, ground strike, and ground support resolution if artillery participates
20. Tank Main Gun Firing Land combat resolution if armor participates
21. Machine Guns Land combat resolution with 2 or more units on both sides
22. Rifle Fire Land combat resolution with only one unit on at least 1 side
23. Aircraft Diving Ground strike resolution if no artillery participates
24. Air Raid Sirens Strategic bombardment resolution
25. Bombs Falling Ground support resolution if no artillery participates, port attack, naval air, and naval surface combat resolution
26. Bombs Landing Port attack, strategic bombing, carpet bombing, ground strike, ground support, naval air, and naval surface combat resolution
27. AA Fire Land Anti-aircraft fire resolution over a land hex (not a port attack)
28. AA Fire Sea Anti-aircraft fire resolution at sea and during a port attack
29. Naval Hunting Sub ASW combat resolution
30. Splashes Port attack, naval air, and naval surface combat resolution
31. Dive Dive Dive ASW combat resolution
32. Clanging During production
33. Fanfare Declaration of war and aligning another country
34. Production Orders During production planning
35. Trade Agreements During lending
Steve

Perfection is an elusive goal.
Post Reply

Return to “World in Flames”