MWIF Monthly Reports

[Shannon V. OKeets]

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

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

Aaron’s bout with pneumonia has sidelined him from maintaining my task list, and from performing numerous other tasks he’s been doing to support MWIF development. Until his health improves, I am back to keeping track of my task list on my own.

But on the positive side, Rolf now has some time to help out with the programming. I just uploaded the current version of the source code for him to work with. Later today I’ll select some of the new bug reports from version 9.02.05 for him to fix.

My health is so-so, which is relatively good news. To prevent a reoccurrence of a kidney stone, I have rather dramatically changed my diet. One element of that is simply drinking 80 ounces of liquids every day, mostly water. But my food intake has also been overhauled. In general, I am unhappy with the dietary changes, but maybe after tweaking it for another month or so, I’ll be able to make it less drab. My eye still interferes with my ability to work long hours; I’m down from 8-10 per day to 6-8 per day (although still 7 days a week).

My long struggle with rewriting the Supply routines this month (detailed below), made me question whether my memory was fading. To check on that I decided to memorize the periodic table of elements. That went pretty fast. After 1 week I had learned the first 5 rows (72 elements). That was all I wanted to learn. Next year I might go back and reread the college chemistry book I bought ten years ago. Understanding the references to individual chemical elements better should make comprehending the text easier.

Hardware and Software
Delphi 2010 is still misbehaving. When time permits, I’ll submit a full report on what is wrong to Embarcadero (which currently owns Delphi).

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.

At the end of the month I purchased an upgrade to the latest version of WordPerfect Office (it was on sale), which I use for all my writing, spreadsheet, and database work. I’ll try to find the time the install it once I finally beat the Supply routines into submission.

Beta Testing
I only released 1 new version to the beta testers this month: 9.03.00 and that only had 9 fixes. I spent the entire month working virtually exclusively on a rewrite of the Supply routines. On the plus side, the beta testers did not find a lot of new bugs. I need to sort through the bug report thread on version 9.02.05 to identify which ones are reports on new bugs and which are new reports on previously reported bugs.

Saved Games
The beta testers are CC’ing me on saved games they send to Aaron for testing and archival purposes. The save and restore code continues to work flawlessly, as it has for months now.

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

Scenarios and Optional Rules
Nothing new.

Rule Precision
At the beginning of the month I had my rewrite of supply working correctly to:
• calculate primary supply sources for major powers (including cooperative major powers)
• calculate primary supply sources for minor countries (including their parent major powers)
• the above includes HQ supply for the turn and the impulse
• calculate secondary supply sources for major powers: HQs and aligned/conquered minor country capitals
• the above includes HQs belonging to cooperative major powers
• calculate HQ secondary supply sources for minor countries (including their parent major powers)
• all of the above could include overseas links using any of the related optional rules.

The problem was that it was taking too long. After a couple of days I was able to reduce the time from 9 minutes to 9 seconds. Presently it takes 5 seconds to execute the above list, regardless of which optional rules are being used. That is when starting from scratch. It should run effectively instantaneously when simply checking whether previous sources and paths are still valid.

I’ve since added the ability to have units trace to supply sources. That took me a couple of weeks to accomplish. The difficulty was that my design for data storage was flawed and I needed to go back and make substantial revisions. Ripping apart code when modifying data structures is particularly difficult. There was one typo I made where a TObject was defined as a TObjectTable. That caused the program to overwrite the executable code, resulting in bizarre fatal errors that occurred in different places at different times. A real nightmare to figure out. Every day I would get up and try to figure out what was going wrong. I did that for over a week before I finally ‘saw’ the error.

Currently I am whiling away the hours delving into why the overseas paths, which are correctly identified, are being stored as several long lists instead of one path per secondary supply source/unit. I found an index that was wrong late last night but making that change this morning only partially alleviated the program’s propensity to route Oslo supply for the Germans through the Med and South China Seas. At least the Allied supply paths are no longer being appended to the path. To repeat, the program finds the path from Oslo to the Baltic to Konigsberg, but then the process of storing that information in the data lists is messed up. It seems to be overwritten by Rommel’s supply route from North Africa and the Japanese HQ’s in China.

If no overseas paths are needed, all the code works - to the best of my knowledge. For instance, the Barbarossa scenario computes supply perfectly using the new routines. It executes the supply determination from scratch in a fraction of a second. But when I apply the heavy duty test using the Brute Force scenario, with the US fully in the war and units scattered all over the map, the overseas routines break down.

The supply code is separated into 4 modules:
• Supply Links, which defines most of the data structures and the routines for identifying supply sources.
• Supply Searches, which has the more complex algorithms for tracing supply from point A to point B.
• Sea Area Supply, which traces supply overseas and pieces together the supply connections from secondary supply source to departure port, first to the overseas path, and finally with the arrival port to primary supply source.
• Supply Sources and Paths, which is the form that displays the sources and paths for review.

The file sizes for those modules are 2050, 2560, 2250, and 1210 respectively. At different times during the month those file sizes expanded and contracted as I made significant mods to the code. All-in-all it is 8,000 lines of code that includes a lot of tables, arrays, indices, pointers, and search algorithms.

You might think that the optional rules are what is causing problems, but they aren’t. At some point I will have to code the search for isolated units (infinite supply paths) which makes me worry about the time it might take to ‘prove’ that a unit is isolated. But since isolation comes up rarely and is usually caused by a unit being surrounded by enemy ZOCs, it shouldn’t be too difficult to get to it execute quickly.

The way the supply searches work is to view each hexagon as the central focal point of 7 hexagons. By computing and recording information on each of the 6 adjacent hexes and hexsides, these TSearchHexes enable the program to compute which of several possible destination hexes is closest and to ‘head’ in that direction. For instance, in the attached screenshot, the potential secondary supply source Tallinn needs to trace a rail path to a primary supply source before it can function as a secondary supply source. The program checks each adjacent hex and marks hexsides 0, 1, and 3 as impassable.

[See the all sea hex in the attached figure for hexside numbers. Hexside 0 is to the west and the other 5 hexsides are numbered clockwise from there. The easy way to remember this is that hexside 2 is at 2 o’clock, 3 at 3 o’clock, and 4 at 4 o’clock. With those in place, figuring out which hexsides are 0, 1, and 5 is easy.]

Of the other 3 hexsides, the program prefers hexside 3, since it uses a rail connection which does not expend one of the limited number of Basic Path Hexes available for a rail path. Then the program evaluates the six hexes adjacent to the new TSearchHex, (38, 49). Hexside 0 leads back to a hex already examined, so that hexside is non-viable. Hexside 1 is impassable. Through hexside 2 is an all-sea hex which is recorded in the TSearchHexes list as non-viable. Of the 3 remaining hexsides both 3 and 4 have rail connections. They are also both 3 hexes away from the nearest primary supply source. But hex (38, 50) is preferred because it is 3 hexes away from 2 primary supply sources (Leningrad and Pskov), while (39, 49) has only 1 primary supply source within 3 hexes (Pskov). The logic continues processing and the rail path reaches Leningrad without expending any Basic Path Hexes. That means it will be viable regardless of the weather conditions.

Here are some of my notes on finding rail paths (secondary to primary). To understand these notes you need to know that a secondary to primary overseas path is composed of 3 pieces: 2ndary to departure port, overseas path, and arrival port to primary. The two land pieces can use up to 3 Basic Path Hexes maximum, since the overseas piece always uses 1 BPH.

1. When failing in a search for an overland rail path from a secondary supply source to a primary, the algorithm identifies all the ports it can reach. So when the search fails, the program stores all the ports the supply source could reach using 3 or less Basic Path Hexes (BPH). Those have the potential for being Departure Ports and are labeled ReachableDeparturePorts (for the given 2ndary supply source) and store the index into the list of port hexes. Also stored is the path used to reach the departure port (so it doesn't have to be recomputed later).

2. Searches for Arrival Ports are performed for a major power or a minor country if (and only if) the country has a secondary supply source that could not reach a primary using an overland route (a.k.a, the supply source is OOS 2ndary), but the supply source has to be able to reach a port. Japan almost always fulfills this criterion because of the captured capitals it controls in mainland Asia.

3. Assuming #2 has been satisfied, sea areas that can be used (i.e., not blocked by the enemy or other overseas supply rules) are then computed for the given major power/minor country. The list of possible Departure Ports is trimmed to only those which connect to the just computed viable sea areas.

4. The list of Failed Arrival Ports is initialized to all the departure ports that could be reached by any OOS 2ndary using 0 or 1 BPH (computed in step #1). We already know those ports can not reach a primary via an overland route using 3 or less BPHs.

5. The full list of ports is then processed looking for viable arrival ports, skipping those in the list of Failed Arrival Ports and those that are not adjacent to a sea area identified in step #3. Also, if an adjacent sea area has been marked with a BPH of 1, the port is skipped (see steps #7 and #8 below). Of course if the port fails any of the other conditions for being used in a supply path, it is also skipped.

6. Processing a potential Arrival Port consists of trying to find a rail path from the port to a primary supply source. If the search fails, then the searched hexes are reviewed, and any port in the search path that could be reached using 0 BPHs is added to the list of Failed Arrival Ports. We already know that these ports can not be connected to a primary using 3 or less BPHs.

7. When processing finds a path from an arrival port to a primary supply source, the adjacent sea area is marked with the number of BPHs used for that connection. The minimum is 1, which counts the overseas path arriving in the port.

8. Successful sea areas identified in #7 are immediately propagated to all other sea areas; which means that the BPH number is propagated. The paths for both the arrival port to primary and propagated sea areas are stored so they do not need to be recomputed.

9. The search for arrival ports continues until all ports have been examined.

10. After all the Arrival Ports have been found, the list of OOS 2ndary are checked to see if their Departure Ports connect to a sea area with a low enough BPH number to satisfy the total BPH limit (which depends on the HQ's hex's weather).

11. The full path for each OOS 2ndary that has succeeded in step #10 is pieced together using 3 links: 2ndary to departure port, overseas, and from arrival port to primary. The full path is stored for the 2ndary supply source.

The advantages of this algorithm are several:

A. HQs that are cut off from reaching a primary supply source overland are not examined if they are unable to reach any port. This is likely to occur quite often in the USSR and China. No searches need to be done for overseas paths for those units.

B. Secondary supply sources that can not reach a port that connects to a sea area identified in #3 do not require processing for overseas routes. For example, if Japan loses control of the sea areas around its home country, no overseas supply computations are necessary for Japan.

C. Ports that can be reached by OOS 2ndary are removed from the list of possible Arrival Ports. This has the advantage of not having the ports in, say, Egypt, trying to reach a primary supply source overland multiple times.

D. Failed searches for Arrival Ports can add numerous entries to the Failed Arrival Port list. For example, if a Chinese HQ, cut off from reaching a primary supply source overland, can reach a sea area (e.g., the HQ is in a coastal hex) then searching all the US and Commonwealth and USSR ports for railway paths to, say, Chungking, only needs to be done once for each rail network. If San Francisco fails as an Arrival Port, then the program knows to skip all the other ports that connect via rail to San Francisco. Each rail network is searched only once for all OOS 2ndary for a major power. Note that the search algorithm searches for ANY primary supply source for the major power. Hence, it is only executed once for ALL primary supply sources.

E. Once a sea area has been found with a BPH of 1, then all the ports adjacent to that sea area are skipped. This means that when a major power controls numerous ports on the same sea area, we only have to find one Arrival Port that connects to a primary at a cost of zero BPH.

F. The propagation of sea areas with a BPH of 1 can have strange, but valid, effects. When searching for an overseas path for Colombo, Ceylon, the program finds a path to Liverpool, ignoring the presence of all the primary supply sources in India. That’s because an overseas link to Liverpool was found earlier and is immediately available, without performing any additional searches.

Finding supply paths for units and tertiary supply sources is vastly simpler, since the maximum BPH is 4 and rail hexes xost the same as other hexes. Note that rail networks are dynamic, since the movement of units can cut supply path connections.

Player Interface
I did a lot of work on the Supply Sources and Path form this month. It now identifies all the supply sources, primary and secondary, and shows how many units are being supplied by each. When you click on a supply source, the actual units are shown in a list at the bottom of the form. For secondary supply sources, the supply path it uses to reach a primary is shown. Clicking on a unit image, causes the supply path for the unit to appear. At some point I want to add a button for displaying all the units that are out of supply: both secondary supply sources (which may include cities) and units.

Internet - NetPlay
Nothing new last month. My work on NetPlay is delayed until I can coordinate with other programmers at Matrix Games/Slitherine. They have a system that they are using for other games and if possible, I want to fit MWIF into the design they already have working. From my preliminary reading of what they have done, that may be feasible. No sense reinventing the wheel.

PBEM
Nothing new.

Artificial Intelligence (AI)
I finished checking the names for the Areas of Operation and Land Regions so they conform to the ‘standard’ I set up. The major task remaining is to change the data file for the terrain, adding a digit to the end of the row of data for each land hex. There are 70,200 hexes, each of which has its own row of data. Mercifully, the all-sea hexes do not need to be edited (they use the default value).

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 this week.

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

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Nothing new.

Communications
Nothing new.

[Shannon V. OKeets]

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

Here is 2011 in review.

Accomplishments of 2011

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

I had two major health issues in 2011: surgery in August in Philadelphia for an ocular melanoma and surgery in October in Honolulu for a kidney stone. All-in-all I lost a couple of months of productive time due to those problems. My vision is still impaired, which limits the number of hours I can work on the computer each day to 6-8, down from 10-12.

Mitchell and Rolf joined the programming team at the beginning of the year. Mitchell had a serious health problem in July and was unable to work on MWIF thereafter, so we only had the benefit of his expertise for the first 6 months of 2011. During that time he did timing studies on why Theme Engine took so long to switch between major powers (3 seconds). Based on his analysis, he was able to reduce the elapsed time to effectively zero. With that accomplishment behind him, Mitchell turned his attention to NetPlay and completed refinements to NetPlayComTest, which will be included as part of the released MWIF product. NetPlayComTest lets players test their internet communications without having to run a MWIF game.

Rolf converted a couple dozen record types in the CWIF’s Windows Messaging code for communicating over the internet to MWIF’s Game Record Logs. Those record types were some of the most complex, which involve moving units. Rolf also did some work on the LAIO (Language for Artificial Intelligence Opponent) parser, which reads scripts written in LAIO. Later Rolf worked on fixing bugs in the sequence of play. His availability was limited, since he was holding down two other jobs at the time.

Hardware and Software
Delphi 2010 continued to misbehave badly during 2011. Delphi is the software development package I use to edit, compile, and link the source code into the executable program MWIF.exe. I successfully work around Delphi’s more serious problems but in the last quarter of 2011, it developed the nasty habit of simply not starting. After losing 5-6 days trying to figure out why the application wouldn’t start (when I clicked on the Delphi icon to run it, it went into an infinite loop trying to load a JPG). I finally found a writeup on the internet by someone who had had the same problem and documented a solution: remove the browsing history files created by Internet Explorer! That worked like a charm. Why the existence of those files should confuse the Delphi application baffles me; perhaps because Delphi executes a Java script when it starts up?

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). In my opinion, neither of these is important. Theme Engine is the software library I use to transform all the forms and buttons into something other than the bland gray backgrounds and images that are the Microsoft defaults. Early in the year I converted the Main from standard Windows style to Theme Engine. So, aside from the just mentioned two problems, Theme Engine is now in use for all 160+ forms and runs cleanly under Win XP, Vista, and Win 7.

Beta Testing
I released 85 new versions of the program with 1144 fixes to the beta testers during 2011. The version numbers ran from 7.01.02 through 09.03.01. For most of the year I focused heavily on fixing bugs in the sequence of play, hence the large number of new versions and bug fixes. In November and December I devoted almost all my time to rewriting the routine for determining supply. In the last week of December I also worked on NetPlay. Both of these mini-projects required all of my focus just to keep straight in my head what the code was suppose to do and how it did it. I’ve compared the complexity of coding the supply for World in Flames to solving Rubik’s Cube blindfolded. As you can see below, for those two months I effectively stopped working on fixing bugs reported by the long-suffering beta testers.

Here is a breakdown by month of the new releases and fixes:
• January - 10 new versions and 168 fixes
• February - 7 new versions and 118 fixes
• March - 8 new versions and 103 fixes
• April - 9 new versions and 128 fixes
• May - 9 new versions and 115 fixes
• June - 10 new versions and 79 fixes
• July - 6 new versions and 109 fixes
• August - 5 new versions and 69 fixes; surgery for ocular melanoma.
• September - 9 new versions and 117 fixes: surgery for kidney stone.
• October - 10 new versions and 128 fixes
• November - 1 new version and 9 fixes; supply rewrite.
• December - 1 new version and 1 fix; supply rewrite.

Aaron took over my master task list of bugs in August. He converted the simple text file I had been using to a spreadsheet and did an excellent job of synthesizing the disparate files from beta tester posts, saved games, and MadExcept reports, into a coherent mass. He prefaced the name of each file with MTL xxxx where xxxx was the Master Task List number for the bug. Working from his spreadsheet (which he updated daily) I was able to read about each bug, find the associated saved game, and reproduce the problem. In my opinion, the work he did on this offset the reduced number of hours I was able to work after my eye surgery, so my productivity remained about the same. Unfortunately, he came down with pneumonia in early November, after which I was once again left to my own devices. I learned from what he did and now use his system for naming files. However, maintaining the spreadsheet would take me more time than I would gain by its use.

Rob W. ran a complete set of tests on land movement for all unit types in all hex and hexside terrain types, under all weather conditions. That was hundreds of cases. I corrected the only bug he found in calculating land movement costs: when moving from a desert hex to an all lake hexside during snow.

Then Rob went through all the US Entry Options and US Entry Actions to make sure the code functioned 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 a saved game for each of them so he can determine whether my corrections work or not. I have fixed most of those bugs, with only a couple lingering on my task list.

Lastly, Rob ran a thorough set of Vichy tests: creating, playing, and collapsing Vichy France. I was able to fix some of them as he reported them but his final list in November added 17 new items to my task list.

I made good progress on Head2Head (a.k.a., HotSeat) play with the help of Orm. I believe that mode of play now executes cleanly.

As of today 132 of the 152 phases/subphases/sub-subphases/digressions that constitute the sequence of play are bug-free. In fact, during 2011 I was able to reduce all but a half dozen of those to zero bugs outstanding. Sadly, fuller testing revealed more bugs. The most recalcitrant areas were: Supply, Naval Combat, Production Planning, Conquest, and Vichy.

I’ve fixed all but one of the bugs concerning nested digressions. This last bug is when a naval unit aborts from a naval combat and is intercepted before it reaches port. Other than that, I have the 7 digressions working as intended, with normal processing of the sequence of play interrupted by a digression, or a series of nested digressions, and ultimately returning to the point in the sequence of play where the first digression occurred.

Most of the beta tester bug reports in the last half of the year arose from: (1) rigorous testing of how the program performs under a variety of obscure circumstances, and (2) going over the rules with a fine tooth comb. See the section on Rules Precision below for some examples of the modifications I made to fix bugs.

In July (I think) I added code to enable 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 another tool when setting up saved games for testing how the game performs with various optional rules On/Off.

Saved Games
Saving and restoring games was stable throughout the year. 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.

Michael created 5 Fast Start saved games. 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. All the Fast Start 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.

Starting in August, Aaron began building 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 modes of play (e.g., solitaire, head-to-head, NetPlay). But with the help of many other beta testers, he generated a large library of saved games. 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
The data and graphics for the map and units were mostly unchanged in 2011. I added a graphic to visually indicate when captured red factories are not producing. I still need to figure out how to indicate visually that a factory has lost a production point. There was a small data correction for a couple of City Based Volunteer units.

Throughout 2011 Rob continued to create new and update old naval unit writeups. For the land unit writeups both Adam and Jimm returned to work and did a batch of new writeups. In early summer, Aaron took over responsibility for maintaining the master files for all the unit writeups , which meant less work for me.

Scenarios
Barbarossa
I added code so the legal sea areas for this scenario are limited to the Black, Baltic, and Arctic Seas. I made an adjustment to the Production form to handle the fact lend leasing air units isn’t permitted.

Fascist Tide and Day of Infamy
These are the two half-map scenarios. For each scenario I made half the sea areas illegal to enter. For instance, when playing Fascist Tide (the war in Europe), entering the Indian and Pacific Oceans is not permitted. I also made corrections for the rules uniquely associated with the half map scenarios. 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.

The victory cities for these scenarios are now correct and so are the lists of which countries are legal. I fixed a couple of bugs when setting up Day of Infamy: New Caledonia now goes to Free France and Vichy France gets French Polynesia and aligns Madagascar. Japan is then 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 still need to add code for the external/European event of Germany collapsing Vichy France so it occurs at a fixed point in the game.

Optional Rules
Partisans
I fixed a few bugs related to setting up partisan units behind enemy lines after all the major powers have been set up. This subphase of Setup was tricky to code. Annoyingly, it has to perform a preparatory check to see if there is enough room for the units to be placed on the map. If, prior to placing the partisans on the map, the enemy player positions his units well, he can sometimes cover all possible placement locations with zones of control. That results in zero partisan units being capable of setting up.

Warlords
I fixed all reported bugs related to Warlords.

Off City Reinforcements and Territorials
I did quite a bit of work to fix bugs in the intersection of these two optional rules. Both are now bug free.

7 Unfinished Optional Rules for Initial Release
I worked on 7 incompletely coded optional rules that I want to include in the first release. To accommodate the associated rules I added 4 subphases to naval combat: Voluntary Abort by Walther Submarines, Kamikazes, and 2 ASW Pre-fire Attack subphases. All 7 of these optional rules still need work. They are listed below.

Convoys in Flames
This is difficult to code because it has so many pieces. I’ve added the code for the +2 penalty when trying to intercept auxiliary cruisers. That was a bear to get correct because of the complexity of search roll modifiers and search numbers. I 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.

City Based Volunteers
I made some progress on City Based Volunteers.

Unlimited Breakdown
I made some preliminary changes to support Unlimited Breakdown.

Kamikazes
This optional rule requires 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 appears listing all the bombers so the player can select which ones should wear head scarves.

Guard Banner Armies
This optional rule also needs a tailored Unit Dialog form so the player can select individual units for upgrades.

Rough Seas
No work done towards this in 2011.

Naval Supply Unit
No work done towards this in 2011.

Rules Precision (a.k.a. MWIF Game Engine and CWIF Conversion)
In the beginning of the year I spent a lot of time trying to debug the code for naval movement and naval combat. That became so tedious that I stepped back and revised the code for the internal record formats to determine into which sea areas/ports the units-in-hand can move. That is, once you select a group of naval units to be moved, the program has to check each hex the cursor moves over to determine if it is a viable destination. 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. I

The primary effect on game play of these changes to the naval movement code 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 thereby ‘daring' 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). At the end of the turn each player reviews his units in the Destroyed Units Pool and decides whether to scrap them or not.

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, I am waiting on coding the rest of S & S until I have PP bug-free.

I added some new code for the factory destruction phase. That was a little tricky because there are rarely occasions when a player wants 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. Most of the time the program ‘knows’ that destroying your own blue factories is senseless and can skip the phase completely.

At one point I had killed off most of the bugs related to creating Vichy France. In doing so 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. But then Rob went through the rules about Vichy line by line and word by word. In November he found 17 more bugs related to Vichy, that are a lump in my task list.

As you can tell from the following, many of the ‘bugs’ reported by the beta testers in the last 4 months of the year were due to them either: (1) rigorously testing how the program performs under a variety of obscure circumstances, or (2) going through the rules with a fine tooth comb. I made changes for:
• Imposing a setup restriction on the Communist Chinese units so they have to be within 9 hexes of a Communist controlled city. This number of hexes is greater than what is stated in WIF FE because of the MWIF change in scale for China.
• 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 decided by the major power on each side that has the most units still capable of fighting in the sea area.
• The WIF FE rules weren’t clear as what should happen 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 Tunisia (which is controlled by Vichy France), 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.
• Vichy France can be both hostile to and/or at war with Allied major powers. I revised the Relations form so those conditions are shown accurately.
• I 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.
• I fixed a bug where liberating France while Vichy France still exists wasn’t converting all Metropolitan Vichy France hexes to French control.
• I fixed a bug so Vichy units can only move into hexes controlled by Vichy or by a country with which Vichy is at war.
• 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 this rule ‘interpretation’ avoids is having newly acquired French naval units overstacked in, say, Toulon.
• I added code so Vichy France can not build pilots or offensive chits.
• 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 had been 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.
• Land units can now only be loaded on air transports if they are organized (Harry Rowland clarified this rule).
• I 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.
• I 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 associated 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.
• I 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].
• I 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.
• I removed the ability of land attacks being declared against a hex containing only enemy supply units.
• I 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.
• I fixed a bug where attacked partisan units were able to receive ground support from countries other than their controlling major power.
• 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 is 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).
• 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 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.
• Allied units in Italy that count towards the conquest of Italy garrison value must be controlled by a country at war with Italy (clarification from Harry Rowland).

Failures in the CWIF code for determining supply was something I discovered within the first 15 minutes I had access to a copy of the game. That was a month before I became involved in this project. I ignored that bug, and other supply bugs, for over 6 years but finally bit the bullet and tackled rewriting supply in earnest on November 1st. Actually, I had done a significant portion of the ground work for the rewrite back in 2009, but there was a lot left to do. I won’t go into the gory details here but there are many rules concerning supply sources and paths that increase the level of difficulty in writing the code. In particular, differences between major powers and minor countries, and cooperation between countries was a pain. I have supply mostly working now and will hand it off to the beta testers this week. Still remaining is the problem of getting the program to update the supply status of all units instantaneously and continuously during the land and naval movement phases (i.e., after each unit is moved).

Player Interface
I created 6 new forms in 2011:
• Supply Sources and Paths. This identifies all the supply sources, primary and secondary, and shows how many units are being supplied by each. When you click on a supply source, the supplied units are shown in a list at the bottom of the form. For secondary supply sources, the supply path it uses to reach a primary is shown. Clicking on a unit image causes the supply path for the unit to appear. There is a special button for displaying all the units and secondary supply sources that are out of supply.
• Liberation. This tiny form simply asks 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 whom 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 remain true to WIF FE, where you can liberate/revert a minor country during any later turn if you so desire.
• US Entry Actions. This form is purely informational but I think compared to RAC it is a much cleaner presentation of the information. Hopefully having this accessible from within a game will make these concepts easier for new players to understand.
• Private NetPlay Forum. This form is used by players to find opponents for NetPlay (i.e., playing over the internet). It is only available to players who have purchased the game, and is accessed from the Opening MWIF screen. It is also used for each game session, letting players restart/join their game in progress.
• Keyboard and Mouse Commands Help.
• About the Current Game. This 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 substantially modified 7 existing forms:
• OverStacked. I revised where in the code checks for overstacking occur. When overstacking is detected, this form appears.
• Choose Naval Combat. The changes I made here give more emphasis to the list of sea areas. These modifications were part of a general revision of the form to fix a few bugs.
• Drop Off Units. The changes here clarified 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.
• Select Units. The change was the addition of filters for movement points and range. For example, when examining a large stack of naval units, you can quickly select just those with 6 movement points. I also increased the size of the form so more units are visible.
• UnitData. This data summary panel now shows if 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.
• Status Indicators Help. This needed to be updated, especially the graphics, because it was a year out-of-date.
• Chat. CWIF had 3 forms for sending a message: Chat, New Message, and Recipients. I 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.

Within 9 minor forms 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. Visually there is no apparent difference. But TJvStringGrid does not crash the program, so the day I spent making the changes was well spent. I’ve now standardized on the use of TJvStringGrid throughout MWIF; it appears in 85 places.

I updated the Unit Status Indicators because there was a ‘hole’ in the design logic. 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 ‘flying’, even if they are not part of the naval combat. Another set of changes I made to the unit status indicators was to clarify when a unit was receiving HQ support and/or engineer support in a land combat. And to accompany the changes made to the UnitData panel mentioned above, I added indicators for units flying night missions and/or at extended range.

I added a couple of shortcut keys to access the US Entry Pools and US Entry Action forms. The third form in this group is the new US Entry Options form mentioned above. Together with the new section on US Entry that Aaron put together (see Players Manual below), these 3 forms should make it easier to learn this crucial game concept.

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

Internet - NetPlay
Rolf and I finished the conversion of CWIF’s Windows Messaging code for communicating over the internet to MWIF’s Game Record Logs. Rolf did a couple dozen, including some of the most difficult items which involve moving units. I did the final 80. The code now exclusively uses Game Record Logs and Indy10 (a Delphi software library that employs TCP/IP for internet communications).

The number of unique record types is around 400, one for each decision/event that occurs in the sequence of play. That number will probably increase slightly once we get heavily into testing NetPlay. For example, there are a bunch of optional rules which 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. Making those 20,000 edits was spread out over several years, since I knew they would be onerous to do and had been chipping away at them off and on since way back when. With Rolf’s help I was able to finally finish them off.

The conversions to GRLs were essential for NetPlay and PBEM (that is: whenever more than 1 computer is being used). The most difficult 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. Another reason behind creating the GRLs is that I am a firm believe in compartmentalized software. The GRLs isolate and completely remove NetPlay and Message Control code from all the details of 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 impinges on the NetPlay code. To be clear about this, the code for NetPlay and the code for the game’s simulation of WW II are mutually exclusive.

As stated at the beginning of this report, Mitchell completed NetPlayComTest, version 2.0 which I then integrated into MWIF. It can be called either as a stand alone program or from within MWIF when a game is in progress. For those of you who don’t know, NetPlayComTest 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 was to test the software for use by MWIF proper. But it will 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 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.

In December I added the ability of MWIF to access the Private MWIF NetPlay Forum. This forum is used by players to find opponents for NetPlay (i.e., playing over the internet). It is only available to players who have purchased the game. Access to the forum is via a button on the Opening MWIF screen. Besides finding opponents, it is used to start each game session, letting players restart/join their game in progress.

PBEM
Nothing new other than the decision to use the MultiPlayer++ system developed by Slitherine/Matrix Games for locating a PBEM opponent. This is the same underlying system used by the Private MWIF NetPlay Forum.

Artificial Intelligence (AI)
Peter finished the geographic breakdown for the AI Opponent. To go with that, I revised the documentation on the AIO command structure 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).

I changed the fundamental map data structure to include information on the geographical breakdown. 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 files listing the Theaters of Operation, Areas of Operation, Land Regions, and Sea Area Groups 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. 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.

The 16 TOs are: Western Europe, Eastern Europe (up to Siberia), Mediterranean, East Africa, West Africa, Middle East, North Asia (i.e., Siberia), South Asia (i.e., India), East Asia (i.e. China & Japan), Southeast Asia, Oceania (i.e., Australia), Pacific Ocean (central), Atlantic North America, Atlantic South America, Pacific North America, and Pacific South America. There are 126 AOs and 320 LRs. The major task remaining is to change the data file for the terrain, adding a digit to the end of the row of data for each land hex. There are 70,200 hexes, each of which has its own row of data. Mercifully, the all-sea hexes do not need to be edited (they use the default value).

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 geographical data, the AIO can now 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.

Another goal here was 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 then designates a Land Region, whose Commanding General decides in which hex to place the new unit.

After completing the geographic breakdown of the entire global map (a massive task which required assessing all 70,200 hexes), Peter worked on the data structures 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 strategic plan data defines 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. It isn’t easy to take the amorphous advice provided by the forum members and render it into a rigidly structured outline for processing by a computer program. For instance, late in the year he was grinding out the precise conditions under which France should surrender.

Rolf made some progress on completing the parser for LAIO (Language for an Artificial Intelligence Opponent) scripts.

Rules as Coded (RAC)
I made a couple of changes to bring RAC up-to-date with MWIF deviations from Rules as Written (RAW). For instance, I added a description of the Naval Abort Queue. On August 1st I uploaded the final version (number 46!) of RAC for the Matrix Games Editor.

Player’s Manual
After querying forum members, Aaron wrote up a new subsection for section 3.4, Advice to Players: Understanding US Entry Options, Actions, and Pools. Composer99 provided the heart of this material. I made some final edits and now new players should have a better chance of understanding this crucial aspect of the game.

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. I reviewed and updated section 10 of the Players Manual so it accurately lists all the RAC deviations from Rules as Written (RAW).

Aaron read through and made numerous changes/suggestions to the largest section of the Players Manual: 8 Players Interface. Equally important, he updated all the screenshots (~250) in the Players Manual. In many cases they had become woefully out of date.

The biggest editing changes Aaron made were 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 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 for 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 set of 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.

The beta testers were provided with the latest and greatest version of the Players Manual after Aaron’s revisions, and given the opportunity to make suggestions over a 2 week period. Aaron collected their comments and added another bunch of his own. While integrating that input into the draft, I read through all 400 pages of the Players Manual and made over 500 edits of my own. After typing in all these changes, on August 1st I uploaded the Players Manual with the up-to-date screenshots for the Matrix Games Editor.

I have a handful of small edits waiting the Matrix Games editor that I have accumulated since August 1st. There is only 1 glaring hole remaining 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.

Tutorials, Training Videos, and Context Sensitive Help
There is one missing screenshot for the Picture and Text Tutorials: Starting NetPlay game. The other 120+ pages are done and final.

This year I finished the design and code for the Interactive Tutorials. Each of the 10 tutorials will have a dozen or so ‘pages’ with 6 lines of instructions on the ‘front’ of each page and 7 lines of commentary on the ‘back’. The player can toggle between the front and back of each page, seeing either very terse instructions for entering keyboard and mouse commands, or commentary. The latter is the equivalent of a “voice over”. After performing the actions indicated by the instructions, the player clicks on the Next button to advance to the next page. I wrote a few sample pages to test the code and system design, but another 100+ pages of instructions with commentary need to be authored.

Throughout the year I made changes to the context sensitive help messages based on feedback from the beta testers. These are roughly 80% complete. The remaining 20% is not that difficult to do, since creating the missing content is done by cutting text from the Players Manual and pasting it into a TXT file.

I reviewed the training videos I made about 2 years ago. All 9 of the chapters I recorded have small discrepancies when compared with the current version of the game. But to my eye those are minor differences, and not worth re-recording an entire chapter. However, I need to redo chapter 6, since it references the production planning form and uses a completely out-of-date screenshot of that form. And chapter 9 also need to be redone because the Land Combat Resolution form has been substantially modified. But the other 7 chapters I think I’ll leave as is. I still have 3 more chapters to do: 10, 11, and 12, which cover naval movement, naval combat, and production & politics (i.e., declarations of war et al).

Here are the 12 chapters of the training videos.
Chapter 1 Introduction (4 minutes :10 seconds)
Chapter 2 Map Basics (20:27)
Chapter 3 Unit Basics (28:27)
Chapter 4 Sequence of Play (33:56)
Chapter 5 Turns, Impulses, Weather, & Supply (25:28)
Chapter 6 Main Form, Screen Layouts, & Map Views (46:31)
Chapter 7 Starting a New Game & Setting Up Units (55:40)
Chapter 8 Air Movement & Combat (23:43)
Chapter 9 Land Movement & Combat (43:46).
Chapter 10 Naval Movement (TBD)
Chapter 11 Naval Combat (TBD)
Chapter 12 Production & Politics (TBD)

Historical Video, Music, and Sound Effects
David Heath sent me the (nearly) complete set of music and sound effects files. I still need to insert ‘calls’ in the code to play these files at the appropriate points in the sequence of play. My design lets the player set how often the sound effects et al are played. That can range from never, to periodically, to always. Periodically would be something like: “every 10th time an armored vehicle moves play the sound effect.”

Marketing
Aaron worked 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. Virtually all of them had been out-of-date.

[Shannon V. OKeets]

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

Accomplishments of January 2012

Sorry for the delay in posting this but I have been hip deep in reinstalling Indy10 for the past couple days.

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

My retina specialist says there is measurable improvement in my eye: the melanoma has shrunk by 20%. Enough of the excess retinal fluid has been reabsorbed that the before and after pictures show a clear image where previously it had been cloudy to the point of being opaque. While all of this is definitely good news, I still can’t really use my left eye for much except avoiding walls. And it still messes up my ability to see out of my right eye. As for my other malady, I sent off a new sample to Chicago for urinalysis, so I should know in the next couple of weeks if the changes I have made in my diet have eliminated the risk of a second kidney stone. Life without chocolate is just so sad.

Hardware and Software
I have discovered bugs in the Indy10 library when sending HTTP requests that include cookies. Specifically, Indy10 successfully captures the cookie returned by the HTTP Server in the response to the first request, but does not insert the cookie into subsequent requests to the HTTP Server. This has caused me difficulty in trying to access the Netplay Private Forum for World in Flames. There is more on the later below.

After looking around on the web and asking for help, I learned the Indy10 version that ships with Delphi 2010 is 10.5.5. The most recent version is Indy 10.5.8, so I am in the process of upgrading to that, since the routines for handling cookies were substantially rewritten early in 2011. Yesterday I downloaded over 300 files, one at a time - arrgh. I’ve got clean compiles on the 5 libraries and was able to add them to the list of MWIF project packages. But when I try to compile MWIF itself, I get an E2202 fatal error: Required package not found (IndyCore). I’ve got a request in to the person who has been helping me with this. Hopefully he can tell me how to circumvent this error.

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

Beta Testing
I released versions 9.03.02 (11 fixes), 9.03.03 (9 fixes), 9.03.04 (1 fix), 9.03.05 (7 fixes), 9.03.06 (19 fixes) and 9.03.07 (9 fixes) in January. I have version 9.04.00 ready to go (12 fixes), once I successfully install Indy 10.5.8. That’s 7 new versions and 70 fixes for the month. One of my changes in 9.03.03 caused the Land Combat Resolution phase to be skipped, so I hurried out the new version 9.03.04.

I spent a lot of my time on NetPlay. The fixes were scattered over the places in the code that have a history of being problematic. Here is where I fixed more than 1 bug:
• Naval combat - 11
• Reinforcements - 5
• Naval movement - 4
• Air rebase - 4
• Land combat resolution - 3
• Supply - 3
• Vichy - 3
• Conquest - 3
• Surrender - 2
• Victory - 2
• Reserves - 2
• DOW - 2
• US Entry - 2

Rob W. ran a complete set of tests on air missions involving carrier air units (with the optional rule for them both On and Off). Basically, he went through Rules As Coded section 14.4 and tested to see if the code performs in accordance with those rules. For the most part it does. I fixed some of the problems he found and I have about 10 left to do.

Saved Games
I fixed one bug that I discovered in restoring a game - it hadn’t occurred in any of the beta testers games.

Map, Units, and Scenarios
I fixed a couple of odd setup issues. But mostly this code remained intact.

Optional Rules
Nothing new.

Rules Precision
With the quasi-consent of the beta testers, I set the maximum production multiple for the US at 2.25. According to RAW it could get higher if the US enters the war early and the game goes past 1945. This limit prevents the US production from getting astonishingly high.

Player Interface
Private NetPlay Forum. This form is used by players to find opponents for NetPlay (i.e., playing over the internet). It is only available to players who have purchased the game, and is accessed from the Opening MWIF screen. It’s also used for each game session, letting players start/restart/join a game in progress. Because this form performs so many tasks, I split it into 5 layouts. This is a common design solution choice by me to deal with busy forms. The player simply clicks on one of the radio buttons in a list of 5 and the form is transformed into the selected layout.

Registration and posting a new request for Seeking Opponent are two of the layouts. The others are for: sending and receiving messages from other players, reviewing the post in the Seeking Opponent database, and reviewing games-in-progress. The last serves a second purpose: starting/restarting/joining a NetPlay game.

Internet - NetPlay
I did a lot of work on the World in Flames NetPlay Private Forum. The paragraphs that follow are from my current draft on the documentation for that. Following the text are screenshots of the Registration and New Post forms. All these sections currently work except for posting to the Seeking Opponent database. For that I need to get Indy10 Cookies to function correctly. I would welcome comments on my draft. This is complicated stuff and I would like the text to provide a lot of help for players who have no experience playing games over the internet.

Introduction
Matrix Games/Slitherine Games provides a dedicated server to host a private forum for World in Flames NetPlay games. Herein the abbreviation NPF is used to reference the NetPlay Private Forum. The purpose of NPF is to enable players to find opponents, chat with other players about NetPlay games, and begin NetPlay game sessions.

Besides the obvious advantage of encouraging the creation of a community of World in Flames internet players, the NPF also simplifies setting up an internet session by automating some technical details. For example, the players don’t need to type in their own or other players’ IP (Internet Protocol) addresses.

The NPF is only accessible by clicking on the button labeled Private WIF NetPlay Forum on the Opening Splash Screen. When you click on that button, the program validates your serial number. The first time you log in, the program then displays the registration form.

Registration
Registration is required for using the NPF. It is a fairly painless process since the program looks up the serial number. Note that the serial number data field can not be edited.

Be careful when choosing your user name and password, since you will not be able to modify them later. The program records all the registration information in the data file NetPlayRegistration.txt so you do not need to type it in each time you access the forum. You can always call up the registration form (using Change Port, described in the next section) to modify the other 3 data fields: residence, email address, and port number. Getting back to the user name and password, very few special characters are permitted. You may only use: a-z, A-Z, _ (underscore), and 0-9. Specifically, blanks are not allowed. The user name must be between 4 and 20 characters and the password between 5 and 20.

The tricky data field is the port number. To start with, MWIF sets it to a default value of 5950. Try using that. If you are able to receive messages from other players, then you can forget about the port number and ignore all the information in the next section. If you do change the port number, please use a value between 5950 and 5959.

Port Number
To set the value for your port number, you need to understand how MWIF uses ports. Unfortunately, that requires understanding some background information. Perhaps you already know a lot about port numbers, but for those readers who haven’t acquired that knowledge, I am going to go into some detail here. I have found that the best way to communicate technical information is by example. So, for explaining about port numbers, I am going to describe how I set the port numbers for my home computers.

I own 3 computers: a desktop running Windows 7, a laptop running Vista, and a Mac running the Mac operating system. Those systems go through my router to connect to the internet (via my phone’s land line). Although it doesn’t have a mouse, keyboard, or monitor, the router is also a computer. These 4 computers form a LAN (Local Area Network), with the router in charge of transferring messages between the computers. Because the router is my only access point to the internet, it handles all outgoing and incoming messages between my computers and the internet.

Each computer on my LAN is assigned a LAN address by the router. The router always uses 192.168.0.1. The other 3 computers get a similar LAN address, with only the last digit changing: to 2, 3, or 4. Which computer gets which LAN address depends on when they are powered up: first come first served. The important point here is that the LAN address is dynamically set by the router as computers connect/disconnect. The laptop usually gets either 192.168.0.3 or 192.168.0.4.

When one of my computers sends a message out to a website on the internet, the router notes which computer did so. That lets the router take the website’s response and send it back to the correct computer. As long as the connection originates from one of my computers, the router knows what to do with the response messages it receives. But if a message arrives unexpectedly from somewhere in the world, the message itself has to have sufficient information for the router to know to which computer to direct the message. That is where port numbers come in.

A port number is comparable to an extension on a phone line. When a message comes into the router, the router uses the port number to identify which of my computers should get the message. If I only had one computer, then I would not need a specific port number to play MWIF over the internet. The default port number would be fine. But because I have multiple computers, I need to have a different port number for each of my computers. The port number is associated with the LAN Address. I set those up using my router’s software. After I have the associations between port numbers and LAN addresses in place, the router can translate a port number into a LAN Address, and knows to which computer to send the incoming message.

Each LAN Address has its own set of port numbers for MWIF. I’ve assigned ports 5950, 5951, 5952, and 5953 to 192.168.0.2 (a LAN Address), ports 5954-5956 to 192.168.0.3, and 5957-5959 to 192.168.0.4. Theoretically, I could assign just 1 port number for each computer on my LAN. But since I have 10 available, I used them all. If I buy another computer someday, I’ll have to revise which port numbers are associated with which LAN Address.

Continuing the analogy of a port number being an extension, the router’s IP (Internet Protocol) Address is comparable to a phone number. When my router is turned on, it connects to my ISP (Internet Service Provider) which assigns my router an IP Address. The value of the IP Address is dynamically assigned, so I can not depend on it being the same from day to day. Because all my computers go through the router, they have the same IP Address. In order to play MWIF over the internet, the players’ computers need to know the IP Addresses and port numbers for the other players’ computers. The IP Address acts as the phone number and the port address acts as the extension. This combination lets the Internet direct the message to my router (using the unique IP Address) and the router to direct the message to the correct computer (using the port number to look up the associated LAN Address).

Mercifully, NPF takes care of figuring out everyone’s IP Address so you never need to worry about that.
NPF records each player’s IP Address every time he logs in and stores the current value as part of the data it has for the player. Although IP Addresses can be dynamic, NPF always has on hand each player’s current IP Address when a game session starts. It sends that information out to all the players automatically: no typing required.

You might need to change your port number from time to time (see section 6.1.3.7). I do that when my laptop LAN Address changes. If it has the LAN Address 192.168.0.3, I use port number 5955. When it is given the LAN address 192.168.0.4, I use 5957. Clicking on the Change Port radio button lets me do that easily. After I change my port number, MWIF logs me out of the NPF and immediately logs me back in again, sending my new port number to the NPF so its data about me is up-to-date.

Messages Layout
After you have registered your game, (and when you log in after you have registered), MWIF brings up the NPF form so you can see what if happening in the forum. There is a slight delay at this time while the program connects to the forum and downloads data on the current status of the forum. Figure 6.3.1.C shows the layout for sending messages and reviewing those that you have received. The program will also ‘ping’ the NPF every 2 and a half minutes so the NPF doesn’t ‘drop’ you from the list of on-line players.

You can create a new message at the bottom of the form and then click on the Send Message button to send it to all the players currently on-line. The list of players currently on-line is displayed in the upper left. You might want to refresh that list from time to time. Whenever you desire, you can clear all the text from the New Message and Messages Received panels by selecting all the text (Ctrl-A) and then pressing Delete on your keyboard.

Seeking Opponent Layout
Players who are seeking opponents can post information about what they would like to play, where they live, and when they would like to play. Let’s call this ‘Requests’. Those requests are collected in a database and remain active for 1 month, or until they are removed by the original poster. The complete list of Seeking Opponent requests is displayed in a grid in the upper right of this layout. See section 6.3.1.5 for a description of each of the fields in this grid.

By clicking on a request in the Seeking Opponent grid, you can review all the replies to the request in the bottom right corner (see figure 6.3.1.D). You can send your own reply by entering it in the lower left corner and clicking on Seeking Opponent - Reply. If you want to review the proposed optional rules from the original post, click on the Optional Rules column in the Seeking Opponent grid. That will bring up the standard Optional Rules Help form (see figure 6.3.1.E).

New Post Layout
When you want to add a new post to the list of Seeking Opponents, click on the radio button labeled New Post. That brings up the form shown in figure 6.3.1.F. The data fields for this form are described fairly well in the form itself. Please only enter the name for one of the scenarios. If you have an interest in playing other scenarios, then create a separate post. The program stores the values you type in, so the next time you access this form, the form is preloaded with the values you used last time.

Side is the side you want to play. If you have no preference, you should enter Either in that data field.

Optional rules has a label that provides a general description of the optional rules you want to use. The purpose of the label is to communicate quickly to other forum members how you would like to play the game vis-a-vis optional rules. If you want to use a lot of optional rules in the Advanced Set, then that is what you should enter. Novice players will then know to avoid playing against you. But more experienced players may express an interest in being your opponent.

You can craft exactly which optional rules you want to use by clicking on the Specific Optional Rules button and using the Optional Rules Help form (see figure 6.3.1.D). Notice that this form has 4 buttons on the middle right which let you start from something close to what you want to use: Novice, Standard, Advanced, and Personal. From those starting points you can tweak individual rules On/Off by right clicking on them. Left clicking on an optional rule brings up a description of the rule; it is the same text that appears in the Players Manual. Your Personal Set of optional rules can be created using the Start New Game form (see section 4.3).

Days of the week is simply when you would like to play. This is a free form field so you could type in: “any day except Mo or Tu”. Hours per session is simply how long you want to play each time you start a session with your opponent. What you enter in these two fields has no effect on the game itself. Their sole purpose is to start a discussion with your prospective opponent about when and for how long you would play.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Rules as Coded (RAC) & Player’s Manual
I uploaded a half dozen changes to RAC for the Matrix Games Editor. These were all clarifications from Harry that I hadn’t inserted into RAC previously. A couple were recent, from November, but most were from the first half of 2011.

I wrote my first draft of section 6.3.3 (see above), which describes setting up a NetPlay game. Because of the introduction of the NetPlay Private Forum (NPF) into that sequence, most of the text and the screenshots are about the NPF.

Tutorials, Training Videos, and Context Sensitive Help
I decided to eliminate the one missing page in the Picture and Text tutorials. It was suppose to describe bidding for major powers, but that topic is a little too complex to describe in a half page of text. I simply cut it off my task list. Other than that, nothing new here.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Nothing new - unless you count the After Action Report that Aaron worked on diligently throughout January.

[Shannon V. OKeets]

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

Accomplishments of February 2012

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

My health shouldn’t be an issue in the near future. All the various specialists that have scanned and probed my inner being and sampled my precious bodily fluids over the past two months have grown bored with me as a patient. I’ll revisit them all in 6 months.

Hardware and Software
I am still unsuccessful in using the Indy10 library to send HTTP requests that include cookies. Early in February I gave this a small part of my attention but then bypassed the problem to work on more important things. I’ll take another look at it this coming 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).

Beta Testing
I released versions 9.04.00 (14 fixes), 9.04.01 (7 fixes), 9.04.02 (3 fixes), and 9.04.03 (4 fixes) to the beta testers in February. There wasn’t very much new for them because I was getting NetPlay to work. The last 2 of these versions had some NetPlay functionality for them to test. There’s more on NetPlay below.

Jimm has begun going through all the naval movement rules, testing them line by line, phrase by phrase. This is similar to what Rob W. did for the air missions. Basically, they go through Rules As Coded sections and run tests to see if the code performs in accordance with the rules.

Saved Games
Nothing new. I need to write some new code for restoring internet games. Mercifully the existing routines for saving games do not need to be changed. The trick to restoring them is to make sure both players are logged in to the NetPlay forum and using the same saved game: saved at precisely the same point in the sequence of play.

Map, Units, and Scenarios
Nothing new.

Optional Rules
Nothing new.

Rules Precision
Nothing new.

Player Interface
I am still tweaking the Private NetPlay Forum. That form is used to find opponents for NetPlay (i.e., playing over the internet) and start/restart internet games. This morning I added more checks for the registration data fields. Previously the error messages about invalid data had been vague to the point of being opaque.

Internet - NetPlay
I spent virtually the entire month working on NetPlay. After getting it to work the first time, it failed as soon as I made a minor change. Another week of work by me and it returned from the dead and breathed a few more breaths. Then it fell into a coma for a few days. To say the code was fragile is like saying a snowball has a long life expectancy in Hades. I finally figured out how to get the various client and server routines to work with the timer routines and the other code that keeps track of what has been sent and received over the internet and processed. Synchronization of ADG’s WW II simulation on multiple computers is a non-trivial exercise.

But after all that, it was a real rush to place a unit on the map on one computer and see the unit moved to the same location on the other computer. How fast does it work? Well, even sending the data over the world wide web results in the second computer updating its map faster than I can turn my head to look at the second computer’s monitor three feet to my right. When I send a batch of moves (e.g., restoring saved setup locations for several dozen naval units), it is just as fast. As far as humans are concerned, it is instantaneous. This is the advantage of a using a TCP/IP connection (continuously connected) instead of an HTTP connection (where the connection is reestablished for each transmission).

I’m working my way through the sequence of play fixing bugs related exclusively to NetPlay. For instance, I had to relocate the random selection of units from the French force pool for transfer to the Vichy French force pool for scenarios that start with Vichy already in existence. After my changes all the setup stuff that requires generating random numbers is separate from the work that can be done on both computers independently.

Let me explain that a little better. The person who starts a NetPlay game sends 85 GRLs (Game Record Logs) over to the second player’s computer. Those list all the optional rules, the scenario, the player names, and who is playing which side. Then both computers execute the next 8200 GRLs independently. This is equivalent to what over the board players do when they sort all the counters and place them in different pools (or cups). Once both computers are ready, the player who sets up units first sees a setup tray loaded with the units to be set up. The other player’s screen shows an empty map. As the first player transfers units from the setup tray to the map, both screens show the units being placed on the map. For me, who has written 10,000+ lines of code to make this happen, it is a miracle, or possibly just plain old fashion black magic.

There is some good news for you, dear reader. But it is bad news for me, the poor programmer. Matrix/Slitherine has decided to host all the NetPlay games on a dedicated server. What that means is that no one is going to have to deal with ports, firewalls, and all the other security/protection features that computers have these days. Instead, you simply log into the dedicated server, which validates your copy of the program, and then you’ll be able to play a game over the internet with a worthy opponent. The reason this design avoids security hassles is that you will being logging into the server and ‘requesting’ data. The same is true for your opponent. There won’t be any need for you to permit another computer to ‘call’ your computer and go through all the security related to starting a “conversation with a stranger”.

For me, this means that a lot of the work I spent weeks on over the past two months was unnecessary. Indeed, I now need to spend time writing code to support the new design. This is a classic aggravation for programmers: specifications changing after code has been written and debugged. It’s right up there with dysfunctional software tools and non-existent documentation for making programmers froth at the mouth. Down the road life will be easier for everyone, including me, since players won’t be asking about how to configure their routers and sate the demands of their security software.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Rules as Coded (RAC) & Player’s Manual
John (the person assigned by Matrix to be the editor for World in Flames) has completed editing RAC. I reviewed his edits and, aside from adding an index, RAC is ready to go to Marc (the layout guy - who places the graphics within the document and hand tailors each page). Once Marc is done his task, it goes to the printer.

I am going to have to substantially revise my draft of section 6.3.3 in the Players Manual, which describes setting up a NetPlay game (see the section on NetPlay above). However, I was able to finish up a few other odds and ends for the Players Manual. Right now the only area other than 6.3.3 that needs work is gathering examples of different screen layouts: placing the map and other forms in different screen locations depending on the number and size of the monitors a player has available. I would like to have a half dozen screen layouts so players can have one available that is sort of close to their own configuration.

Matrix is negotiating with several printers on printing RAC and the Players Manual. Because the size of these documents is larger than for other games, getting a good deal on the price of printing them is important.

Tutorials, Training Videos, and Context Sensitive Help
Context sensitive help is now done except for a half dozen entries for the NetPlay forms. There are ~350 entries completed which cover all phases/subphases in the sequence of play and all the forms. As reported last month, the Picture and Text Tutorials are done.

Rob W. has acceded to my request (it was more like me begging) that he make a first pass on the text for the interactive tutorials. There’s a bunch to do, but none of it requires programming. Being able to immediately see your work on the screen is another bonus; instant feedback is always nice.

The Training Videos (8 out of 11 completed) cover the same material as the tutorials. The difference between the two is active versus passive. The players can watch the Training Videos listening to the narrator comment on what he is doing. Alternatively, the interactive tutorials let a player control the mouse and keyboard, fiddling around with other stuff if he wants to. He won’t get as much commentary - which may be good, may be bad.

The match up between the Interactive Tutorials and the later Training Video chapters is:

11 Introduction to Interactive Tutorials (Training Video 6 part I)
This tutorial focuses on the Main form, the drop down menus, and the various buttons and panels that are tightly packed into the Main form, which is ubiquitously present during game play.

12 Screen Layouts and Map Views (Training Video 6 part II)
MWIF introduces two innovative game features: screen layouts and map views. Screen layouts enable you to control the visibility and positioning of dozens of forms. More importantly, it lets you design layouts where multiple detailed maps are visible simultaneously. Map views provide a dynamic means of jumping from one battlefield to another effortlessly.

13 Setting Up Units (Training Video 7 part II)
Setting up units only happens at the start of a scenario, although the setup tray is also used at other times. For example, it appears when bringing in reinforcements, placing reserve units on the map, and setting up the units of attacked minor countries.

14 Land Unit Movement and Combat (Training Video 9)
Land movement itself is pretty easy in MWIF, so the first part of this tutorial explains the Unit menu, Flyouts, overruns, and status indicators. The second part of this tutorial takes you from declaring attacks, through adding in artillery and air support, and ultimately to resolving individual combats. Invasions and paradrops are also covered in this tutorial.

15 Naval Unit Movement (Training Video 10)
Naval movement in MWIF is somewhat complicated. To start with, designating groups of naval units that are to move, and determining how far they can move, is quite different from land movement. Additionally, enemy naval units already at sea can intercept your naval moves. Lastly, picking up land and air units with naval transports is done during the naval movement phase.

16 Naval Combat (Training Video 11)
MWIF has three types of naval combat: air-to-sea, surface, and submarine. This tutorial takes you through all three types, including the assignment of losses, damage, and aborts.

17 Air Unit Movement (Training Video 8 part I)
Air movement is easy and this tutorial lets you conduct 3 types: strategic bombing, carpet bombing, and ground strikes. For the first two of these air mission phases, a strategic bombing attack is subjected to anti-aircraft fire, while the carpet bombing attacks go in unmolested.

18 Air-to-air Combat (Training Video 8 part II)
Air-to-air combat in MWIF has it own set of sub-subphases, and each combat can have multiple rounds. This tutorial lets you go through several air-to-air combats and experience a variety of outcomes.

19 Production (Training Video 12 part I)
Production in MWIF is done in two separate phases: Production Planning and Production. This tutorial lets you examine the details of both planning for production and actually building units.

20 Politics (Training Video 12 part II)
The last interactive tutorial covers the Declaration of War phase, which has many subphases, most of which deal with changing international relationships between major powers and minor countries.

Historical Video, Music, and Sound Effects
Nothing new last month, but I’m going to see if I can implement all of these in the first 10 days of March.

Marketing
Nothing new.

[Shannon V. OKeets]

April 1, 2012 Status Report for Matrix Games’ MWIF Forum

Accomplishments of March 2012

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

Hardware and Software
Matrix solved my difficulty with HTTP requests that included cookies. The problem was that the expiration date on the cookie indicated it was no longer valid, so the Indy10 software package did not use it. Once the Matrix programmers changed the cookie’s expiration date so it was valid, all was well. I am now able to access the NetPlay server’s Seeking Opponents database. The Matrix programmers also finished their changes to the NetPlay server so players no longer need to work with IP addresses, port numbers, and security issues to play the game over the internet. There is more on that topic below under NetPlay.

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

Beta Testing
I released versions 9.05.00 (4 fixes), 9.05.01 (29 fixes), 9.05.02 (31 fixes), 9.05.03 (2 fixes), 9.05.04 (27 fixes), 9.05.05 (15 fixes), 9.05.06 (15 fixes) , and 9.05.07 (7 fixes) to the beta testers in March. This is about my normal number of new versions (8) and fixes (128). While I was waiting for Matrix to make the necessary NetPlay changes (completed late in the month) I bore down on the bug list.

My first batch of fixes were for air mission bugs. Rob had detailed a lot of those and I was able to fix most of them; there are still 13 to do. Then I cleaned up all the setup, Declaration of War, and reorganization bugs. The last large batch I fixed were for naval movement and naval combat; I now have the naval bugs down to 7. The other large list of bugs to fix is in Production Planning. I keep trying to clean up other issues so I can focus exclusively on that phase of the game, but distractions abound.

Some of the new beta testers are getting involved. Peter v. in particular has been working closely with Rob W. on the interactive tutorials. That’s discussed more below.

Saved Games
Nothing new. I need to write a bit of new code for restoring internet games.

Map, Units, and Scenarios
Changed the Zuider Zee to IJsselmeer in the map data so the correct name appears on the map.

Optional Rules
Nothing new.

Rules Precision
Nothing new.

Player Interface
I automated the creation of default screen layouts for new players. In a nutshell, the program checks out what monitors you have on your system and makes an intelligent guess at the best size and location of important forms. This way the program appears tailored for your system. At the end of this report is an excerpt from the Players Manual that describes that automation in more detail.

Internet - NetPlay
I spent the last third of the month mostly working on NetPlay. I had to trash the code I had just gotten to work for exchanging data directly between two players’ computers. The new design is cleaner and easier to support but it was painful to remove code that functioned correctly.

The new design avoids the security hassles with one computer permitting another computer to ‘call’ and initiate a “conversation with a stranger”. Instead of having to deal with ports, firewalls, and other security/protection features, a player simply logs into the Matrix server dedicated to World in Flames to play a game over the internet with a worthy opponent.

The past couple of days I have been working with the JSON data structure, which is what the Matrix server uses for posts. I’m close to getting that to work. Behind the scenes, the JSON database stores the NetPlay “seeking opponent posts” by players. You will be able to post a request and reply to other players requests. Ideally this will let players find opponents for NetPlay games easily.

I still need to write new code to have the players’ computers send/receive messages and game data when playing over the internet. Once I get the Seeking Opponent and Messaging systems working I can take the final screenshots and finish the last few paragraphs of the Players Manual. Then I’ll be reduced to just tearing my hair out whenever I see a typo in the Players Manual.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Late in March John sent me his final edited version of the Players Manual. It was 523 pages without figures. Of course the number of pages depends on the page size, margins, font size, and line spacing. For instance, my version came in at 350 pages and that was with all the figures included. As of today, I have proofread 404 of John’s 523 pages and I should finish the rest in a few days. The figures are also almost ready for Marc (who will merge the text and figures). My last count was 271 figures for the Players Manual of which 265 are ready for Marc, with 3 screenshots to be retaken and 3 new screenshots needed for NetPlay.

After Matrix’s discussions with the printers it looks like the Players Manual and Rules as Coded will be separate volumes. There had been some consideration of making them a single volume containing two ‘Parts’.

Tutorials, Training Videos, and Context Sensitive Help
I corrected the graphics used in the 10th picture and text tutorial (sequence of play) so they use underlined text instead of colors. This had been a problem for some beta testers with difficulty distinguishing colors.

My wife updated the Content Sensitive Help messages for the revised Screen Layouts section and a few other sections that I updated while proofreading the Players Manual. Only the NetPlay message will need further revision - once I finish coding NetPlay.

Rob W. Has completed 8 of the 10 Interactive Tutorials, with Peter v. beta testing them heavily and finding a bunch of improvements for Rob to make. He and Rob are working out the details. I am trying not to get involved since I’ve got so much else to do. Hopefully with the new beta testers also putting those tutorials through their paces, the group will be able to buff and polish them without me doing very much.

One of the changes Rob and Peter decided on was to change the order of the tutorials so the sequence is air, land, and naval. Because naval units are the most difficult units to move and engage in combat, we’ve put it last - after the player has had a chance to build up his familiarity with unit movement and combat in general.

Because the beta testers were complaining that they didn’t understand what they were suppose to do with the interactive tutorials, I’ve created a title page for each. It gives a short overview of the tutorial and itemizes what you will have learned once you complete it. To address the problem of how to execute the tutorial, the title page contains some standard paragraphs at the bottom that explain the instruction form, which the player uses when going through the tutorial. If you want to see what the title pages look like, last week I posted the first 7 (#11 through #17) in the thread MWIF Game Interface Design. Rob just sent me #18, so I’ll do a title page for that tomorrow.

At this point I think the interactive tutorials will be a popular way for players to learn the player interface and other important game elements (e.g., setting up units, moving units, engaging in combat, and production).

Historical Video, Music, and Sound Effects
Nothing new. I am still trying to find a week of time to embed all of these into the sequence of play.

Marketing
Nothing new.



Excerpts from Players Manual section 8.6 Screen Layouts

Form Dimensions and Locations
Many forms have fixed dimensions and locations, though they can all be rolled-up by clicking on the small icon in the upper left corner of the form. That reduces the form to a thin horizontal bar (i.e., just the top of the form). You can restore the full form by clicking on that icon a second time.

The more important forms can be resized to meet your personal taste: detailed maps, the global map, the setup tray, the screen layouts list, map view lists, selectable units, naval review details, etcetera. Each screen layout stores the location (and usually the size) of the following forms:
1. Main form
2. Screen layout list
3. Map views list (a separate entry with size, location, and content is made for each major power)
4. Detailed maps (a separate entry with size, location, and display controls is made for each detailed map on the screen).
5. Global map
6. Sequence of Play (only the location is stored since the size is dynamic)
7. Setup tray (this can be expanded horizontally to see more units).
8. Units in hex (this can be expanded horizontally to see more units).
9. Selectable units (this can be expanded vertically to see more units).
10. Naval review details (this can be expanded vertically to see more units).
11. Naval review summary (a separate entry with size, location, and content is made for each major power)
12. [Task force details. Not used.]
13. [Task force summary. Not used.]
14. Land combat resolution
15. Dice
16. Chat
17. Interactive Tutorials

New Game.SLY
One of the most important things to know when starting a new game is that for each scenario there is a screen layout with the name “New Game.SLY”. These are the 11 SLY files that the program uses to start new games. The “New Game.SLY” files are slightly different for the 11 scenarios, since the number of major powers and the frontlines change from scenario to scenario. So, if you start a new game for the Barbarossa scenario, then MWIF uses the “New Game.SLY” file in the Barbarossa directory to determine the location and dimensions for all the forms listed immediately above.
.
.
.
If MWiF cannot find New Game.SLY, it automatically creates a New Game.SLY for the scenario. The newly created screen layout takes into consideration how many monitors are on the system and the size of the monitors. Based on that data, the program defines positions and sizes for all the forms listed above. It also defines a set of map views for each major power for each scenario, and stores that information within the new screen layout file.
.
.
.
After you acquire some familiarity with game play, it behooves you to spend some time modifying (i.e., Redefining) the “New Game.SLY” file to suit your own preferences.
.
.
.
Minimal Screen Size (1024 by 768)
Figure 8.6.C shows the default screen layout for the minimal configuration. It positions the Main form at the top left of the screen and the Detailed Map below it. To the right of the Main form, at the top of the screen, are the screen layouts list and the map views lists.

When other forms appear, they overlay the detailed map, and possibly even the main form - if they use the full 1024 by 768 footprint. The first few forms you see when you start a new game (lend lease and scrap units) and all the forms used during combat require this maximum footprint. In contrast, the setup tray has been made as small as possible and is positioned at the bottom of the screen, to maximize the amount of viewable area on the detailed map. So too the Main form, Screen Layouts list, and Map Views list have been scrunched down to as small a foot print as possible.
.
.
.
There are numerous helpful forms that you might want to examine during game play. The Global Map, Sequence of Play, Units in Hex, and Selectable Units forms are just some examples. With the minimum monitor size you will probably just toggle these on and off using the short cut keys defined for them. Or you could “roll them up” using the small up-arrow triangle icon in the upper left of every form.
.
.
.
Other Single Monitors
If you have more than the minimum width available, MWiF repositions several forms when it creates a new New Game.SLY. Figure 8.6.E shows the layout for a monitor that is 1280 by 1024. It has the Main form positioned somewhat to the right, leaving room for the Selectable Units form to appear between it and the left edge of the screen (i.e., in the upper left corner). The detailed map is extended to use almost the full width of the monitor, leaving room for the Global Map to peek through on the far right. Notice that the screen layouts list and map views lists are no longer cropped vertically as they are for a minimally sized monitor.

With very large monitors, the Global Map is placed at the top, making the entire width of the form available for the detailed map. Figure 8.6.E is an example of the default screen layout for a monitor that is 1920 by 1080.
.
.
.
Dual Monitor Systems
Dual monitors provide more real estate for the MWIF forms and therefore more flexibility in screen layouts. The automatic creation of the New Game.SLY file only considers the situation where there are two monitors. If you have more than two, then the two leftmost monitors are used. You can create your own New Game.SLY file for three or more monitors by starting with the one automatically created for two monitors.
.
.
.
The left monitor is devoted to the detailed map, with the setup tray placed at the bottom, when in use. The Selectable Units for appears on the left side of the left monitor when that form is active (as shown). The default position for the Units in Hex form is in the upper right corner of the detailed map (not shown).

The right monitor holds principally: the Main form, Global Map, Screen Layouts list, Map Views list, Sequence of Play, Naval Review Details, Naval Review Summary, and all other forms that appear during game play. The basic concept here is that your main detailed map is never obscured by large forms, and is omnipresent. The exceptions are the Setup Tray, Selectable Units, and Units in Hex forms; the reason they overlie the detailed map is so the “mouse distance” from a unit in those forms to a location on the detailed map is minimal. For example, moving the mouse back and forth from the setup tray to the detailed map can be tedious if the two are far apart and you have 50+ units to set up.

Of course, you can design the layout however you like, and there are going to be numerous variations given the variety of monitor combinations possible. Indeed, the entire purpose behind the screen layouts feature is to enable you to tailor MWiF to accommodate your particular hardware configuration and personal preferences.

[Shannon V. OKeets]

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

Accomplishments of April 2012

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

Hardware and Software
Matrix Games programmers fixed the problem with dropped server messages when using the NetPlay Forum to communicate with other players that are logged in. That capability is crucial for starting/restarting a NetPlay game. The same correction was made to the game server, which is used when playing an game over the internet. They also enabled deleting Seeking Opponent requests. This means that players are able to delete their posted requests to the Seeking Opponent database once an opponent has been found; therefore all listed posts should be active.

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

Beta Testing
I released versions 9.06.00 (9 fixes), 9.06.01 (10 fixes), 9.06.02 (1 fix), 9.06.03 (8 fixes), 9.06.04 (6 fixes), 9.06.05 (12 fixes), and 9.06.07 (19 fixes) to the beta testers in April. Version 9.06.06 was used by me but never uploaded to the beta testers. This is about my normal number of new versions (7) but half my typical fixes (65).

One reason there were so few fixes this month is that I have been running alpha testing for NetPlay, besides being time consuming (working with two computers), that means I was both discovering and fixing bugs rather than dividing the labor between the beta testers (finding) and me (fixing).

I fixed one bug in creating detailed maps which must have dated back to 2005. I’m kind of baffled that anything worked with this bug present (there were two separate copies of the detailed maps). See the comments regarding NetPlay below for most of the changes I made for the new versions I uploaded for the beta testers.

Saved Games
I revised the format for saved games (*.GAM) a couple of times so it contains the necessary data for switching decision makers (e.g., USSR, US, Italy) during setup for a NetPlay game. This was the reason version 9.06.06 was never uploaded for the beta testers.

Restoring NetPlay games now works. To accomplish this required a handful of coding changes. For instance, the autosaved games needed to be synchronized so they are created simultaneously on all computers. The program checks that both players are restoring the same game at the same point in the sequence of play. To make that determination, the program uses the Game Number and the Next Entry Number, which are written out to the GAM file. Prior to restoring a game, players should check those numbers to make sure they match. The program displays that information for each saved game when a player ‘considers’ whether or not to restore a game. When NetPlay executes, it checks for matching numbers and reports any discrepancy. The same system will be used for PBEM games.

Map, Units, and Scenarios
I removed Ceylon as part of the setup area for the Commonwealth in Guadalcanal. I also updated the naval unit writeups with the latest from Rob J.

Optional Rules
Nothing new.

Game Engine
Getting NetPlay to work forced me to revise the code for the Weather phase. It is now what I consider ‘beautiful’ code. Rarely do I go to the effort of writing code that might be considered beautiful. But the requirements for the weather phase are both few and weird. Having the weather preset for some scenarios but not for all of them is one strange aspect. Having it rolled every other impulse is another. In addition, MWIF rolls for the weather and reports it to both players. In practice that means reporting it for one major power for each player. After all players have closed the weather report form, the game advances to the next phase.

This combination of unusual requirements dictated that the code had to be crystal clear. Previously I had been patching the CWIF code to implement the weather phase, but the result became so confusing. So I more or less started over. Now the weather phase has its own module, similar in structure to all the other phases. Not a lot of code but it’s very easy to understand how it handles the unusual weather rules.

Setup is one of the most complex phases and I finally admitted that it also needed its own module with 3 subphases: (1) lend lease at the start of the game between major power on the same side, (2) placing each major power’s units on the map, and (3) placing partisan units on the map after all other units have been set up. I think of these as: lend lease, set up major powers, and set up partisans. It was a struggle to get these to execute correctly for NetPlay.

Lend lease involves all the major powers on a side which make decisions simultaneously. On the other hand, setting up the major powers is processed by each major power in a rigidly defined order. That is also preceded by a scrap units sub-subphase prior to randomly drawing units from the force pools. Always a pain to code was setting up the Nationalist Chinese and then the Communist Chinese - because they are one “major power” set up by two major powers. Setting up partisans is similar to setting up major powers, but with the kicker that there might not be an available hex for some units (“No room for the partisan unit on the map.”).

Here are the routines I gathered together in the Setup Phase module:
function SettingUpPartisans: Boolean;
procedure Setup__Initialization;
procedure Setup__ChangeSubPhase(const NewSubPhase: TSetupSubPhase);
procedure NextSetupMajorPower;
procedure NextSetupPartisans;
procedure Setup__Process;
procedure FinishedSettingUp;
procedure Setup__TerminateMajorPower(const MPI: TMajorCountries);
procedure Setup__Terminate;

Many other phases of the game needed revisions to support NetPlay. The most common problem is how to process an event so it is only done once, by one major power, but gets reported to all the players (e.g., setting up reserves). Again, the changes I made here were also required by PBEM. Mandatory DOW on major powers was a major hassle to revise but that now functions correctly. I currently have a similar problem with the mandatory DOW by Germany on Poland - that’s next on my list of things to fix.

Player Interface
Nothing new.

Internet - NetPlay
I spent the month mostly working on NetPlay. I finished the code for working with the JSON data structure, which is used for Seeking Opponent requests. Players can post a request and reply to other players requests. The intention of this functionality is to enable players to easily find opponents for NetPlay games.

I also finished the code for players to send and receive messages and game data when playing over the internet. Getting that accomplished let me take the last couple of screenshots for the Players Manual. A typical game starts with 13,000 game record logs being created and transmitted between computers. That’s a pretty severe test for the game server.

Sending and receiving messages while logged into the NetPlay Forum is useful for resolving any outstanding issues about starting a NetPlay game (e.g., negotiating about optional rules). It can also be helpful just before starting/restarting a game to coordinate when to start and how long the session will last.

One aspect of NetPlay that I now have working correctly is that the flags in the main form accurately report which major powers currently have decisions to make. Those flags also indicate whether the local player controls the major power or not: a large image means the local player control the major power, a small image means he does not. In addition there is a little ‘Waiting’ message in the main form when a player is waiting for another player to make a decision.

I’ve been able to run the Barbarossa, Global War, and Missed the Bus scenarios through to the completion of setup in NetPlay mode. A couple of beta testers have been able to do the same for Global War. I’ve actually run Barbarossa through several impulses, but that was by taking mostly Pass actions for both sides. Testing NetPlay takes a lot of effort because it involves either two people or running two computers with a lot of back and forth. Now that I have saving and restoring NetPlay games working it will be much easier. That starting every game from the very beginning got old super fast.

PBEM
Nothing new, other than the comments above about saved games and the game engine.

Artificial Intelligence (AI)
In making changes to support NetPlay I reviewed, and made a couple of changes to, the code determining which major powers are decision makers (I was able to reduce the code from over 1000 lines to 825). The important thing was to enable a player, who currently has no decisions to make, to have full access to the map, units, and various forms to review the status of his position vis-a-vis his opponent.

Another change I made for NetPlay, that has direct bearing on the AI Opponent code, was that I created a separate thread to run some code “in the background”. It is a minor technicality but I am happy to now have a working example of how to code background threads using Delphi. Virtually all the AIO code will execute in separate (i.e., background) threads. The intent is to have the AIO figure out what to do, while its human opponent is moving and clicking the mouse and using the keyboard. When the time comes for the AIO to decide something, it should be able to do so quickly.

Player’s Manual
I have finished with the text and screenshots for the Players Manual and Rules as Coded. Next up for my involvement with the documentation is proof reading the final layouts for how those will appear in print.

Tutorials, Training Videos, and Context Sensitive Help
Content Sensitive Help messages are finished (350+ messages totaling 693 kb). The 20 tutorials are also finished, although Rob W. is still worrying over the text for the interactive tutorials (261 kb). Rob wrote the text for all 10 of the interactive tutorials and Peter v. diligently went through them all, checking for clarity and typos. I made a bunch of code changes to support the interactive tutorials; there are still a couple of coding loose ends that I need to look into.

All that really remains here is for me to re-record the 6th and create the last three Training Videoes: 10, 11, and 12. The 6th (main form and drop down menus) needs redoing because I have seriously modified some of the forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics.

Historical Video, Music, and Sound Effects
I now have all the files I need for this except for the Italian National Anthem. For that I have a MP3 file, but I need a WAV file. All the sound files are WAV and the video files are WMV.

Marketing
Nothing new.

[Shannon V. OKeets]

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

Accomplishments of May 2012

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

Hardware and Software
Matrix/Slitherine Games programmers revised the code at the NetPlay server end and cut the log in time down to 10 seconds. Since it had been 90 seconds, that made a big difference for debugging NetPlay. This should be acceptable for the released product too. What is done during that period is to verify the game’s serial number, log in to the lobby, list the other players who are logged into the lobby, log into the Seeking Opponent database, download the list of all entries in that database, and list all the replies to the first entry in the database. This gives the player a lot of information on his screen immediately after logging in, without him having to enter more commands.

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

Beta Testing
I released versions 9.07.00 (22 fixes), 9.07.01 (1 fix), 9.07.02 (13 fixes), 9.07.03 (24 fixes), 9.07.04 (22 fixes), 9.07.05 (27 fixes), 9.07.06 (46 fixes), and 9.07.07 (8 fixes) to the beta testers in May. This is about my normal number of new versions (8) but 40% more that my typical number of fixes (163).

One reason there were so many fixes this month is that I was able to work with saved games from the beta testers that reproduced bugs immediately. That saved me the time and effort of trying to recreate the problems on my own. I am still running alpha testing for NetPlay, but the technical issues have been ironed out, so fixing those bugs involves working with the sequence of play rather than synchronization issues and queues. In particular, that means that the beta testers are able to find NetPlay bugs instead of me having to check every aspect of the game personally.

One point of my focus this month was to eliminate bugs in Production Planning (i.e., identifying who owns/controls the resources and factories and getting the former to the latter). There are a lot of detailed subtasks involved: mandatory fulfillment of trade agreements, convoy capacity, saving oil, and overseas routes. Since I hadn’t looked at these bugs seriously in over a year, they had accumulated to a count of 43. I reduced that to 19 and should be able to clean up the rest in the next week or two.

There seem to be a lot of minor details to straighten out. For instance, during the past month I added code so:
• When the US successfully DOWs a major power, a message is now shown to all the other players stating the totals in each of the 4 US Entry Pools.
• Bombers that fly naval air missions at extended range can now use extended range when returning to base.
• Added a check for an off-city reinforcement so it can only be placed in its home country. This came up when a home city was adjacent to a different, but friendly, country (e.g., Vienna next to Czechoslovakia).
• Excess overstacked naval units (just captured) in a damaged major port are destroyed by the owning player until stacking limits are met.
• Relocated code for calculating the production multiple bonus for being attacked in your home country so it is applied even if all the attacking units are destroyed.
• When Bessarabia is recovered by Rumania, a Hungarian fighter in Bessarabia was not being counted as having started the impulse in Rumania. Fixing this prevents the fighter from being destroyed because of foreign troop commitment limits.
• Rail movement of factories to cities wasn’t counting the factories “on the move” to the city, with the result that more than 2 blue factories could end up in a city.
• When Denmark is conquered, its territories become neutral. RAW doesn’t say what is to be done with naval units in those territories (e.g., Iceland). I decided to just leave them there. They can exit the port whenever they like but no additional units can arrive unless there is a DOW on the territory (which is now a minor country).
• I added a data field and code so the negation of the movement point penalty for “In the Presence of the Enemy” only occurs if the friendly unit (which provides the negation) was present in the sea area from the beginning of the turn. CWIF had this coded as from the beginning of the impulse (perhaps a rule change from long ago)?
• Foreign troop commitment limits should not be imposed on Commonwealth air units flying air missions into France. But it should be imposed on Finnish air units leaving Finland.
• I corrected the flag image for Free France in the Production Planning form - it was wrong in 2 of the 3 places where the flag is displayed.
• Placing partisan units on the map can be tedious because it is difficult to identify where they can be placed if there are only a couple of possible hexes. The program now identifies the first two eligible hexes for the player.
• I added code so the Commonwealth has only half of their activity limits once the United Kingdom has been conquered.
• I modified the bitmaps and labels for damaged oil resource markers so they state the resource’s hex. This lets the player choose which one to repair during production if there is more than one damaged oil resource.
• I added code to fulfill the rule in of RAC 8.2.10, Swedish resources to Germany. The consensus of the beta testers was: IF Narvik = Allied AND Arctic Weather is Snow or Blizzard THEN Swedish Resources are lost. Note that for Germany to receive the Swedish resources they always need to be convoyed through the Baltic Sea.

Saved Games
I continue to tweak the format for saved games (*.GAM). These are small changes, and some are merely me keeping everything neat (i.e., eliminating data fields that are no longer in use).

Map, Units, and Scenarios
For this category there were a handful of minor corrections this month. In Decline and Fall, Albania was being shown as controlled by Italy, which isn’t part of that scenario, so we changed Albania to neutral. There was an Ethiopian reserve militia appearing in the Commonwealth reserve pool at the start of scenarios where the Commonwealth had liberated Ethiopia; we moved it to the Commonwealth force pool. I needed to add a missing French partisan to the setup list for Darkness Before the Dawn scenario.

I also updated the naval unit writeups with the latest from Rob Jenkins.

For the Fascist Tide scenario I modified the USSR resources and factories in the same manner as described below for Barbarossa. Also in Fascist Tide, the Commonwealth is suppose to get 3 non-oil resources and 3 factories from outside the playable map area. I simply converted these to 3 production points and ‘gave’ them to the Commonwealth comparable to how the bonus production points are given to the Commonwealth when using the optional rule Food in Flames. There are no restrictions on these 3 PP. I still have to write new code for dealing with the Transfer Pool in the half map scenarios Fascist Tide and Day of Infamy.

The only thing I spent significant time on under this heading was getting the resource and factory counts right for Barbarossa. What follows is my analysis and resulting implementation.

Analysis of German production
From the scenario booklet: Germany receives 3 resources from Sweden that must be transported via the Baltic Sea to be useable, and 19 factories, 1 oil, and 14 other resources off the western map edge.

There are 20 factories in Germany on the Western European Map so 1 German factory is not usable. I made that the factory in Munich. Controlled by Germany on the Eastern European Map there are 3 non-oil resources, 3 oil resources, and 5 factories: Lodz, Breslau, Vienna, Bratislavia, and Bucharest. The Hungarian factory is available once Germany aligns Hungary and the Finnish resource once she aligns Finland. The Hungarian resource is available through a trade agreement before Hungary is aligned. Therefore, at the start of the scenario Germany should have 24 factories available for production.

There are 8 non-oil and 2 oil resources in Germany on the Western European Map so 1 oil resource is not usable and 6 non-oil resources have to be added. Germany receives 6 non-oil resources through trade: Hungary, Sweden (x3), Turkey, and Spain. She also gets 1 oil resource from an Iraqi trade agreement. Since it is easiest to modify resource counts using trade agreements, I eliminated the Iraqi trade agreement (minus 1 oil resource), increased the Spain agreement to 4 non-oil resources, added a new Bulgaria trade agreement for 1 resource, and include the 2 non-oil resources that Germany controls in Yugoslavia. This results in Germany getting 6 non-oil resources from outside of Germany. The subtraction of the Iraqi oil is offset by including both oil resources in Germany/Austria.

At the start of the scenario Germany has 5 oil resources: Rumania (x3) and Germany (x2); in addition she has 23 non-oil resources: 5 in the east (including the 2 in Yugoslavia), 8 in the west, and 10 in trade. So, if saving oil is possible, Germany should be able to keep 24 factories producing while saving 4 oil per turn.

Analysis of USSR production
From the scenario booklet: The USSR has 4 factories, 6 oil, and 11 other resources off the eastern map edge. Furthermore, from Jul/Aug, the USSR receives 5 resources via Archangel (while not frozen) and/or Murmansk (Soviet player’s choice), if those ports are Soviet controlled.

There are 7 factories, 7 oil resources, and 12 non-oil resources controlled by the USSR on the Asian and Pacific Maps. Therefore the USSR factory total has to be reduced by 3, its oil resources by 1, and other resources by 1. I eliminated the non-oil resource west of Sverdlovsk (hex 88, 39), the oil resource in Perm, and the factories in Sverdlovsk and Perm.

At the start of the scenario there are 22 factories, 3 oil resources, and 8 non-oil resources controlled by the USSR on the Eastern European Map. So the USSR has 26 factories, 9 oil resources, and 19 non-oil resources available. That gives her 26 factories at full production while saving 2 oil (if that is permitted).

As for the 5 resources arriving starting with the Jul/Aug, I made the following decision (call me Winston). All 5 resources arrive in Archangel, if that is possible. If not, then they arrive in Murmansk, if that is possible. Otherwise they are lost for the turn. The player has no involvement in this decision (Churchill decides). Not all the beta testers were happy with this decision (they wanted the player to be able to decide exactly how many resources went to each city as stated in the WIF scenario booklet). But implementing that would require more specialized code and provide marginal benefit in this 5 turn scenario. I have more pressing concerns than the potential loss a 4 production points to the USSR (in the worst case).

Optional Rules
I fixed a bug in reinforcements arriving in off-city hexes. But I still need to make one more modification to that code to fully solve the problem.

Game Engine
Supporting NetPlay has caused me to acquire a better understanding of what the game engine has to do in each phase/subphase/sub-subphase/digression. There are four tasks within each of those simulation elements:

1. Determine which major powers need to make decisions - this is done separately by each player on his computer. In some phases, e.g., Weather, a representative major power is chosen for each player.

2. Each deciding major power makes decisions - this is done by the controlling player for each of his major powers and the results of his decisions are sent to the other players so all computers have identical data on the simulation/game state.

3. A major power terminates making decisions - this is done by the controlling player for each of his major powers and the results of his decisions are sent to the other players so all computers have identical data on the simulation/game state. This may be as simple as closing the weather report form.

4. One computer (MasterMWIF) makes the determination that the simulation element (e.g., phase) is over - upon doing so, MasterMWIF determines what simulation element occurs next and sends that information to all players so all computers have identical data on the simulation/game state.

Like most things having to do with programming, this is pretty obvious in retrospect. But before someone (in this case, me) has thought it out completely and in excruciating detail, it is a large ball of fog with several nasty bear traps embedded within.

Now when I think of debugging the sequence of play for NetPlay, I focus on each of these 4 tasks separately. Did each computer determine the deciding major powers? Are the decisions made by one major power being sent correctly to the other players? Is each major power’s end-of-phase command being sent to all the other players? Is MasterMWIF, and only MasterMWIF, making the decision when the phase is over and informing all the players? All die rolls and other random events are made by MasterMWIF. Obviously that introduces additional complexity at times.

I methodically went through the code for each of the 152 simulation elements checking #3 and #4. I was already pretty sure that #1 was working correctly. Most of the remaining bugs lie in the realm of #2. There are 550+ GRLs (Game Record Log) record types that are used to send data on the different WIF decisions to the other players. And each of those has 6 code segments that must be done as a series of steps. All tolled, there are 44,000+ lines of code devoted solely to task #2.

Player Interface
Nothing new.

Internet - NetPlay
I spent half the month working on NetPlay.

I have moving and undoing moves working correctly for land, air, and naval units. What I am currently trying to fix are the combat forms so both players receive the decisions made by the other player and the die rolls made by MasterMWIF. For instance, when a ground strike is conducted, both players need to see the results (right now only one of them does). In naval combat the use of surprise points has to be communicated to the other player (that isn’t happening). And in land combat, after the results have been determined for a combat, the attacking player’s computer isn’t being informed that the subphase has changed and he has things to decide (i.e., advance after combat).

None of the problems here are really nasty, although there are a few than snarl rather aggressively. Like all bugs I am working my way through them one at a time, a chair in one hand and a whip in the other.

The beta testers have been able to run through an impulse and advance into the next impulse. A bunch of stuff runs smoothly:
• Setting up units in all the various places in the sequence of play where units get placed on the map.
• All the declaration of war subphases.
• Simple phases such as: lend lease, scrap units, weather, initiative, naval air, and air rebase.

A couple of the beta testers were able to complete the setup for Brute Force. They did that carefully, thoughtfully placing units on the map, as well as making good decisions for the other aspects of starting a game. It took them two and a half hours but they had no problems. In other words, NetPlay connections seem to be both stable and reliable.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Both the Players Manual and Rules as Coded are in the hands of the Matrix Games graphics person, who is doing the final layouts for how those will appear as PDFs and in print.

Tutorials and Training Videos
I still have one bug to fix for the tutorial on Production (so production can be performed for multiple countries within the tutorial). Otherwise the tutorials are done.

I need to re-record the 6th and create the last three Training Videos: 10th, 11th, and 12th. The 6th (main form and drop down menus) needs redoing because I have seriously modified some forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics.

Historical Video, Music, and Sound Effects
I now have all the files I need as WAV files. To those of you who provided information that let us find the Italian national anthem during the war years, thank you![&o] When I get a day or two free, I’ll insert the calls into the sequence of play to activate these glitz elements.

Marketing
Nothing new.

[Shannon V. OKeets]

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

Project Management
In the first half of June I monitored all the threads in the MWIF World in Flames forum daily. Then I took another one of my 2 week vacations. This time is was for a heart attack and triple bypass surgery. I am sure that you will greet this information with as much joy as I did.

I was in the hospital for 12 days but got out a day earlier than the doctors’ had expected (4 days after the operation). The surgery itself went well and it is just a question of mending my body and my ways. For the latter, I have set up a structured daily routine, with meals at fixed time, as well as exercise and rest. There is an absolute maximum on the number of hours I can work (5 hours a day), but that is only if I am doing well and keeping up with my exercise and rest regimen.

Bypass surgery involves cutting open the sternum, rerouting the arterial blood flow to the heart muscle so the entire heart is getting oxygenated blood, using thin titanium threads to reconnect the bone back together and then suturing the skin tissue. Like for any other broken bone, the healing process is 6-7 weeks. Until then I can’t lift anything weighing 8 pounds or more.

I am being careful about going back to work. So far the only thing I have done is write this short status report. I’ll probably wait another couple of days before putting my task list back in order and up-to-date. Then I’ll ease the car back into gear and see how it runs on the straightaways.

Sorry that I don’t have better news.

[Shannon V. OKeets]

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

Accomplishments of June and July 2012

Project Management
As indicated by the title above, this report includes items that were done in June and July. My last month’s report hadn’t provided any details on June.

I am mending the MWIF code, mending my body, and mending my ways. It’s now 5 weeks since my bypass surgery and a month since I left the hospital. The Docs say I’m doing extremely well. I’ll see all 3 of them again in the middle of August. Hopefully that will be my last visit with the cardiac surgeon. The cardiologist says he will still want to see me annually. My visits to my internist are more frequent, monthly or bi-monthly. He draws blood each time and does a fairly full analysis of its chemical composition.

I’m taking a 1 hour walk each day, which is mostly boring, and my body is insisting on 10+ hours of sleep daily. That doesn’t leave a lot of time for work - which is just as well, since I have trouble staying focused for more than a couple of hours at a stretch. I’ve lost 24 pounds since I left the hospital, most of which was during the first 2 weeks. But I continue to lose a pound every 4 or 5 days. Weighing less is really great (45 pounds more to go) since it increases my flexibility and makes changing clothes a lot easier: my clothes are now oversized so they go on effortlessly and my pants fall off as soon as I undo the button at the waist.

In the first half of July I was pretty much good for nothing, although I did manage to bring my task list up-to-date. That was somewhat difficult to accomplish since I had dropped a lot of balls when I went into the hospital. It took me a while to figure out what I had actually completed and what was only partially done. Also the beta testers had reported a lot of items over the 3 week period I wasn’t keeping a close eye on them. I had to add all their new bug reports to my task list. In the second half of July I was able to get back to working on bugs again.

Hardware and Software
Matrix/Slitherine Games programmers made more revisions to the code at the NetPlay server end. I haven’t tested those changes yet. The goal is to cut the login time from 10 seconds to under 5 - perhaps that has been achieved.

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

Beta Testing
In June I released new versions 9.07.08 (13 fixes), 9.08.00 (13 fixes), 9.08.01 (25 fixes), 9.08.02 (9 fixes), and 9.08.03 (10 fixes) to the beta testers. That totals 5 new versions and 70 fixes. I didn’t release a new version in July although I am close to doing so - I want to finish up the work on factory destruction and repair which just kept dragging on and on (more about that below).

I found another half dozen small items to fix in Production Planning. Simply going through the phase myself I found some small (mostly cosmetic) things to improve. While I was also able to whittled down the number of Production Planning bugs from 19 to something smaller, the beta testers quickly identified new bugs in that phase to bring the count back up to 19 - rats. In the middle of July I worked on eliminating all the remaining bugs in Production. That phase was working cleanly in almost all cases but there were a few odd elements that needed specialized code:
• Lend Lease air units mistakenly appearing in the build ahead pool
• Missing a separate row of possible units to build for SubHunters
• Repairing damaged oil resources (e.g., in Ploesti)
• Repairing damaged factories.

Saved Games
Only small changes to support SubHunters and damaged factories.

Map, Units, and Scenarios
For the start of Decline and Fall I changed control of New Caledonia and some other islands in the Pacific from Germany to France.

Optional Rules
In the Production form I added a new line for SubHunters to the list of items on which a player can spend build points. There is still more code to be written for SubHunters (e.g., for performing their missions) but at least now they can be built and arrive as reinforcements.

I spent over a week at the end of the month working on getting the code for damaging and repairing factories to work correctly (I still have a few small items to fix). CWIF had only completed about a third of this code. To start with I needed to determine what the rules were, which took me several passes and a lot of help from Orm. There is more on this at the end of this report. The optional rules for Construction Engineers and Factory Construction & Destruction necessitated a lot of branching logic.

Game Engine
Nothing new.

Player Interface
Nothing new.

Internet - NetPlay
Probably the biggest difficulty with NetPlay is getting the decision maker(s) for each phase, subphase, sub-subphase, and digression correctly identified on all computers, then having their decisions communicated to all players, and ultimately having the ‘phase’ end and transition to whatever comes next. Towards that goal, I modified the following to support NetPlay:
• Carpet bombing phase
• Strategic bombing phase
• Undoing land moves (reverting hex control to what it was previously on all computers)
• Weather phase
• Ground support phase
• Paradrop phase
• Land combat resolution phase
• Air transport phase
• Setup (combining multiple oil point counters in a hex into a single counter)
• DOW on minors, choosing the controlling major power, and setting up units for the attacked minor
• Displayed available Activity Counts (e.g., land moves, land attacks, etc.)
• Processing of a half dozen Naval Combat subphases - there are more to do, including the use of surprise points.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new: both the Players Manual and Rules as Coded are in the hands of the Matrix Games graphics person, who is doing the final layouts for how those will appear as PDFs and in print.

Tutorials and Training Videos
I still have one bug to fix for the tutorial on Production (so production can be performed for multiple countries within the tutorial). Otherwise the tutorials are done.

I need to re-record the 6th and create the last three Training Videos: 10th, 11th, and 12th. The 6th (main form and drop down menus) needs redoing because I have seriously modified some forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics.

Historical Video, Music, and Sound Effects
I now have all the files I need as WAV files. What’s needed is for me to insert calls into the sequence of play to activate these glitz elements.

Marketing
Nothing new.

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

Here are my in-line code comments on factories. The first section describes the MWIF internal Class TFactoryHex, supplemented by my understanding of the rules. The second section presents a more detailed explanation of how the rules are implemented by MWIF (e.g., what routines get called when). I almost always start coding a complex set of rules with this sort of writeup. The nitty-gritty implementation details are added as I code. What I find so useful about this approach is that by reading through what is suppose to happen I can often anticipate problems in advance of actually writing code. In addition, if I need to make changes later, I have this clear and concise description of what the code is doing as a quick reference.

// ****************************************************************************
// Class TFactoryHex.
//
// A TFactoryHex can contain up to 3 factories. The factories in the hex are
// differentiated using an index (0-2). Red factories are always listed first
// followed by Blue and then Green. Printed factories are designated Permanent
// internally.
//
// Green factories are those that were newly built (i.e., they are not
// Permanent).
//
// There is only one difference between Blue and Green factories:
// (1) Blue factories that are 'destroyed' are merely Damaged, and moved to the
// Repair Pool, while 'destroyed' Green factories are removed from the game.
//
// Factories can only be 'destroyed' if playing with the optional rule
// FactoryConstruction (which includes the rules for factory destruction). Note
// well that the following paragraphs about destroying, damaging, and repairing
// factories only apply if the optional rule FactoryConstruction is being used.
//
// There are 2 ways in which a factory can be 'destroyed':
// (1) By strategic bombing,
// (2) During the Factory Destruction phase when a major power chooses to
// destroy a Blue or Green factory using one of its land units that occupies
// the hex.
//
// If a Red or Blue factory is 'destroyed', by any means, then it becomes
// damaged and a unit representing the damaged factory is placed in the Repair
// Pool. If a Green factory is 'destroyed', it is removed from the game.
//
// Repair of a damaged factory in the Repair Pool is initiated during the
// Production phase by spending build points to repair the factory. The factory
// then arrives as a future 'reinforcement'. In actuality, upon arrival the
// factory simply changes from damaged to usable.
//
// If using the optional rule ConstructionEngineers, then an engineer unit must
// be in the factory's hex during the Production phase in order to spend build
// points to repair the factory.
//
// Both Captured and Recaptured (see below for definitions) Red factories are
// not usable if using the optional rule ConstructionEngineers until an engineer
// unit is in the factory's hex during the Production phase. There is no build
// point cost to make these factories usable.
//
// ++++++++++++++++++++++++++++++++++
// Code Implementation for factories.
// ++++++++++++++++++++++++++++++++++
// A factory typically has no associated unit counter. Instead, the factory is
// displayed as an icon in the hex. For example, this is true for all Permanent
// (Printed) factories. Temporary factory units are created under four
// circumstances, when:
// (1) a new factory is built [FactoryCreate -> RLID_UCrF -> PickFactory],
// (2) a factory is moved [FactoryCreate -> RLID_UCrF -> PickFactory],
// (3) a factory is damaged [DamageAFactory -> RLID_FacD ->
// FactoryDamagedOnMap -> FactoryDamage ->
// PickFactory, and
// (4) an undamaged Blue or Green factory is controlled by the enemy
// [SetHexControl -> TFactoryHex.SetOwner -> PrepareMoveReservePool /
// PrepareMoveRepairPool /
//
// In all these cases the temporary factory units are placed in off-map pools so
// players can see the status of factories that are not currently usable but
// which may become usable in the future.
//
// Building a new factory causes a New Factory unit to be created and placed in
// a Production Pool. Once the factory arrives as a 'reinforcement', the New
// Factory unit is removed from the game and the factory icon in its arrival hex
// is modified to display a new Green factory.
//
// Moving a Blue or Green factory by rail causes a Moving Factory unit to be
// created and placed in a Production Pool. Once the factory arrives as a
// 'reinforcement', the Moving Factory unit is removed from the game and the
// factory icon in its arrival hex is modified to display a new Blue factory.
// Some scenarios start with the USSR having Moving Factory units in the Setup
// tray and/or a Production Pool. The USSR player can placed these factories in
// any valid city hex in the USSR. However, all factories that are moved during
// a game have their destinations specified by the player when they are first
// moved. Those destinations cannot be changed and the factory must arrive in
// the city hex originally chosen by the player.
//
// 'Destroying' a Red or Blue factory during strategic bombing causes a Damaged
// Factory unit to be created and placed in the Repair Pool. Destroyed Green
// factories are simply removed from the game.
//
// When control of a factory hex changes sides, there are 2 possibilities:
// (1) the factories are 'Captured' by the enemy, or
// (2) the factories are 'Recaptured' by the side that originally controlled it.
// For instance, Germany occupying Lille 'Captures' the factories in the hex;
// while if the Allies later occupy Lille, then they 'Recapture' the factories.
//
// Capturing or Recapturing a factory hex containing damaged factories does not
// affect the damaged factories, unless they are in the process of being
// repaired. If they are being repaired, then that process is aborted and the
// damaged factory units are returned to the Repair Pool.
//
// Undamaged Blue and Green factories are never usable when Captured, but are
// immediately usable when Recaptured.
//
// Undamaged Red Factories are immediately usable by the new owner when they are
// Captured or Recaptured, unless the optional rule ConstructionEngineers is
// being used. If the optional rule ConstructionEngineers is being used, then
// for each undamaged Red factory in a Captured or Recaptured factory hex, a
// TFactory unit is created and placed in the Repair Pool.
//
// When a factory hex is Recaptured, for each undamaged Blue and Green factory,
// there should be a TFactory unit in the Reserve Pool. That unit is removed
// from the game and the corresponding Blue/Green factory immediately becomes
// usable by the original owner.
//
// If during the Factory Destruction phase a Blue factory is destroyed, its
// TFactory unit in the Reserve Pool is converted to a Damaged Factory unit and
// moved into the Repair Pool. Destroying a Green factory causes its Factory
// unit in the Reserve Pool to be removed from the game.
//
// During the Production phase, a check is made to see if there are any TFactory
// units for Red factories in the Repair Pool. If one is found, a check is made
// for an engineer unit in the corresponding factory hex. When an engineer unit
// is found in the hex, the TFactory units is destroyed and the Red factory becomes
// usable.
//
// During the Production phase, a player may repair damaged factories using
// build points. If using the optional rule ConstructionEngineers, then an
// engineer unit must be in the factory's hex. When a factory is repaired, the
// Damaged Factory unit for the repaired factory is moved from the Repair Pool
// to a Production Pool to arrive as a reinforcement. Upon arrival, the Damaged
// Factory unit is removed from the game [ProcessReinforcement -> RLID_FcRp ->
// FactoryRepair] and the factory is shown as usable on the map (and in the
// Production Planning form).
// ****************************************************************************

[Shannon V. OKeets]

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

Accomplishments of August 2012

Project Management
I monitored all the threads in the MWIF World in Flames forum daily. Regrettably, I was only able to work effectively 3+ hours a day in August. More about my health in the next 2 paragraphs, but feel free to skip that.

I had a final visit with my cardiac surgeon, who says I’m doing fine. My cardiologist wants to see me again in October, mainly because I was only using 95% of my full lung capacity - I think that has been rectified in the two weeks since I saw him. Likewise my internist wants to see me again in October, when he’ll draw blood and do an analysis of its chemical composition. When they did that 2 weeks ago, my blood sugars were back to normal so I am no longer taking insulin. I’ve also cut my dosage of one med in half to 12.5 mg twice a day. That med was making me sleepy and impairing my ability to focus (i.e., work on code). After reducing that med a couple of days ago, I’ve increased my work hours to 4 a day. I would like to get back to 5-6 hours productive hours. Right now I am taking low dosages of 4 meds daily, which I guess will continue for the foreseeable future.

This coming week, as a scheduled 6 month followup, I’ll have sonography done on my kidneys, looking for kidney stones. That should be a non-event since I routinely drink 60-80 ounces of water/milk per day, which aggressively flushes my kidneys. The following week I’ll be in Philadelphia for 5 days for a scheduled annual followup on my eye surgery (on my left eye). I hope I can persuade them to let me have the cataract in my left eye removed and replaced with an artificial lens. The radiation treatment appears to have accelerated the formation of that cataract. In May I was able to read text with my left eye, but now it is so bad I can’t use it to count my toes.

Hardware and Software
Matrix/Slitherine Games programmers made more revisions to the code at the NetPlay server end. I haven’t tested those changes yet. The goal is to cut the login time from 10 seconds to under 5 - perhaps that has been achieved.

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

Beta Testing
In August I released new versions 9.08.04 (12 fixes), 9.08.05 (13 fixes), and 9.08.06 (14 fixes) to the beta testers. That’s only 3 new versions and 39 fixes. I’ve made 8 more fixes for version 9.08.07, but I won’t release that until I’ve gotten my rewrite of the supply determination code done (there is a long discussion of that in Game Design below).

I whittled away at the air/naval/land movement and combat bugs. I now have these down to 17 total, some of which are important, some of which are not, and some of which are so old I am not even sure they still exist. 17 is a small enough number that if I just bear down on them for a week, I should be able to eliminate them all.

Saved Games
I added a couple of AutoSave calls so they happen whenever a new major power has something to do in the Reinforcement phase. I also added the subphase to the name of the saved game file for that phase.

Map, Units, and Scenarios
I received some more naval unit writeups from Warspite.

Optional Rules
I fixed a couple more bugs in the optional rule Off-city Reinforcements where it had interactions with the optional rules for Territorials and Divisions.

I improved the display of information in the Universal Unit Data Panel on lost production points and damaged factories. The UUDP is part of the omnipresent Main form, so when the player moves the cursor over a hex, the UUDP updates with information on how many production points have been lost to strategic bombing and the status of factories in the hex. Also included is info on damaged oil resources (e.g., in Ploesti). During game play it’s important to know these things when planning strategic bombing missions.

Game Engine
The beta testers have been nagging me for a long time to fix the bugs in (mostly overseas) supply. My solution for the various supply bugs was to rewrite the CWIF code from scratch. I completed most of that last year:
1. identifying valid primary supply sources for major powers and minor countries,
2. identifying possible secondary supply sources for same,
3. identifying valid secondary supply sources by finding a railway path to a primary supply source,
4. using overseas supply links for secondary supply sources only when no pure land link exists,
5. identifying which valid supply sources can be used by cooperating major powers and aligned minor countries,
6. determining which units are in supply by tracing a link composed of basic path hexes overland and/or overseas to a valid supply source.

I devoted the last half of August to working on supply. There were some bugs in the last item listed above that I just spent the last 6 days tracking down and correcting (hence this report being late). What was completely uncoded was identifying tertiary supply sources: those are potential secondary supply sources which could not trace a railway path to a primary, but can trace to either a valid secondary or tertiary.

As of today I’ve fixed all the bugs in the supply code I’ve written, and I have tertiary supply working for major powers. Still left to do is:
7. writing code to differentiate between tertiary supply sources which are ‘pure’ for a major power and those which rely on supply sources from cooperating major powers; the latter cannot be used by minor countries,
8. taking the code for determining tertiary supply for major powers and cloning it for minor countries,
9. writing a routine to determine if a supply path, that was previously valid, is still valid; this will drastically reduce the time required to recalculate supply,
10. check and evaluate when supply is calculated/recalculated during game play (the beta testers have reported instances when it hasn’t been recalculated when it should have),
11. reduce the time required to calculate supply the first time (i.e., from scratch).

All except the last item are straightforward. Getting the time down to under 3 seconds for the original supply determination is going to be difficult. For small scenarios, like Barbarossa and Guadalcanal, calculating supply is always instantaneous. That’s also true for scenarios where there aren’t many units on the map (e.g., at the start of the Global War scenario). But for the later scenarios, like Brute Force and Decline and Fall, where there are hundreds of units spread out all over the map, the original supply calculation is taking 1-2 minutes, which is totally unacceptable. I need to do some more timing studies to see where the program is spending/wasting all that time. One place is when it tries to find a railway supply path for the Commonwealth from Baghdad to India, going through the USSR, China, and Burma. For instance, it is conceivable that a railway path could be found from Baghdad through the USSR and China to the rail hexes in Burma and overland to the rail hexes in India and then to a primary supply source; or from Baghdad to Murmansk and from there overseas to England. I’ve timed that [failed] search at ~15 seconds. I have a plan for how to reduce it drastically, but that will require some new code.

I should be able to finish up supply in the first couple of weeks of September. While I am working on this, I set virtually everything else aside. It takes my full involvement in the supply code (11,000+ lines) to keep it straight in my head. Side jaunts into naval combat and production planning have to be delayed for later.

Here are 4 screenshots of supply determination in MWIF. The units’ supply status indicators, some of which are incorrect, were calculated using the old CWIF code.

In the upper left von Bock is supplying units in the Crimea, during rain, via the Black Sea. Because von Bock is in the port Nikolayev, the basic path hex (BPH) cost from the Black Sea is only 1. That’s shown in the path for the 5th Mtn. Division. It also lets the Alpine mountain corp trace 1 BPH to the port Evpatoria (which the Italian units are occupying) and 1 BPH to von Bock for a total of 2 BPH (in rain the maximum BPH for a path is 2). I think many over-the-board WIF players are likely to not see this path - I was surprised and thought it was a bug at first. In the upper right screenshot, von Bock has moved 1 hex east of Nikolayev but the 5th Mtn. Division is still in supply by going through Nikolayev to reach von Bock.

The screenshot in the middle of the figure shows Rommel as a tertiary supply source tracing to Graziani (who is in an adjacent hex). Graziani then traces through Benghazi to the Eastern Med and from there to Greece and ultimately to a primary supply city in Italy (Graziani’s supply path is not shown). Note that as a tertiary supply source Rommel is able to provide supply to 3 other German units in North Africa. The Commonwealth units are out of supply (yellow status indicators in the upper right of the unit counter) because they do not have a convoy or transport in the Eastern Med.

The fourth screenshot, at the bottom of the figure, shows Balbo as a tertiary supply source in Iraq, tracing to Graziani in Syria. Graziani is a secondary supply source and his supply path back to Genoa is shown above the screenshot on the right. Guderian is also a tertiary supply source - he traces to Balbo.

Appended at the end of this report is an overview of the MWIF process for determining supply, with some of the variables involved.

Player Interface
Nothing new.

Internet - NetPlay
I went through half of the 28 Naval Combat subphases revising them to support NetPlay (I still need to do the other half). This entails making sure that the players controlling the major powers that need to make decisions are given the opportunity to make those decisions, and that the other players are informed about which major powers need to decide. As decisions are made everyone is kept informed, and once all necessary decisions have been made, the program advances to the next subphase. What is especially tricky about this is making sure the opportunity to spend surprise points is offered to the player who has surprise points to spend - those decisions intrude on the normal sequence of play in several places.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new: both the Players Manual and Rules as Coded are in the hands of the Matrix Games graphics person, who is doing the final layouts for how those will appear as PDFs and in print.

Tutorials and Training Videos
I still have one bug to fix for the tutorial on Production (so production can be performed for multiple countries within the tutorial). Otherwise the tutorials are done.

I need to re-record the 6th and create the last three Training Videos: 10th, 11th, and 12th. The 6th (main form and drop down menus) needs redoing because I have seriously modified some forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics.

Historical Video, Music, and Sound Effects
I now have all the files I need as WAV files. What’s needed is for me to insert calls into the sequence of play to activate these glitz elements.

Marketing
Nothing new.


// ****************************************************************************
// For determining supply, the following sequence of tasks is performed:
//
// Primary Supply Sources.
//
// 1 - Identify fixed primary supply sources for each major power and all minor
// countries that are at war. Primary supply sources are cities in the home
// country. The country cannot be conquered and the city has to have been
// controlled for the entire turn. All Commonwealth member nations are
// equivalent in providing primary supply sources for the Commonwealth.
// 2 - Add to the list of fixed primary supply sources identified in #1, the
// primary supply sources from major powers with which a country cooperates.
// 3 - Identify mobile primary supply sources for each major power and all minor
// countries at war. These are either: (1) an HQ on which a Supply Point
// has been expended this turn, or (2) an HQ which has been used to provide
// Emergency Supply this impulse. An HQ providing Emergeny Supply has slots
// which identify the units being so supplied. The number of slots equals
// the HQ's reorganization number (maximum of 5). For an HQ to serve as a
// primary supply source for a country, the HQ has to cooperate with the
// given country.
//
// Secondary Supply Sources.
//
// 4 - Identify fixed secondary supply sources for each major power and minor
// country. For a major power these are either:
// (1) the capital of a controlled/aligned minor country or
// (2) the capital of a conquered country (major or minor).
// For a minor country, only cities in (2) are secondary supply sources.
// Since both (1) and (2) are cities, the city has to have been controlled
// for the entire turn.
// 5 - Identify mobile secondary supply sources for each major power and all
// minor countries that are at war. These are simply HQs that are on land.
// For an HQ to serve as a secondary supply source for a country, the HQ has
// to cooperate with the given country.
//
// Railway Paths from Secondary Supply Sources to Primary Supply Sources.
//
// A - These paths are Railway Paths regardless of whether a rail link is used
// or not.
// B - The shortest path is taken, without using an overseas link if possible.
// This permits the use of the single overseas link to be preserved for use
// by another link.
//
// 6 - Find the shortest path from each fixed secondary supply source to a fixed
// primary supply source. For a primary to supply a secondary, the owner of
// the primary has to be the major power that aligned or conquered the
// secondary.
// 7 - Find the shortest path from each fixed secondary supply source still out
// of supply to a mobile primary supply source. For a primary to supply a
// secondary, the owner of the primary has to be the major power that
// aligned or conquered the secondary.
// 8 - Find a path from each mobile secondary supply source to the closest fixed
// primary supply source. For a primary to supply a secondary, the owner of
// the primary has to be a major power with which the secondary cooperates.
// 9 - Find a path from each mobile secondary supply source still out of supply
// to the closest mobile primary supply source. For a primary to supply a
// secondary, the owner of the primary has to be a major power with which
// the secondary cooperates.
//
// Basic Paths from Tertiary Supply Sources to Secondary or other Tertiary
// Supply Sources.
//
// C - A tertiary supply source is a secondary that cannot establish a Railway
// Path to a primary supply source.
//
// 10 - If there is no secondary supply source for a major power, then there are
// no tertiary sources either. For all tertiary supply sources that are out
// of supply, find a Basic Path to a secondary or tertiary that is in
// supply. Repeat this until all tertiary supply sources are in supply or
// until the previous pass through this routine caused no new additions to
// the list of in-supply tertiary supply sources.
//
// Basic Paths from units to Primary, Secondary, or Tertiary Supply Sources
//
// 11 - Find the shortest path for all non-HQ units on land to a primary,
// secondary or tertiary supply source. To be a valid supply source for a
// unit, the source must be controlled by a country with which the unit
// cooperates. Some units do not need supply: Forts, Partisans, Synthetic
// Oil Plants, Supply Units, and Oil and Build Points. If a path can not
// be found of any length, the unit is isolated. If a path exists but is
// too long, the unit is out of supply.
// ****************************************************************************

The following variables are for each major power and each minor country that has units on the map.

// ****************************************************************************
// Variables for supply links, connections, and paths. Since these are primary
// sources, they are always valid supply sources.
//
// Entries in any Coop list only provide supply for SubC.
// For minor countries these are the supply sources directly controlled by their
// controlling major power. For instance, German primary supply sources, HQs,
// and the capitals of conquered countries can provide supply any minor country
// aligned to Germany. Note that many supply sources that are available to
// Germany are not available to Germany's aligned minor countries. For
// instance, the capitals of aligned minor countries do not provide supply to
// other aligned minor countries. Similarly, secondary suply sources for
// cooperative major powers do not provide supply to any of the minor countries
// aligned to Germany.
//
// For major powers Coop entries can include supply sources from cooperative
// major powers and from aligned minors. Although in the latter case only HQs
// and capital cities provide supply, and then it is secondary supply.
// ****************************************************************************
PriSupCities: TSupplySourcesList;
PriSupHomeCities: TSupplySourcesList; // For conquered territorials.
PriSupHQsTurn: TSupplySourcesList;
PriSupHQsImpulse: TSupplySourcesList;
PriSupAlignHQsTurn: TSupplySourcesList;
PriSupAlignHQsImpulse: TSupplySourcesList;
PriSupCoopCities: TSupplySourcesList;
PriSupCoopHQsTurn: TSupplySourcesList;
PriSupCoopHQsImpulse: TSupplySourcesList;
// ****************************************************************************
// The secondary sources with All at the end are all possible secondary sources.
// ****************************************************************************
SecSupCitiesAll: TSupplySourcesList;
SecSupHQsAll: TSupplySourcesList;
SecSupCitiesAlignAll: TSupplySourcesList;
SecSupHQsAlignAll: TSupplySourcesList;
SecSupCitiesCoopAll: TSupplySourcesList;
SecSupHQsCoopAll: TSupplySourcesList;
// ****************************************************************************
// These secondary and tertiary variables have valid supply connections back to
// a primary supply source. Both secondary and tertiary are subsets of the
// secondary supply sources listed immediately above. The difference between a
// secondary and a tertiary supply source is that only the former can trace a
// rail path to a primary supply source.
// ****************************************************************************
SecSupCities: TSupplySourcesList; // Active lists are subsets.
SecSupHQs: TSupplySourcesList;
SecSupCitiesAlign: TSupplySourcesList;
SecSupHQsAlign: TSupplySourcesList;
SecSupCitiesCoop: TSupplySourcesList;
SecSupHQsCoop: TSupplySourcesList;

TerSupCities: TSupplySourcesList;
TerSupHQs: TSupplySourcesList;
TerSupCitiesAlign: TSupplySourcesList;
TerSupHQsAlign: TSupplySourcesList;
TerSupCitiesCoop: TSupplySourcesList;
TerSupHQsCoop: TSupplySourcesList;

OOSUnits: TUnitStack;

[Shannon V. OKeets]

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

Accomplishments of September 2012

Project Management
My body is getting in the way of me working on the game - arrgh.

I missed 6 days working on the game traveling to Philly for an annual followup on my eye surgery to treat my melanoma. Then I lost another 5 days due to headaches caused by muscle pain in my neck and shoulder. Pretty much a lost month as far as the beta testers are concerned.

My health, in short:
• My kidneys are fine, with a September sonogram showing no sign of new kidney stones.
• My heart is fine; but the healing from the bypass surgery on my breastbone aggravated a 25 year old injury (broken clavicle) which caused the neck and shoulder pain. I have 3 sessions scheduled this month with a physical therapist which hopefully will abate that discomfort and provide me with exercises to avoid having it reoccur.
• The melanoma in my left eye is dormant and has less than a 5% chance of reoccurring. But a cataract completely blurs my vision in that eye. Wills Eye Hospital in Philly gave their go-ahead to get the cataract removed, so I have that scheduled here (in Honolulu) for October 24th.

Hardware and Software
Matrix/Slitherine Games programmers made more revisions to the code at the NetPlay server end. I haven’t tested those changes yet.

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

Beta Testing
I did not upload a new version for the beta testers in September. That is a first since beta testers began working on MWIF in early 2006. I should be able to do much better this month.

Saved Games
Nothing new.

Map, Units, and Scenarios
I received some more naval unit writeups from Warspite.

Optional Rules
Nothing new.

Game Engine
I spent all of my working time this month on supply. In pondering possibilities I discovered several unusual situations:
• An HQ could be out of supply, yet still act as a secondary supply source. The obvious example here is Gort supplying Egyptian territorial units by tracing a path to an Egyptian city.
• A secondary supply source might use multiple paths to reach primary supply sources. For instance, if von Leeb were cut off from primary supply sources in Germany, he might be able to reach cities in Rumania, Bulgaria, and Hungary. In that situation, he could serve as a secondary supply source for Rumanian, Bulgarian, and Hungarian units, but he would need to use 3 different supply paths.
• Besides supplying minor country units, a secondary supply source might use multiple paths to supply major power units too. Here the example is Clark in southwestern France tracing paths to a French city and a British city. Clark, although unable to trace a path to the US, could supply US, French, and Commonwealth units, but would need to use two separate supply paths for the units belonging to the cooperating major powers. Assuming that the Axis had control of Cape St. Vincent, US naval units in Malta could trace to Clark and from there to a French city. But Commonwealth naval units in Malta would be out of supply since the supply path would have to go overseas twice.
• A tertiary supply source might also need multiple paths. For example, if von Leeb is cut off from primary supply sources in Germany, he might be able to reach Antonescu and Mannerheim, both of which could reach a city in Germany. In this circumstance, von Leeb would be in supply and capable of supplying all German, Rumanian, and Finnish units. But he would not be able to supply Italian or Hungarian units. Note that to supply the Rumanian and Finnish units, von Leeb would need to use different supply paths.
• Another odd instance is where German units could trace to Bucharest (secondary: capital of aligned minor country) and from there to Trieste (primary: city belonging to cooperating major power), even though Italian units could not use Bucharest and Rumanian units could not use Trieste.

To accommodate all the above, I had to add some variables to store multiple paths for secondary supply sources. I also renamed some variables to make their purpose easier to understand.

Besides straightening out multiple paths, I worked on eliminating supply path searches. That is the only big problem remaining with supply: reducing the time required to calculate all supply paths from scratch. What I have done is consolidate all the searches for railway supply paths from a secondary-to-primary to just one search for each secondary supply source. The search starts by looking for an overland path to a primary supply source for the major power (M) which controls the secondary supply source. If that succeeds, then no more searches are necessary, since the secondary can then be used to supply all of M’s units, as well as units belonging to major powers that cooperate with M (if they cooperate with the secondary), and units belonging to minor countries aligned with M (if they can make use of the secondary).

But if that search fails, then a quick review is made of all the hexes that were just examined, looking for primary supply sources belonging to cooperating major powers and aligned minor countries. If any are found, then those paths are stored. This followup to failed searches eliminates the need to search later for possible uses for the secondary supply source. In fact, minor countries do not need to perform any searches for secondary-to-primary paths, since any secondary that they might use was already been checked when the search was performed for its controlling major power.

Lastly, failed searches also initiate a further review of all the hexes that were just examined, looking for ports. Ports might be used for extending the search overseas. There are other routines that perform the overseas searches and combine the three links (overland, overseas, and overland) into a single path. Exactly the same as for the overland routes, overseas routes might require storing multiple paths. But the key point here is that for each secondary supply source, only one search is conducted trying to find a railway path to a primary.

Still left to do is:
• read through the code for determining tertiary supply for major powers and seeing if that code can simultaneously make the same determination for minor countries (this is what I did for secondary supply as described above),
• write a routine to determine if a supply path, that was previously valid, is still valid; this will drastically reduce the time required to recalculate supply,
• check and evaluate when supply is calculated/recalculated during game play (the beta testers have reported instances when it hasn’t been recalculated when it should have),
• check if the time required to calculate supply the first time (i.e., from scratch) is now acceptable.

Player Interface
Nothing new.

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new: both the Players Manual and Rules as Coded are in the hands of the Matrix Games graphics person, who is doing the final layouts for how those will appear as PDFs and in print.

Tutorials and Training Videos
I still have one bug to fix for the tutorial on Production (so production can be performed for multiple countries within the tutorial). Otherwise the tutorials are done.

I need to re-record the 6th and create the last three Training Videos: 10th, 11th, and 12th. The 6th (main form and drop down menus) needs redoing because I have seriously modified some forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics.

Historical Video, Music, and Sound Effects
I now have all the files I need as WAV files. What’s needed is for me to insert calls into the sequence of play to activate these glitz elements.

Marketing
Nothing new.

[Shannon V. OKeets]

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

Accomplishments of November 2012

Project Management
The first half of November was more or less lost to having my gall bladder removed and recovering from same. Throw in the follow-up to the cataract removal I had on October 31st (7 eye drops /day) and I didn’t get much done during the first half of November.

But I now have new glasses which make my good eye 20/20 and my poor eye 20/40, which is not too shabby. Reading and working on the computer (yesterday and today) with the new glasses is much easier. My only health event in the next 2 months (of which I am aware) is probably removing a retinal membrane in my left eye. That will be done by a retinal specialist whom I will see in mid-December. A retinal membrane is roughly equivalent to scar tissue (due to surgery or some other trauma to the eye) and the process for removing it is to peel it off. Still, it’s yet another operation - ugh. Doing so should improve my left eye’s vision a bit more, which would be very nice.

After my heart surgery I had a 6 inch vertical scar over my breastbone and three 1 inch horizontal scars in my chest from their other incisions. From the surgery to remove my gall bladder I got a 1 inch vertical scar near my belly button and 3 more horizontal scars in my abdomen. Looking at my torso one might think I am a survivor of a South L. A. drive-by shooting involving gangs and automatic weapons. I’m investigating getting a tattoo “ER Bloods” and wearing gangland colors of scrubs green and latex white.

Hardware and Software
Matrix/Slitherine Games programmers made more revisions to the code at the NetPlay server end. I haven’t tested those changes yet.

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

Beta Testing
The first thing I did once I was able to work on the game again, was to go back over all the emails I had received since June 8th, before my heart attack. I then went through all the bug reports the beta testers had posted for versions 09.08.03, 09.08.04, 09.08.05, and 09.08.06, which covered roughly the same period. My goal was to make sure my master task list was accurate and up-to-date, and to assign an MTL number to all the email missives and posted bug reports. There was some redundancy and other confusion that had to straightened out - as always with tasks like this. But by the 24th of November I had a good handle on all the new items that had been reported in the previous 5 months. I am now able to link posted bug reports to saved game files and MadExcept bug report files (i.e., data dumps) which makes figuring out what went wrong and how to fix it vastly simpler.

I started working my way through my master task list in the order of the sequence of play, which is my normal approach. I fixed 5 Setup bugs, 4 DOW bugs, and I’m working on the 5 new bugs related to air missions. The newly reported bugs fall into 2 categories: mostly cosmetic and obscure. The mostly cosmetic are where the program performs a function correctly but fails to immediately update the map and/or forms. Simply refreshing the map or form ‘solves’ the problem. But sometimes the player could generate a Mad Except error (i.e., fatal crash) when trying to manipulate one of the false visual artifacts. Under obscure bugs I place the rail gun unit being unable to retreat when no rail line exists to an otherwise valid retreat hex. A second example is when a player wants to fly a bomber with a range of 5 and extended range of 10 to a target 4 hexes away, but wants to use extended range so in the return to base subphase the bomber has a range of 10.

In November I released new versions 9.09.00 (12 fixes), 9.09.01 (9 fixes), and 9.09.02 (7 fixes) to the beta testers. That’s only 3 new versions and 28 fixes. I’ll try to pick up the pace in December.

Saved Games
Nothing new.

Map, Units, and Scenarios
I received some more naval unit writeups from Warspite.

Optional Rules
Nothing new.

Game Engine
I haven’t finished with supply yet. Still left to do are:
1. write a routine to determine if a supply path, that was previously valid, is still valid; this will drastically reduce the time required to recalculate supply,
2. check and evaluate when supply is calculated/recalculated during game play (the beta testers have reported instances when it hasn’t been recalculated when it should have),
3. reduce the time required to calculate supply the first time (i.e., from scratch) to something acceptable.

Player Interface
Nothing new.

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new: both the Players Manual and Rules as Coded are in the hands of the Matrix Games graphics person, who is doing the final layouts for how those will appear as PDFs and in print.

Tutorials and Training Videos
I still have one bug to fix for the tutorial on Production (so production can be performed for multiple countries within the tutorial). Otherwise the tutorials are done.

I need to re-record the 6th and create the last three Training Videos: 10th, 11th, and 12th. The 6th (main form and drop down menus) needs redoing because I have seriously modified some forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics.

Historical Video, Music, and Sound Effects
I now have all the files I need as WAV files. What’s needed is for me to insert calls into the sequence of play to activate these glitz elements.

Marketing
Nothing new.

[Shannon V. OKeets]

I am heading back to Philly for 4 days for a funeral. Since I am going to be out of touch during that period, I hope everyone hereabouts can be polite until I return.[;)]

[Shannon V. OKeets]

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

Where the Game Stands at This Point in Time
I have a new analogy for creating MWIF: it’s like building a transcontinental railroad. Each phase of the game corresponds to a section of track stretching from one station to another. There are 60 phases in the sequence of play and the more complex phases have subphases. There are also sub-subphases for air-to-air combat and 7 digressions that occur at various times. Altogether, there are 150+ distinct track segments that the program traverses during game play. The players can be thought of as the engineers that drive the train, with the start/end of each phase being a station.

This railroad is operational for the most part. Trains can proceed from coast to coast, with all track segments completed. However, there are unacceptable bumps (i.e., bugs) along the way, and even an occasional derailment (i.e., program crashes, as reported by the beta testers). But once these mostly minor flaws are ironed out, we will make the whole system available for commercial traffic. Although we also want to complete work on a parallel line so two players can run separate trains side by side (i.e., NetPlay).

Health
While 2011 was a rough year for my health, 2012 was worse. In 2011 I had surgery on my left eye for a melanoma, but that was topped by my heart attack and triple bypass in 2012. Likewise the lithotripsy to remove a kidney stone in 2011 wasn’t as bad a having my gall bladder removed in 2012 due to its complete blockage by numerous gall stones. To finish out the year 2012, my brother died in December. I think there’s the makings of a country western song in there somewhere. My wife says that we are going to try real, real hard to do better in 2013: “No more hospital visits!”

Actually I’m doing pretty well at the moment. I took a 75 minute walk to the beach last week with no more effort than going to the kitchen for a glass of water. I plan on going to the driving range this week; it will be the first time in 4 years that I have held a golf club in my hand. If I can make weekly visits to the driving range for a couple of months, in March I should be able to play a round of golf without embarrassing myself too badly. However, I do have a minor (outpatient) surgery scheduled on my left eye January 10th, to remove a retinal membrane (that’s more or less scar tissue). Right now my vision in that eye is 20/40. After the surgery it should improve slightly.

Accomplishments of December 2012

Hardware and Software
Matrix/Slitherine Games programmers made revisions to the code to the NetPlay server months ago, and I’ll test that this coming 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).

Beta Testing
In December I released 5 new versions to the beta testers: 9.09.03 (13 fixes), 9.09.04 (10 fixes), 9.09.05 (7 fixes), 9.09.06 (11 fixes), and 10.00.00 (27 fixes) to the beta testers. My change in numbering to 10.00.00 was to mark the start of the new year. That’s 5 new versions and 68 fixes, which is much better than what I managed to do in November (3 and 28 respectively). In fact, I got more done in the last 10 days of the month than in the first 21. Partially that was due to me losing 4 days in the middle of the month on a trip to Cape May, New Jersey for my brother’s funeral. I’m still way below my average before my health problems, which was 116 fixes per month.

Nowadays bug reports from the beta testers fall into 3 broad categories: not bugs (20%), CWIF bugs (40%), and bugs which are wholly my own fault (40%). “Not bugs” are often due to a misunderstanding of the rules by the beta testers, or they think they saw something that was wrong, but it wasn’t. Reporting these is all fine by me. The beta testers are suppose to be suspicious and report anything that appears out of the ordinary. Usually other beta testers straighten out these misunderstandings without me having to get involved. All of this is as it should be. But some of these can be very annoying: yesterday I spent half the day trying to figure out why an armor HQ could not advance after combat through 2 clear hexes, in fine weather, when getting a breakthrough result. Burrowing deep into the search algorithm code for land movement, I ultimately determined that the code was working correctly; the optional rule that increases the cost of the first hex entered by an HQ by one was ON - arrgh.

The CWIF bugs are being found because the beta testers are beating on the program very hard. For instance, Michael found that the code for retreating the rail gun wasn’t checking for there being a rail hexside between the two hexes. Rob reported that sending an air unit on a mission using extended range, when reaching the target hex didn’t require extended range, denied the air unit the opportunity to return to base at double its range (which was the whole point of using extended range to reach a nearby target). Some of the CWIF bugs aren’t the fault of the CWIF programmer; they are just changes to the rules that have occurred in the past 8 years. For instance, Lars found that disorganized naval units at sea were having to trace a supply path to an oil point, instead of using ANY oil point for reorganization. This was a rule clarification/modification published in the WIF 2008 Annual.

My mistakes are typically because I did not slice the conditional clauses as fine as required by the rules, or got the processing sequence wrong. Commonly, changes I have made either didn’t completely solve the reported problem or precipitated a new problem somewhere else. For instance, when I added code giving auxiliary cruisers an advantage in avoiding detection, my new check for the moving stack being composed exclusively of auxiliary cruisers interfered with the check for the presence of convoys (which make a group of naval units easier to detect). While these bugs are irritating, I’m not too bothered by them since it doesn’t take me long to find and fix them (since I had been looking at the relevant code only a week or so previously). This patching of patches takes much less time than the alternative: being excessively diligent in checking for all possible inadvertent consequences of a code change. I make a reasonable attempt to think of what might be affected by each change I make, but there is simply too much code to spend time reviewing even a fraction of it for each change. And the main reason I work on all the bugs reported for a game phase as a group is because it only requires me to review the block of code for a phase once to fix multiple bugs.

Below is a summary of all items in my Master Task List (MTL). This summary is up-to-date for all bugs reported through December 31st, 2012. The total count is 155, down from 200+ at the start of the month, which didn’t count a dozen bugs or more reported for the versions 09.09.00/01/02. This jibes with the 68 fixes reported for December.

You might notice that the counts for some phases seem wrong. For instance: Setup Phases [0]: 1062R, 1456R, 1643. That’s because the colors I use to identify bugs I have seriously tried to reproduce, but couldn’t, aren’t visible in this copy. I do not include Cannot Reproduce bugs in my counts. I also use braces {} when there are multiple MTL items for what I perceive as being a single bug. At the end of this report is the complete list of current bugs, with all my notes about same.

Oh, and for those who are interested, the next bug reported with be assigned the number 1728. I started by numbering the first bug 100. There were a couple of times when I renumbered all the bugs, starting again with 100, when the next number would have been 1000 (I wanted to avoid having to type in 4 digits). But the third time that happened I let the numbers continue on past 999. My rough estimate is that over 3000 bugs made it to my task list at one time or another. This doesn’t count an even greater number of bugs I fixed as soon as they were reported (not going to the trouble of placing them on my task list only to immediately remove them).

NetPlay [13] 1510, 1589, 1594, 1604, 1606, 1609, 1610, 1616, 1617, 1618, 1619, 1620, 1638

Sequence of Play [98]
Supply [7]: 191S, 192S, 1070S, 1073S, 1036, 1081, 1707
Setup Phases [0]: 1062R, 1456R, 1643
DOW [0]: 1684
Air Missions [6]: 826S, 1434S, 1564, 1611, 1722, 1726
Naval Movement [1]: 1661, 1673, 1688, 1653, 1665
Naval Combat [8]: 1356, 1531, 1566, 1599, 1693, 1700, 1701, 1724
Land Movement [1]: 276S
Emergency HQ Supply [1]: 1561
Entry Markers [1]: 915
US Entry [2]: 1172S, 1171S
Production Planning [25]: 1341, 832, 556, 612S, 1107, 569, {847, 871S, 961, 1347}, 326, 781, 1400, {1413S, 905}, 1572, 1582, 1598, 1614, 1615, 1641, 1644, 1645, 1671, 1679, 1703, 1709, 1710, 1719
Stay at Sea/Return to Base [1]: 1057
Breakdown of Units [2]: 344, 345
Search Seizure [1]: 409S
Reform Units [3]: 1246S, 362, 1078
Conquest, Surrender, Peace [6]: 1269S, 1021, 1053, 1087S, 1464, 1608
Vichy [22]: 1320S, 1313S, 1002S, 1003S, 1004, 1005, 1006, 1007, 1009, 1010, 1011, 1012, 1013, 1014, {1015, 1065S}, 1016, 1407, 1408, 1656, 1676, 1682, 1692
Liberation [11]: 1353, 1311S, 1308S, 1275S, 891, 383, 1401, 1629, 1630, 1631, 1636

Non-sequence of Play [44]
Detailed Map [14]: 1188, 1120, 880, 142, 769, 493, 138, 139, 140, 1440, 1498, 1501, {1560, 156}, 1721
Units in Hex form [4]: 1462, 1590, 1672, 1698
Main Form [4]: 741, 146, 145, 169
Other Interface Elements [3]: 1167, 1147, 361
Screen Layouts [3]: {1175, 1491}, 1490,, 1689
Game Save/Restore [7]: 867, 695, 517, 110, 118, 1479, 1605
Theme Engine [2]: {1050, 568}, {1513, 1467, 966, 1455, 1573, 1655}
Fast Start [2]: 1261, 1562
Half Map Scenarios [4]: 1259, 1260, {1207, 563}, 1208
Interactive Tutorials [1]: 1493

Saved Games
Done, except for 7 bugs. I focused on this area one day last week and cut the number of remaining bugs in half.

Map, Units, and Scenarios
I received some more naval unit writeups from Warspite.

Optional Rules
Nothing new.

Game Engine
I haven’t finished with supply yet. Still left to do are:
1. write a routine to determine if a supply path, that was previously valid, is still valid; this will drastically reduce the time required to recalculate supply,
2. check and evaluate when supply is calculated/recalculated during game play (the beta testers have reported instances when it hasn’t been recalculated when it should have),
3. reduce the time required to calculate supply the first time (i.e., from scratch) to something acceptable.

The other big problem areas are Production Planning, Vichy, and Liberation. The last has over 10 bugs and the other two have over 20.

Player Interface
Done except for a scattering of 28 bugs. I haven’t taken a serious look at any of these bugs in 2012. Many of them are from 2011 or earlier, which means that some have probably been fixed along the way. Note that all the 150+ forms the program uses have been finalized.

Internet - NetPlay
The technical aspects of NetPlay are all functional: logging into the Matrix/Slitherine Games computer, registering a player’s individual copy of the game, posting a request for an opponent, and agreeing to play a game with someone. Indeed, starting a new game, restarting a saved game, and joining a game in progress are also done and bug-free.

Right now there are 13 bugs on my task list concerning NetPlay. These are preventing the beta testers from doing additional testing of NetPlay. Starting next week, I plan on spending my afternoons working on NetPlay. If you have been able to read between the lines, you might have figured out that NetPlay bugs are quite separate from the sequence of play bugs. They are not so much about getting the program to execute according to the rules, as they are about making sure the right player(s) is(are) making decisions. The other half of the NetPlay bugs deal with keeping all players’ computers up-to-date and their screens continually refreshed.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual and Rules as Coded (RAC)
Done except for the final layouts (by Matrix/Slitherine Games) for how those will appear as PDFs and in print. When I get close to fixing all the remaining bugs, Matrix Games/Slitherine will put the finishing touches on these and print them.

Tutorials and Training Videos
The Tutorials are done except for one bug in the interactive tutorial on Production.

The training videos are roughly 2/3rds done. I need to re-record the 6th and create the last three: 10th, 11th, and 12th. The 6th (main form and drop down menus) needs redoing because I have seriously modified some forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics (e.g., declarations of war, neutrality pacts, and aligning minors).

Historical Video, Music, and Sound Effects
I now have all the files I need as WAV files. What’s needed is for me to insert calls into the sequence of play to activate these glitz elements.

Web Site
Andy has been hard at work on the World in Flames website. Over the past month or so, beta testers have had at it and haven’t reported any difficulties with its operation. He has given it quite a few capabilities and is working on a Ladder where players can challenge each other and record the outcomes of their games. The idea here is that there will be a ‘ranking’ of MWIF players.

Marketing
Nothing new.



Here is my current Master Task List with all the gory details. The colors aren’t visible in this copy; I use them to identify bugs I have seriously tried to reproduce, but couldn’t,. I do not include Cannot Reproduce bugs in my counts. I also use braces {} when there are multiple MTL items for what I perceive as being a single bug.

1638 NetPlay 09.08.02 Rob W. Confirmations August 18, 2012
In Barbarossa, Germany can DOW Hungary and then align it later in the same impulse.
1617 NetPlay 09.08.02 Rob W. Email July 21, 2012
Restarting NetPlay almost immediately can cause a Mad Except, possibly because one of the computers is slower.
1618 NetPlay 09.08.02 Rob W, Email July 21, 2012
Undoing a ground strike generated a Mad Except. The non-phasing side proceeded to Ground Strike Results.
1619 NetPlay 09.08.02 Rob W. Email July 21, 2012
Setting up partisans during the end of turn phase caused a Mad Except.
1620 NetPlay 09.08.02 Rob W. Email July 21, 2012
Overrunning a Polish naval unit calls New Country where a Mad Except occurs.
1616 NetPlay 09.08.03 Rob W. Email July 20, 2012
During Land Combat Declaration, the message about being able to use the engineer’s benefit also appears on the non-phasing player’s computer. It should only appear on the computer of the player declaring the attack.
1609 NetPlay 09.08.02 Rob W. 167-09-08-02 Post #10 July 19, 2012
When assigning losses during Land Combat Resolution, the other side can acknowledge the results before the losses are assigned. This causes the sequence of play to become confused.
1610 NetPlay 09.08.02 Rob W. 168-09-08-02 Post #11 July 19, 2012
Undoing a ground support mission by the phasing side causes the game to hang.
1606 NetPlay 09.08.02 Rob W. 166-09-08-02 Post #4 July 19, 2012
Action choice made by phasing side with the message not acknowledged by the non-phasing side results in the phasing side able to continue to the next phase without receiving the acknowledgment. When the non-phasing side does acknowledge the message, the sequence of play is confused.
1604 NetPlay 09.08.02 Rob W. 165-09-08-02 Post #1 July 15, 2012
Rail activity limits do not update correctly. In particular, they are shown as * at times, which is impossible. Double counting also appears to occur.
1594 NetPlay 09.08.03 SJH June 16, 2012
There are several calls to Check Surprise. The one from Air-to-air combat should only be shown to the player who won the surprise. Likewise for the anti-aircraft fire results and the Port Attack Air Attack subphase. All of them have to worry about Avoid Combat being chosen. Once the decision on spending surprise points has been made, then the game needs to return to the correct place in the sequence of play. If the Naval Combat Results form is about to be shown, then a call to RLID_NCRe needs to be made.
1589 NetPlay 09.07.07 Rob W. #161 Post #4 June 11, 2012
The message list for the Chat form does not scroll to the bottom automatically when the form is reopened. It works ok with Rolling the form up/down.
1510 NetPlay 09.06.07 Post #40 Rob W. #136 May 8, 2012
Autosave does not match entry numbers in Decline and Fall after setting up Germany and the USSR. In both cases one of the players had fewer (by 4 and by 2).
May 8, 2012 - This is the problem I noticed today where the last entry number can be ‘restarted’ incorrectly.
June 2, 2012 - I made a change that should have a major effect on preventing these from occurring. However, I think this might still come up when both players are making decisions in a phase (e.g., production).
--------------------
1707 Supply 09.09.02 Jimm Post #1 December 25, 2012
Japanese militias are being supplied by Italy from Turin.
1081 Supply Aircraft-9/03/05 Post #4 Rob W. #80 January 18, 2012
Several supply problems, notably tertiary supply. There is a saved game from Aaron for testing tertiary supply as well as one from Rob.
May 2, 2012 - Revise the code for finding overland and overseas supply for tertiary sources [currently tertiary supply sources are not calculated]. Three saved games available: CVPSupply and SupplySCS do not find Rommel as a tertiary supply source; TertiarySupply does not find Guderian and Balbao as Tertiary supply sources.
August 24, 2012 - Added code for finding Tertiary supply by land and sea for major powers.
August 27, 2012 - Tertiary supply for majors partially works. It needs to differentiate between paths that include aligned minor and/or cooperating major powers and those that do not.
August 27, 2012 - There is a bug with units in coastal hexes not being able to find overseas supply.
September 2, 2012 - Fixed a couple of bugs with determining supply for units in coastal hexes.
191 Supply 05.03.04 Post #27 Nils October 25, 2010
Many reports thru 9.00.03. Supply not updated correctly - HQ moves, in land combat phase, units incorrectly out of supply or incorrectly in supply. A saved game with instructions available.
Supply 09.02.05 Post #1 Jimm090205-1 December 3, 2011
French convoys do not provide supply to Commonwealth units in Gibraltar. Save available from Jimm was requested but none received (a.k.a. MTL 1017).
December 9, 2012 - CWIF overseas supply does not work: Michael 9.00.00, Posts #1, #2, #3, #4; Lars, 9.00.00, Post #8; Peter v. 9.00.00, Post #13.
1070 Supply SJH January 2, 2012
1 Identify all the sea areas that the major power’s list of ports are adjacent to. Augment that list with the sea areas that can be reached by HQs providing primary supply for the turn. If all the sea areas have a BPH of 1, then no From Port searches need to be performed. This might reduce the elapsed time down from the current 35 seconds.
2 Identify OOS units that are isolated.
1036 Supply 09.02.05 Post #53 Lars December 15, 2011
Supply length should be infinite for notional units.
192 Supply 04.02.05 Post #12 Nils July 1, 2010
Rewrite Supply: Takes too long - when Limited Overseas Supply is off. Madexcept when open Trace Supply Routes form (also reported in 05.01.05 by Grotius post #33).
1073 Supply 9.03.01 Post #6 Grotius January 10, 2012
Tracing supply for a specific unit can not be done easily. The player should be able to select a unit and see its supply path. And then click on another unit to see its supply path. Saved game available.
----------------------
1643 Setup 09.08.06 Peter v. Post #19 August 7, 2012
Mad Except error when starting Global War in Head-2-Head mode. Bugreport is in 09.08.05.
November 24, 2012 - Could not reproduce.
1456 Setup 09.05.01 Post #4 Orm March 14, 2012
When playing without pilots, the available air units can be reduced incorrectly. After picking 4 of 8, placing land units on the map, and then returning to placing the air units on the map, only 3 of the 4 are available.
March 15, 2012 - Could to reproduce.
1062 Setup 09.03.00 Post #35 Doktor December 27, 2011
Converting a convoy that has been placed on the map to the Queens results in no apparent changes. Later the Queens shows up as a Commonwealth reserve unit.
January 6, 2012 - Could not reproduce.
--------------------
1684 DOW - Reserves 09.08.06 Michael Post #91 November 18, 2012
The USSR is given the opportunity to set up its reserves when an Axis major power declares war on China.
November 30, 2012 - Could not reproduce.
December 30, 2012 - Saved game available, but I could still not reproduce this bug.
-------------------
1726 Port Attack 09.09.06 Michael Post #9 December 31, 2012
The game freezes after the Port Attack phase, in which nothing was done, and closing the game generates a Mad Except error. Saved game available.
1722 Air Rebase 09.09.06 Michael Post #4 December 31, 2012
US air unit rebasing from a naval transport into a Commonwealth port shows the message “out of range from the sea area” when it should say “no cooperation with units in the hex”.
1611 Air Transport 09.08.02 Michael Post #12 July 19, 2012
Undoing an air transport move still results in the subphase for unloading land units to occur, although there are no land units to unload.
July 22, 2012 - I could not reproduce this problem. However, I did find (and fixed) a bug when an ATR flew to a cargo and picked it up. When undoing that move, the cargo was incorrectly placed in the hex where the ATR started the phase.
July 24, 2012 - New problem: when an ATR moves to a hex to pick up cargo, the next phase is to unload cargo, but there is no cargo to be unloaded and the game cannot be advanced.
August 16, 2012 - Fixed the problem with unloading cargo. However, the enemy is not given the opportunity to fly intercepting fighters to the ATRs’ return to base hexes, which is the only way they can initiate air-to-air combat. Saved game available.
826 Air Missions 8.02.05 Post#42 RobW May 17,2011
Return to base – is not possible at times. The player needs to be able to destroy units that can not RTB.
Comments: What needs to be done is to write a new routine that checks all the possible RTB hexes to see if any viable RTB hex exists. This would be executed in two places: RTB digression for any reason and normal RTB from any air mission. I need to see if it is also necessary for the Stay-at-Sea/Return-to-Base phases. Saved game available.
1564 Air Rebase 09.07.05 Orm BA090705-02Barb Post #31 May 29, 2012
Air units unable to rebase outside of Finland display the error message “Out of Range” when it should be FTC limitations for minor country units.
August 14, 2012 - One possible solution is to maintain a separate list of hexes that are within range but invalid destinations for FTC (for major powers and minor countries).
1434 Air Missions Aircraft Post #38 Rob W. 101-09-04–00 March 5, 2012
CAP flown to a target hex does not get to choose whether to fight against the Day or Night air missions. Saved game available.
August 9, 2012 - The solution to this is to detect the mix of day/night missions during the defender interception subphase. If all the attackers are day, then there is no problem. If they are all night, then the CAP fighters should be set to fly as night fighters. If there is a mix, then the defender should be prompted to set his CAP fighters as day or night (include the CAP fighters in the Selectable Units form). Once the defender ends the subphase, all should be well; but check that the day/night settings for the fighters are used in the air-to-air combat.
----------------------
1665 Naval Movement 09.08.06 Lars Post #30 November 18, 2012
After entering a port and picking up a division, a heavy cruiser appears to get a fresh range and movement allowance. Saved Game exists.
December 14, 2012 - There are several problems. Moving from Liverpool to the Bay of Biscay (Germans do not attempt to intercept) and then into Plymouth, let’s the heavy cruiser (6 MP, 6 range) pick up a division, but then the cruiser is not allowed to move back into the Bay of Biscay. Furthermore, when it moves into the North Sea it then has zero movement points remaining; it should have 2 MP and 3 range. Lastly, should it move into the North Sea and the Germans not attempt to intercept, the Commonwealth player is asked whether he wants to continue moving, and answering Yes results in the Moving Stack not being able to be placed anywhere.
1653 Naval Movement 09.08.06 Michael Post #9 November 18, 2012
There is no single command that lets a player undo a stack of naval moves.
1688 Naval Movement 09.08.06 Eric Post #106 November 18, 2012
An attempted interception of naval units that fails, with the units being placed in the 4 section box, results in them being placed in the zero section box instead (this was not noticed until the Naval Combat phase).
December 14, 2012 - Could not reproduce.
1673 Naval Movement 09.08.06 Lars Post #38 November 18, 2012
Commonwealth naval units in the 2 section box find German naval units on a die roll of 2, during Blizzard weather. Saved game available.
December 11, 2012 - Could not reproduce.
1661 Naval Movement 09.08.06 Peter v. Post #20 November 18, 2012
Mad Except error when trying to merge convoys.
December 11, 2012 - Could not reproduce. My attempts included using the Units in Hex form, Flyouts, and the Naval Review Details form. I made changes to this code recently because of other reported Mad Except error, perhaps I fixed the problem then.
------------------------------
1724 Overrun Digression 09.09.06 Michael Post #6 December 31, 2012
An overrun French naval unit is destroyed in an interception combat where Commonwealth units participated in the naval combat. When the Commonwealth chooses to not keep on fighting, there is no return to base digression, which leaves the Commonwealth naval units at sea with an Aborting status.
1531 Naval Combat 09.07.04 Nils U496 Post #4 May 19, 2012
When a naval unit aborting from a naval interception combat can be successfully intercepted, Windows abruptly shuts down MWIF. Saved game available.
August 10, 2012 - Recreated following Nils’ instructions. There is a pause before Windows states that MWIF has stopped working. That is probably due to an infinite loop using up available memory (or some such).
December 25, 2012 - Problem still occurs when following Nils’ instructions.
1700 Naval Combat 09.09.01 Michael Post #1 December 15, 2012
Germany is asked to commit submarines, even though they have none in the combat. Italy is not asked, although they do have submarines in the combat.
1701 Naval Combat 09.09.01 Michael Post #2 December 15, 2012
Aborted naval units moving through a sea area with enemy units are found and destroyed, but next the intercepting units are suppose to be attacked and the results to them resolved. At that point, the Naval Combat Results form does not show any intercepting units and the game hangs.
1599 Naval Combat 09.08.01 Nils U517 Post #8 June 16, 2012
Naval Combat A generates a message about an air unit arriving “next turn as a reinforcement for” the US, after a failed naval combat search.
August 14, 2012 - Try to duplicate this problem.
1566 Naval Combat 09.07.05 Bo Email May 30, 2012
German naval units are permitted to return to base in a French port after aborting from a naval interception combat.
August 14, 2012 - Try to duplicate this problem.
1693 Naval Combat 09.08.06 Michael Post #116 November 18, 2012
Naval Combat Results form has no filters. This presents a problem when there are numerous naval units (e.g., 90+) available to take losses.
December 10, 2012 - The necessary components have been added to the form, but there is no code behind them to perform the sort (in lieu of a filter). The difficulty will be making sure the correct unit is identified when the player selects a target, given that the unit list is sorted.
1356 Naval Combat 9.02.04 Lars Post #29 October 31, 2011
MWIF runs sluggishly during a large naval combat, taking a long time to execute die rolls and results. Saved game requested 11/1/2011.
----------------------
276 Land Movement 8.04.04 Aaron Post #22 March 11, 2006
Add code to permit temporary overstacking while moving units. Use the variables OverstackedHexExists, OverstackedHex, and OverstackedHexUnits to record when a hex is temporarily overstacked. Require players to resolve these hexes before making any other moves. Saved files available.
----------------------
1561 Emergency HQ Supply 09.07.05 Nils U367 Post #25 May 29, 2012
The player should be able to activate emergency HQ supply whenever he is the deciding major power and he has an HQ out of supply. Nils also wants another subphase in the land combat resolution phase for the non-phasing player to be able to declare emergency HQ supply if doing so can help OOS units in the combat.
---------------------
915 Entry Marker 8.04.03 Aaron Post #22 July 8, 2011
Transferring markers – from one pact to another doesn't work correctly. When the player clicks on pact, upper or lower, the selected pact in the other location should be reset. This item is not pressing, due to the fact that there is only one Scenario currently allowing 2 pacts – Lebensraum.
---------------------
1171 US Entry 8.04.04 RobW Posts #6, #8, #9 July 13, 2011
Discussion about Option 20 where land based air is not given the opportunity to intercept/react. Rob says he needs to do more testing of this to see if Option 20 correctly evaluates possible locations, based on Options 11, 29, 38 & 50. After checking, Naval Air Interception is still not allowed, even if the sea area in question is a legal sea area (based on other Options). Saved Game available (RobW012).
1172 US Entry 8.04.05 RobW Post #11 July 18, 2011
Option 32. Problem with Japan initiating combat with USSR. Will be coded as: “Once this US Entry Option has been chosen, Axis major powers at war with any major power receiving resources/build points from the US, as part of a current trade agreement, may attack any and all US convoys.” Saved file from original reporting; was partially fixed. Saved Game available (RobW015).
December 24, 2012 - Could not reproduce. The US non-oil resource point is now convoyed to the Red Sea and then overland from Suez to Vladivostok! That avoids going through the sea areas where Japan could intercept.
December 26, 2012 - Change the placement of the convoys so the route has to go through sea areas where the Japanese can intercept.
--------------------
1719 Production Planning 09.09.05 Peter v. Post #4 December 29, 2012
Mad Except error when trying to send Philippine resource to Japan.
1644 Production Planning 09.08.05 Lars Post #1 November 18, 2012
When playing with Advanced Optional Rules, but with Oil Rules OFF, default settings for the convoys are ignored and the program sets the routes to non-optimal. Peter v. reports a similar problem with the Final phase ignoring the Preliminary settings, apparently because of Trade Agreements (Post #43). There was a Mad Except error too. See also 09.09.02, Peter v., Post #9: The automation of routing resources is very frustrating. It’s possible that the problem primarily relates to the trade resources coming from Venezuela and elsewhere in South America,
1614 Production Planning 09.08.03 Lars Post #1 July 19, 2012
Changing routes works ok now but the changes are always Overrides, setting them as Defaults isn’t possible. See also 09.07.06, Nils U513, Post #32, June 5, 2012: It isn’t possible to designate both a default destination and a route for a convoyed resource. They can be done separately, but then the route is an Override. The saved games from MTL 1582 can be used.
1709 Production Planning 09.09.02 Peter v. Post #10 December 25, 2012
The Iraqi oil is not shown as a French resource.
1710 Production Planning 09.09.02 Peter v. Post #11 December 25, 2012
The USSR is able to saved the oil points it sent to Germany to fulfill the trade agreement - for future use by the USSR. See also 09.09.01, Lars, Post #5: One of the USSR oil points sent to Germany was saved in Irkutsk and could not be routed to Germany.
1679 Production Planning 09.08.06 Eric Post #83 November 18, 2012
Using Save In Place for a received oil point sent to Germany, causes the oil point’s location to be (0,0).
1703 Production Planning 09.09.01 Lars Post #5 December 15, 2012
Persian oil cannot be railed to Cairo, although this was possible in previous versions.
1641 Production Planning 09.08.04 Lars Post #4 November 18, 2012
After Netherlands was conquered by Germany (aligned to the Commonwealth), Japan is unable to use the 2 oil points from the NEI because it “does not control” the NEI. Same problem reported by Peter v. in version 09.08.06, post #40 and by Eric in post #73. Saved game available from Peter.
1598 Production Planning 09.08.01 Lars Post #3 June 16, 2012
NEI oil for the Commonwealth uses 19 convoys to send the oil to Melbourne.
Saved game available.
1645 Production Planning 09.08.05 Lars Post #2 November 18, 2012
Closed Burma Road still lets the Burma Oil through to Kunming. Saved game available.
1671 Production Planning 09.08.06 Michael Post #34 November 18, 2012
Newly captured red factories are usable. During production the red factories are not ‘repaired’, even though there is an engineer in the hex. Saved game available.
1615 Production Planning 09.08.03 Lars Post #4 July 19, 2012
Saved oil isn’t saved. Instead it is set to Idle.
1572 Production Planning 09.07.06 Lars Post #2 June 5, 2012
At the start of the PP Preliminary phase a MadExcept occurs. Saved game available.
June 6, 2012 - Program fails when trying to add a hex to TraceHexes.
1582 Production Planning 09.07.06 Nils U512 Post #31 June 5, 2012
Resources routed overseas complete their journey to one viable destination (factory) but then continue on to a second destination (factory) with the second journey also going overseas without the use of convoys. The route shows a jump from the 1st factory to the 2nd. Saved games available.
612 Production Planning 8.02.06 Lars Post #26 February 19, 2011
Unable to see all convoys in a route – when convoys from more than 1 major power are used.
Convoys in the Mozambique Channel and Cape Basin – are not accounted for. They are not shown with “Show Unused”, and are not in use (as far as can be seen). Comment: This is, in fact, the Iraqi Oil being shipped to France. Upgraded status from Minor to Major, since this could have a major impact on NetPlay Production Planning.
The CW uses French convoys, leaving none for the French, if CW Production Planning is done first. It does not seem to matter what order is attempted, especially if more than 2 Majors have CP in the same sea area. There needs to be some way to assign priority for Default Routes, beyond using an Override Route each turn, for Non-Trade & Non-Oil RP, so that it works as desired. Should you desire it, I can write up a full report on what I believe the routing priority needs to take into account.
Saved game available: MTL 612 BugReport228-GW
832 Production Planning 8.02.06 Lars Post #51 May 22, 2011
Saving the Palembang oil in place failed and the program used a convoy to achieve the same result.
May 28, 2012 - I need a saved game to reproduce this. Lars said he can reproduce this.
1400 Production Planning 9.04.00 Post #3 Aaron March 2, 2012
5 oil points are being transported by 1 convoy.
May 28, 2012 - Need a saved game.
1341 Production Planning 9.02.02 Aaron Post #56 October 26, 2011
Two reports: With no Convoys in adjacent sea areas, the Commonwealth is still getting overseas RP to UK factories. It seems that changes in convoys in a sea area are not getting recorded in the Production Planning form.
May 28, 2012 - Need a saved game.
1413 Production Planning 9.04.00 Post #52 Lars March 4, 2012
Saved oil beyond the maximum of 4 causes all saved oil in the hex to be lost. There is no warning that the amount of oil is in excess, but sometimes a MadExcept occurs. If a neutral sends an oil point to another major power which saves it, then that oil point counts as the 1 new saved oil point permitted to the neutral. Saved oil is frequently used by the program for production.
Saved game available.
905 Production Planning 8.04.02 Lars Post #67 July 4, 2011
Saving the maximum amount of oil in a hex – causes problems because once the maximum is exceeded, all the oil is removed and a fatal MadExcept pops up when the game is restored because the oil in the hex cannot be found. There should be a warning message about exceeded the oil capacity of a hex. Or some other remedial action taken.
May 28, 2012 - I think I was able to reproduce the lost of all oil points in a hex (Bordeaux) once using Lars’ saved game. But when I tried to fault isolate when that event occurred I was unable to make it happen again. Instead, at the beginning of the Free France Use Oil phase, the number of oil points saved in Bordeaux is reduced from 5 to 4 automatically. Thereafter there is no excess amount in the hex. I tried sending excess oil points to be saved in a hex (Palembang) but the program detects that the hex is full and does not offer the city as a location for saving additional oil.
556 Production Planning 7.02.02 Lars Post #60 January 29, 2011
Saving oil – by a neutral major power doesn't maintain a correct count on what was saved at the start.
1107 Production Planning 8.04.07 Lars Post #9 August 5, 2011
Multiple problems with radio buttons - saved oil from Lars.
Saved oil in the USSR are used in production without the player being able to have them saved.
Saved Oil – is used for production and cannot be returned to save status. The latter restriction might be caused by the major power being neutral and only able to save 1 'new' oil point a turn.
The USSR's original saved oil points – are used in production but cannot be saved – apparently because of the limit on saved oil points by an inactive major power.
At the end of the first turn, Preliminary Production Planning, I was not able to keep the 4 Japanese originally saved oils as saved; the game insisted on having them for production. When I simply bypassed the Prelim Prod Plan and continued until the Final Prod Plan, I found that here I was able to keep those oils as saved. The screen then did not show that 1 of those oils had been used for reorganization; it ought to have said 'used' at one of those oil resources.
569 Production Planning 8.03.06 Lars Post #11 February 6, 2011
The saved Italian oil point shows up in both the German and Italian production planning forms.
847 Production Planning 8.03.01 Aaron Post #26 May 21, 2011
When a trade resource can not be shipped – it should still have a notation that it is part of a trade agreement: TL for lost – and marked as Lost instead of Idle. The Players Manual includes the TL designation.
May 26, 2012 - The problem remains with recording which resources have been lost when they are needed to fulfill a trade agreement and no resource can be routed to the receiving country.
871 Production Planning 8.03.05 Lars Post #19 July 14, 2011
Spanish resource that cannot be shipped – ends up generating 4 Idle resources in Spain being assigned to Germany.
Saved game available: MTL 418 TR Control-MB-(090104).
961 Production Planning 8.04.07 Aaron Post #24 August 6, 2011
Trade agreement – to send BP from the Commonwealth to Free France/Gabon can be created but the program never implements it in any manner. That is, Free France does not get the BP and the Commonwealth does not lose a BP.
1347 Production Planning 9.02.04 Aaron Post #295 October 29, 2011
When a new Trade Agreement is created, no resources are automatically assigned as TS (this is fine) – but no penalty of lost availability is applied if the player does not assign a resource as TS. This may be related to MTL #961.
326 Production Planning 1.01.00 Lars Post #39 June 20, 2009
Multiple reports on Trade agreements/routing:
Free France resource – could not be sent to CW because of an existing Trade Agreement. Changing the selected Trade resource is problematic overall.
Resource to China is not Burma Oil, but the Port of Spain Oil – unable to change the chosen Trade resource.
Sending the Burma Oil to China gets overridden by the AIA and the Port of Spain oil is used.
781 Production Planning 8.01.07 Michael Post #31 May 1, 2011
Special Action – Close Burma Road (option 24) by Japan causes the Commonwealth oil to not go through to China, but BPs do. Since Japan and the Commonwealth are at war, the closure of the Burma Road should have no effect. In a Global War I have been running, I discovered that if the CW is NOT at war with Japan, even after Japan decides to Close Burma Road, I was still able to send oil to China (from Port of Spain), when it should not be possible. This suggests that the code for Option 24 is reversed in how it is implemented. Maybe an easy cut and paste?
-------------------
1057 Return to Base 09.03.00 Post #18 Jimm090300-6 December 27, 2011
Italian sub can not return to base because La Spezia is “not controlled” by Italy.
December 24, 2012 - I need a saved game to understand what happened here. I found another saved game from Jimm related to version 00.09.03.00, with the extension -6-1Abort, but that did not appear to be the one I was looking for.
--------------------
344 Breakdown Units 1.00.09 Zorachus99 Post #30 August 1, 2007
Multiple reports up to 9.00.03
During setup – with the optional rule off, units can be broken down even when there are no divisional units available.
During setup – with the optional rule off, units can be broken down even when there are no divisional units available.
345 Breakdown Units 1.01.03 Lars Post#13 July 7, 2009
During setup – with the optional rule off, units can be broken down even when there are no divisional units available.
---------------------
409 Search & Seizure 6.00.00 Nils Post#27
Coding new phase: Comments: Created a new form and phase for search and seizure but it needs more code. In particular, clicking on the button to execute a search and seizure does nothing presently. Need to add that S&S can happen to any lent resources/BPs, not just for starting Trade Agreements. Decision that if more than one recipient can lose items, the program will choose them first-come first serve and who loses what is not a problem as the program knows when it “chooses” who was getting the item.
--------------------
1078 Reform Units. 09.03.02 Post #2 Michael January 6, 2012
When reforming units, it would be nice to see the pool of available Corps units.
1246 Reform Units 9.01.01 Lars Post#2 September 11, 2011
The Broken Down Pool is not being accessed when a unit can be reformed – only Force Pool units are available. Connected to the bug from MTL-345 (1.18 Breakdown Units). Saved file available.
362 Reform Units
Needs logic to find which optional rule is being used.
-------------------
1608 Conquest 09.08.02 Michael Post #6 July 19, 2012
Taking Chungking does not change which major power controls its warlord. In this case it appears that China is conquered, because the Chungking warlord goes into the Conquered Pool.
December 24, 2012 - The code for assigning which major power controls a Warlord, when control of the Warlord’s home city changes, needs to be part of the Conquest phase (and Surrender, and Liberation).
1464 Conquest 09.05.03 Michael Post #4 March 18, 2012
Control of Gibraltar correctly passes to Spain when Spain is aligned. However, it incorrectly reverts back to Spain when the Commonwealth later enters the hex. Saved game available.
1087 Conquest 9.03.07 Post #13 Jimm 090307-2 January 25, 2012
In Fascist Tide the Dutch East Indies is awarded to Germany when the Netherlands is conquered. It should become neutral. The same is true for Dutch Guyana. Saved game available.
1021 Reconquest 09.02.05 Posts #11 & #12 Jimm090205-2 December 3, 2011
Italy cannot be conquered a second time by just capturing Rome. That should be how it works. Save game available from Jimm. Rule modifications per Paul and Patrice need to be implemented. CWIF contained no code for reconquest so this needs to be written from scratch.
1053 Conquest 09.03.00 Post #12 Michael December 27, 2011
Conquering both Canada and South Africa generates a MadExcept.
1269 Conquest 9.01.08 RobW Post#48 September 18, 2011
Conquest of Vichy – is processed incorrectly. (1) Vichy land units not removed from Vichy home country. (2) Naval units in production, construction & repair pools not rolled for control. (3) Hex control in Vichy did not change. (4) Vichy not offered a new home country. If you surrender Vichy, only the Hex control issue remains. Saved file available.
-------------------
1656 Vichy France Declaration 09.08.06 Michael Post #10 November 18, 2012
Belgian convoys in France are correctly left in France as they are at war with Germany, but after the hex becomes German, they should be forced to rebase. Saved game available.
1002 Vichy Posts #104 & #116 Rob W. #59 09.02.05 12/3/2001
Naval Review Details form can obscure Die Roll form. The solution is to always close the Naval Review Details and Naval Review Summary forms when the Die Roll form is about to be shown. But record if the forms were Showing before the Die Roll form appears, then they should be restored to view when the Die Roll form is closed.
Files: zipped with GAM, bugreport; jpg
1004 Vichy Posts #112 & #113 Rob W. #61 & #62 09.02.05 12/3/2001
Assuming Spain is aligned to Germany and then conquered by France, the declaration of Vichy results in the disposition of Spain depending on the administrative roll for “All other territories and minors”. However, regardless of the die roll, Spain goes to Free France. On lower die rolls it should become aligned to whichever Axis major power the major power installing Vichy chooses. The same thing happens to Libya.
Files: 2 jpg. Also see RobW Summary.txt.
1005 Vichy Post #114 Rob W. #63 09.02.05 12/3/2001
Assuming that Portugal was aligned to France and Vichy declared, if the administrative die roll is low for “All other territories and minors”, the installing Axis major power chooses which Axis major power conquers Portugal (in this case Italy conquers Portugal). That proceeds correctly but the control of individual hexes in Portugal is computed incorrectly. A previous controlled German hex should become Italian controlled. Also, the hexes occupied by Commonwealth units should become controlled by the Commonwealth.
Files: 1 jpg. Also see RobW Summary.txt.
1006 Vichy Post #115 Rob W. #64 09.02.05 12/3/2001
Assuming that Spain was conquered by France and Vichy declared, if the administrative die roll is high for “All other territories and minors”, Spain should to go Free France. That proceeds correctly but hexes controlled by the Commonwealth should become controlled by the Free French.
Files: 1 jpg. Also see RobW Summary.txt.
1010 Vichy Post #129 Rob W. #70 09.02.05 12/3/2001
French New Caledonia Territorial, on-map in New Caledonia, is not processed correctly when Vichy is Declared. It should be processed as part of the administrative group “All Pacific Ocean Minors and Territories”. The Dakar Militia unit is also processed incorrectly; it should have gone into the Free French force pool because it is a militia unit.
Files: 1 jpg
1011 Vichy Post #130 Rob W. #71 09.02.05 12/3/2001
French land and air units located in Allied controlled hexes after Vichy has been declared can not be moved into administrative groups that have gone Vichy (e.g., Syria). The problem here is that the check for the destination country not being neutral has to be by-passed (i.e., add a conditional clause). Locate the error message about Neutral Country and backtrack to the place in the code where it is generated.
Files: 1 jpg
1012 Vichy Posts #131 & #137 Rob W. 09.02.05 12/3/2001
Convoy units at sea are not split into individual units in advance of the Move French Units At Sea subphase of Vichy France creation. The solution here is to enable the player to use the popup Units Menu to split the convoys. That is normally possible but there must be a conditional clause that is preventing that from occurring during Vichy formation.
January 3, 2012 - There appears to be a problem with displaying the Naval Units menu. A similar problem occurs with the Splitting convoys in the Setup tray at times.
1014 Vichy Posts #133 & #138 Rob W. #73 09.02.05 12/3/2001
Allocation of pilots in production by France when Vichy is declared is based solely on the air units in production. It should include those in the Reserve Pool and the major power declaring Vichy France should be able to select to which air units the pilots are assigned. Any excess pilots (more than there are available air units) should be lost. It appears that the pilots available to France are not being processed here but instead are simply being passed along to Free France, which is completely wrong.
Files: 1 jpg.
A similar problem is reported by Lars with both a pilot and an air unit in the air reserve pool arrive as reinforcements for Free France (9.05.06, Post #8).
1016 Vichy Post #147 Rob W. 09.02.05 12/3/2001
PM 7.12.10 state that French Oil Points should go to Vichy, but go to the installing major power instead. This might be ok. It should depend on who controls the hex in which the oil point resides.
1676 Vichy France 09.08.06 Peter v. Post #52 November 18, 2012
When Vichy France is created, partisans in Indo-China should remain on the map, not be removed. This is true for all red partisans whenever their country is Vichied, conquered, surrendered, or liberated.
1682 Vichy France 09.08.06 Eric Post #88 November 18, 2012
Move French Land/Air Axis indicates a hex in Belgium as the closest, but that hex is not a legal destination. It appears that Belgium was aligned to France and when Vichy was declared, it went to Vichy France. Therefore the hex in Belgium appears to be a valid destination, but it isn’t really since the hex is not in Vichy France proper. The 2 conditional clauses that determine valid destinations don't match. One says it is a valid destination (when determining the closest hex) while the second says the unit cannot be moved into the hex (when Eric tries to move the unit). I need to get them to be the identical.
1692 Vichy France 09.08.06 Eric Post #111 November 18, 2012
Iraq oil still goes to Free France even though Syria goes Vichy. Also, Greece reserve unit is removed from the map when Greece, previously aligned to France, goes to Free France; another Greek unit remains on the map.
1003 Vichy Posts #105 & #106 Rob W. #60 09.02.05 12/3/2001
Commonwealth naval and air units in minor countries aligned to France when Vichy is declared and the minor subsequently conquered are correctly overrun, but the overrun can not be performed because the units have no viable hexes to which to rebase.
Files: zipped with GAM, 2 jpg
Also reported by Lars, 9.05.06, Post #4 for occupied France..
1007 Vichy Post #117 Rob W. #65 09.02.05 12/3/2001
Message for Allied major power Destroy French Units when Vichy is declared could be made easier to read.
Files: 1 jpg
1009 Vichy Post #125 Rob W. #68 09.02.05 12/3/2001
Lending build points to Vichy France by the installing major power is only possible after a delay (e.g., restoring a saved game). The way to fix this is to examine the code for what variables are controlling whether the installing major power can/cannot lend to Vichy France. One of the conditions is not being satisfied as soon as Vichy is installed, but becomes satisfied by restoring a saved game. That should be enough information to identify and fix this bug.
Files: 1 jpg
1013 Vichy Posts #132, #139, #140, #141, &#146 Rob W. #51, #72, & #75 09.02.05 12/3/2001
Assuming that the Netherlands, aligned to France, is incompletely conquered and chooses France as its new home country, during Vichy creation Netherlands naval units in Occupied France should be forced to rebase. That does not happen. The program logic should include these units in a forced rebase because they are Allied units in German controlled hexes. Note that if these units were stacked with a Commonwealth land unit, the hex would be controlled by the Commonwealth and the units would not have to rebase. There is an existing bug similar (identical) to this for Belgian naval units (Rob #51). See point #4a and make sure that NEI goes to an Axis major power if the stated conditions occur. The same point occurs in a slightly different form in posts #140 and #141.
Files: 2 jpg (#72 and 75)
1015 Vichy Post #143 Lars 09.02.05 12/3/2001
Iraq oil is going to Free France after Vichy is declared, even though Syria went Vichy.
1065 Vichy 09.03.00 Post #45 Lars December 27, 2011
The Iraqi oil should go to Vichy/Germany instead of Free France. Saved game available for MTL #1065 (Imp8).
May 25, 2012 - This is still a problem.
1407 Vichy 9.04.00 Post #32 Michael March 4, 2012
After collapsing Vichy, all convoys at sea should be split down to 1 convoy each and set to not being in sentry mode.
1408 Vichy 9.04.00 Post #33 Michael March 4, 2012
Liberation of France, followed by the liberation of Vichy France (?) causes a Mad Except.
1320 Vichy 9.02.02 RobW Post#94
Multiple reports for Vichy creation - move French Naval
Naval units of an incompletely conquered French-aligned minor cannot be moved to the designated “closest hex” – and cannot be deleted using Backspace. Fixed - but
The problem here seems to be that FTC rules are not being taken into account when deciding which is the “closest hex” for rebasing. Guadeloupe and Martinique, being French, are valid destinations, but there is nothing indicating this to the player. Comments: The Main Form text is now correct, but the “closest hex” calculation still does not account for the FTC rules.
After moving the Belgian units, the End-of-Phase button remains inactive. Comments: Sort of solved the problem with Belgian units in Brest, but still have outstanding questions about the situation. These are French-controlled, not French-owned, so they do not evacuate with French Naval units. In that case, what do they do?
The Belgian units should be overrun during the Conquest step, per RAC 13.7.1 (incomplete conquest).
Saved file available.
1313 Vichy 9.01.09 RobW Post#72 October 15, 2011
The following reported as problem, but then under discussion with no resolution:
Vichy units outside of Metropolitan Vichy France should be sent to the French Force Pool if the nation they are in is conquered as a result of Vichy being collapsed (by Axis influence). Currently they just become French.
--------------------
1631 Liberation 09.08.03 Michael Post #37 August 12, 2012
When China is liberated, it is at war with all countries. Saved game available.
1308 Liberation 9.01.09 RobW Post#49-53 October 13, 2011
When France is liberated – hexes inside Vichy Metro France that are in Axis ZOC (including Vichy itself) are not converted to French hexes, as they should be. Saved file available.
1401 Liberation 9.04.00 Post #4 Aaron March 2, 2012
Persia is aligned to Japan, conquered by the USSR and liberated by Italy. The Persian Militia is not moved from the conquered pool to the force pool. The cavalry unit moved between the two pools correctly.
1629 Liberation 09.08.03 Michael Post #35 August 12, 2012
Chinese saved oil point ends up in a Chinese hex but stacked with Commonwealth units, which is illegal. What should happen to the oil point? Right now the code says the oil point must be moved, but that isn’t possible and the game hangs. Saved game available.
1636 Liberation 09.08.03 Michael Post #42 August 12, 2012
Reverting Palestine hexes back to the original owner isn’t possible (US is the liberator). Maybe a saved game is available? - Try saved game for MTL 1629.
1630 Liberation 09.08.03 Michael Post #36 August 12, 2012
Japanese controlled Warlords are moved to the Japan force pool when China is liberated. The Warlords should be unaffected by liberation and the cities remain under the control of Japan. Saved game available.
1353 Liberation 9.02.04 Michael Post#18 October 30, 2011
When the USSR is liberated, Guards Banner Armies units get placed in the Force Pools. This may be fixed once the GBA code is in place?
1311 Liberation 9.01.09 RobW Post# 49-53 October 13, 2011
Failure to revert Metro French hexes – does not revoke co-operation between France and the major power that failed to revert the hexes.
1. Free France should become France in the Relations form.
2. Free France becomes a “nation without a capital” if the liberating major power fails to revert territory – Paris remains controlled by the liberating major power.
Saved file available.
1275 Liberation 9.01.04 Michael Post#18 September 22, 2011
China is not asked to revert French Indo-China after conquering it from the Japanese. Comments: Liberation is going to be changed to Liberate/Revert/Neither in those cases. This will require a new form, and additions to the Players Manual. Vichy Minors should be conquered by the Allies – not liberated. Then they can be reverted to Free France or not (without penalty). Saved game available.
891 Liberation 8.04.02 Michael Post#11 June 28, 2011
When the US does not revert control of hexes in the UK to the Commonwealth – there is a MadExcept error.
383 Liberation 3.00.02 Michael Post#10 November 16, 2009
Free French units – in Vichy, when liberated by CW, do not cooperate with CW, and after interception by Italians, the naval units have no port to which to rebase. Comments: See Aaron's report on this 8.02.01 Test08

1721 Detailed Map 09.09.06 Michael Post #3 December 31, 2012
One damaged red factory with 2 undamaged blue factories are shown with the blue factories not producing.
1498 Detailed Map 09.06.07 Rob W. #131 Post #8 May 8, 2012
Rolling the detailed map up/down causes it to change to full screen instead of to the size it had been previously. Saved game available.
1560 Global Map 09.07.05 Nils U287 Post #24 May 29, 2012
Scrolling the bottom of the detailed map causes the small global map to become distorted. The detailed map has to be at the bottom; then using the left/right arrows for scrolling the detailed map distorts the global map.
See also 156, 09.00.06, Nils, Post #4, August 10, 2010: Small sized Global Map misbehaves at high row numbers. See the post for an excellent description of what exactly goes wrong.
1501 Detailed Map 09.06.07 Post #20 Nils U481 May 8, 2012
The detailed map is only partially redrawn after the end-of-phase button is pressed. Each refresh makes the image more confused.
1440 Detailed Map 9.03.07 Rob W. 097 Post #38 March 2, 2012
Unit resolution changes from medium to high when an air unit flies to a target hex for strategic bombing.
1188 Detailed Map 9.00.06 Lars Post #? August 31, 2011
1. When returning ships to base, there remains an image of the ship in the sea seaction box until it is moved off-screen.
2. Air-to-Air Combat & naval overrun digressions often leaves a form artefact on screen.
3. When shifting from one theatre to another, there is often a mix of both map areas on the screen. Also happens with air unit RTB.
4. Restoring a game often shows only a frame, with your desktop image in it, instead of the detailed map.
1120 Detailed Map 9.00.02 Orm Post #11 August 13, 2011
Factories railed to Murmansk – hide the city Icon.
880 Detailed Map 8.03.08 Michael Post #5 June 21, 2011
When one factory is producing, and another isn't – then the graphic of the smokestacks is incorrect.
142 Detailed Map 01.01.03 Patrice Post #1 July 7, 2009
The weather overlay is not always refreshed when the map is scrolled.
769 Detailed Map 8.01.06 Nils Post #5 April 25, 2011
Screen refresh is not always correct. An example is when using 2 detailed maps and bringing up the Spend Surprise Points form.
493 Detailed Map 7.01.06 Nils Post #8 January 13, 2011
When multiple detailed maps are in use – the Flyouts and Popup Unit Menu positions are not necessarily on the detailed map below the cursor. Using two detailed maps – can result in one having the focus even though the mouse is within the other.
138 Detailed Map 5.01.02 Nils Post #47 August 10, 2010
With units in hand – and scrolling quickly, the map is not redrawn correctly. This was much improved by August 31, 2011, but still not quite perfect.
139 Detailed Map 3.00.04 Patrice Post #55 November 28, 2009
The detailed map refreshes needlessly in several places: DOW minors, Neutrality Pact, Choose Action.
140 Detailed Map 3.00.04 Patrice Post #46 November 28, 2009
Refresh of mouse position – not updated when scrolling, in any way, shape, or form.
--------------------
1462 Units in Hex form 09.05.02 Email Rob W. March 15, 2012
It isn’t possible to move selected units in the Units in Hex form.
1698 Units in Hex 09.09.00 Lars Post #9 December 9, 2012
During Setup, advancing to the next major power causes the Units in Hex form to “jump to a step ahead”.
December 9, 2012 - I am not sure what Lars means here. I setup the US in Global War and then the game went to the USSR without any noticeable problem.
1672 Units in Hex form 09.08.06 Lars Post #37 November 18, 2012
This form stops working fairly often during setup and the reinforcement phases of the game. It can only be corrected by exiting and restoring the game. See also 09.08.04, Lars, Post #9, November 18, 2012: MadExcept error occurred during production and also during reinforcements.
December 30, 2012 - Lars’ bug report concerned Mad Except errors occurring when the program was trying to Clear the UnitsInHex form.
1590 Units in Hex form 09.07.08 Lars LM 0978 Post #4 June 11, 2012
The form does not update correctly during Setup. It places units in the wrong hex.
----------------------
741 Main Form 08.01.05 Orm Post #5 April 18, 2011
The map display button settings down/up do not match what is shown on the detailed map.
146 Main Form 01.01.00 Grotius Post #26 - #29 June 21, 2009
After halting units due to naval interception, the map centers on the next available unit, even if this option is set to Off.
145 Main Form 01.00.06 Grotius Post #10 April 30, 2009
This menu item does nothing.
169 Main Form 00.05.08 ? Post #? November 18, 2007
Setup tray changing the resolution does not always update all the units in the setup tray. This is probably true for all UnitStackViewers.
-------------------
1167 Other Interface Elements Rules Questions Aaron Posts #1018 and #1024 August 23, 2011
If Vichy CAP phases are not disabled, Germany and Italy are offered the opportunity to fly CAP – even if they have all CAP phases disabled. Disabling Vichy CAP phases solves this.
1147 Other Interface Elements 09.00.03 Orm Post #74 August 20, 2011
Ground Support and other phases. Unit status indicators are not updated until you click within the list, even though they are updated on the map. This is true, even if selecting the unit from the list.
361 Other Interface Elements 02.01.04 Sagji Post #7 October 9, 2005
Remains on top of other applications if the user Alt-Tabs out of MWiF.
---------------------
1689 Screen Layouts 09.08.06 Andy Post #107 November 18, 2012
When using 3 monitors, the game does not load if the primary monitor is in the middle and the secondary monitor is on the right. A Mad Except error occurs with the left monitor’s left position as -1920. Asked for the Mad Except report.
1490 Screen Layouts 09.06.03 Post #1 Rob W. #119 April 23, 2012
Naval Review Details settings are not taken from the SLY file when the form is closed and then restored. Refreshing the SLY file does restore them correctly. Perhaps the program is using the current NRS settings?
1491 Screen Layouts 09.06.03 Post #2 Rob W. #120 April 23, 2012
The Global Map that is automatically created as part of New Game.SLY for a two monitor system appears to interfere with the display of the scroll bars (Theme Engine’s) and other elements of the Global Map. For instance, the interior details of the map are a mix of zoomed in and zoomed out. Scrolling the map using the mouse wheel will then produce a MadExcept - eventually. The sequence to reproduce this is: good SLY, New Game.SLY, Good SLY. The last is the one that is messed up. Saved game and SLY files available.
1175 Screen Layouts 09.99.04 Post #2 Aaron August 27, 2011
Changing screen layouts at the start of a new game – does strange things to the Global Map scroll bars. See images in post.
----------------------
118 Game Save/Restore 0.12.01 Orm Post #16 February 10, 2009
Directory default - “Global War\Saved Games\Setups” specified but “Global War\Saved Games” used. See bug report 6 (no saved game).
1605 Game Save/Restore 09.08.02 Peter v. Post #2 July 15, 2012
Trying to save a game during the port attack phase generated a Mad Except.
December 25, 2012 - Try to recreate.
December 26, 2012 - The program was trying to refresh unit depictions in the Flyouts’ form UnitStackViewer.
1479 Game Save/Restore 09.05.04 Stian Post #6 April 6, 2012
File extension GAM assigned to an application in Windows causes the saved game files to not be found. This needs to be explained as part of the installing the application text in Section 1 of the PM.
695 Game Save/Restore 8.00.06 Orm Post#56 March 27, 2011
HQ Reorganization phase – can restore a saved game to the non-phasing side for this phase if the phasing side has no HQs capable of reorganizing units. The game was being played Head2Head.
867 Game Save/Restore 8.03.05 Aaron Post #25 June 14, 2011
Saved Oil Point – not found. Save is from Factory Destruction phase. See bug report 143 (no saved game).
517 Game Save/Restore 9.00.03 Grotius Post #6 January 22, 2011
Attempting to load a saved game with a long directory name – generates a MadExcept error. Too many folders sounds like the problem here. Inserting diagnostic messages should help isolate this problem.
110 Game Save/Restore 0.12.10 Grotius Post #33 April 13, 2009
Restore Last Game – has no code behind it.
--------------------
1513 Theme Engine 09.06.07 Emailed Nils & Jennifer May 8, 2012
Minimizing game during Spend Surprise Points subphase of port attack generated a Mad Except error.
1467 Return to Base 09.05.03 Michael Post #12 March 18, 2012
MadExcept messages generated by minimizing/maximizing the game using the Main form.
966 Land Movement 9.00.00 Orm Post#12 August 6, 2011
Minimizing the game – causes a MadExcept error. This was a Head2Head game running Vista in XP compatibility mode. This does not happen every time.
1455 Theme Engine 09.05.01 Post #3 Orm March 14, 2012
Minimizing the application causes a MadExcept. Reproducing this bug is unreliable but it has occurred several times, under both Vista and Win 7.
March 15, 2012 - Unable to reproduce. The bug report says the minimize command came from within the Units Review form.
1573 Theme Engine 09.07.06 Michael Post #5 June 5, 2012
MadExcept on minimizing game.
1655 Minimize Game 09.08.06 Michael Post #5 November 18, 2012
Bugreport file in 00.09.08.03.
1050 Theme Engine 09.03.00 Post #7 Jimm090300-2 December 27, 2011
Using any directory option other than List generates a MadExcept error. Same as MTL 568.
568 Theme Engine 7.02.03 Grotius Post#27 February 3, 2011
Using the Browse button – on the Splash Screen to bring up a list of files and then clicking on changing the layout from List to something else, generates a MadExcept error.
-------------------
1562 Fast Start 09.07.05 Nils U461 Post #26 May 29, 2012
The SLY files for the Fast Start saved games are missing - or at least they are for Barbarossa.
1261 Fast Start Save Game 9.01.03 Aaron Post#5 September 17, 2011
Once the Transfer Pools are coded, Fascist Tide is going to need a new Fast Start saved game.
------------------
1259 Half Map Campaign 9.01.03 Orm Post#1,12,8,16 September 17, 2011
1. Allied units are at the moment not able to enter or leave the Transfer Pool during naval movement.
3. Units in the Transfer Pool are not RTB at the end of the turn.
For Fascist Tide, I am thinking about using the Azanian Sea as a place to display the Transfer Pool and any combats that take place therein. Units would move from Cape Basin and the Red Sea directly into the Transfer Pool/Azanian Sea. By what method? Again, this would be for display purposes. The Azanian Sea would still be an illegal sea area for all game play purposes.
6. If the Netherlands is DOWed, can the CW set up some of the naval units in the Transfer Pool to represent their setup in the NEI? Harry says “Yes”.
7. General consensus is that the Weather in the Transfer Pool should always be Fine.
8a. Suggestion made to include additional units during Japanese raids instead of doubling the combat factors.
8b. Objection to this change, based on “why fix it, if it ain't broke?”
1260 Half Map Campaign 9.01.00 Orm Post#4 September 17, 2011
Aden should be outside the playable area – but isn't.
1207 Half Map Campaign 9.00.07 Orm Post#16 September 4, 2011
Fascist Tide - Special production rules, special US Entry rules, Transfer Pool rules.
563 Production Planning 8.01.03 Doktor Post #19 February 1, 2011
Problems with half-map scenarios:
In Fascist Tide - the Commonwealth are France receive oil and non-oil resources using the Transfer Pool.
In Fascist Tide - the US has only half of it resources and factories available.
1208 Half Map Campaign 9.00.07 Irn Post#16 September 4, 2011
Day of Infamy - Special production rules, special US Entry rules, Transfer Pool rules, special victory conditions.
-------------------
1493 Interactive Tutorials 09.06.04 email Rob W. April 24, 2012
Unable to complete German production in IT #20.

[Shannon V. OKeets]

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

Accomplishments of January 2013

Project Management
My health is fine.

Hardware and Software
I’ve confirmed that the changes Matrix/Slitherine Games programmers made to the NetPlay Server have reduced the time required to login etc. to the Server. 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).

Beta Testing
In January I released 6 new versions to the beta testers: 10.00.01 (3 fixes), 10.00.02 (4 fixes), 10.00.04 (15 fixes), 10.00.05 (20 fixes), 10.00.06 (32 fixes) and 10.01.00 (29 fixes). Because I was messing around with the formatting for saved games, the beta testers never saw version 10.00.03. My change in numbering to 10.01.00 was to mark the start of the new month. That’s 6 new versions and 103 fixes, which is approaching my average (116 fixes per month) before my health problems.

Below is a summary of my Master Task List (MTL) as of February 1st. During this past month I moved 26 items to a separate category (Recommended Improvements - not shown below) that I will work on after the game’s initial release. Those improvements will be provided to purchasers of the game as free patches.

My task list count is 92, down from 155 at the start of the month. Considering that I removed 26 items from the list, that means I am net -37 for the month. The NetPlay count is going to jump around for a while, since current NetPlay bugs are preventing the beta testers from reaching some places in the code (e.g., forming Vichy France). At the moment, what I am more concerned about is eliminating the non-NetPlay bugs, which presently stand at a new low of 78.

NetPlay [14] 1510, 1589, 1594, 1606, 1609, 1610, 1616, 1617, 1618, 1619, 1620, 1638, 1750, 1752

Sequence of Play [57]
Supply [7]: 191S, 192S, 1070S, 1073S, 1036, 1081, 1707
Air Missions [6]: 826S, 1434S, 1611, 1726, 1732, 1738
Naval Movement [2]: 1665, 1756
Naval Combat [6]: 1356, 1531, 1566, 1599, 1701, 1724
Land Movement [1]: 276
Entry Markers [1]: 915
US Entry[1]: 1741
Production Planning [22]: 1341, 832, 556, 612S, 1107, 569, {847, 871S, 961, 1347}, 326, {1744, 1645, 781}, 1400, {1413S, 905}, 1572, 1582, 1598, 1614, 1615, 1641, 1644, 1671, 1679, 1703, 1710
Stay at Sea/Return to Base [1]: 1057
Breakdown of Units [2]: 344, 345
Search Seizure [1]: 409S
Reform Units [3]: 1246S, 362, 1078
Conquest, Surrender, Peace [1]: 1021
Liberation [2]: 891, 1636
Final Reorganization[1]: 1733

Non-sequence of Play [21]
Detailed Map [7]: 1188, 880, 142, 769,140, 1501, 1721
Main Form [2]: 741, 169
Other Interface Elements [2]: 1167, 1462
Screen Layouts [1]: {1175, 1491}
Game Save/Restore [7]: 867, 695, 517, 110, 118, 1479, 1605
Theme Engine [2]: {1050, 568}, {1513, 1467, 966, 1455, 1573, 1655}

Saved Games
Done, except for 7 bugs.

Map, Units, and Scenarios
This just needs the final naval unit writeups from Warspite.

Optional Rules
I fixed a couple of bugs related to Warlords.

Game Engine
I finished fixing all the bugs in forming Vichy France (Rob W. did a ton of work testing my changes - sadly, sometimes they weren’t correct!) and all but 2 of the bugs in Liberation. The latter should be easy to fix, once the beta testers can provide saved games so I can reproduce them. In the same general section of the sequence of play, I cleaned up the code for Conquest so all that’s left there is the unusual case where Italy is reconquered.

This past month I worked to eliminate all the bugs related to US Entry. I’ve got them down to one, for which I need a saved game to reproduce.

I haven’t finished with supply yet. Still left to do are:
1. write a routine to determine if a supply path, that was previously valid, is still valid; this will drastically reduce the time required to recalculate supply,
2. check and evaluate when supply is calculated/recalculated during game play (the beta testers have reported instances when it hasn’t been recalculated when it should have),
3. reduce the time required to calculate supply the first time (i.e., from scratch) to something acceptable.

The other big problem area is Production Planning, which I’ll tackle this coming month.

Player Interface
This is done except for a scattering of 21 bugs. I eliminated some bugs with GameStackViewers that had been causing Mad Except errors (i.e., fatal crashes) for years. There are ~80 GSV components in numerous forms, which display lists of units. For example, the setup tray has 2 GSVs (air units and land/naval units) and so does the Land Combat Resolution form (attacking units and defending units). I also fixed a couple of bugs with Screen Layouts.

Internet - NetPlay
I spent some time on NetPlay this past month and expect to continue to devote half my time to it in the future. Right now there are 14 bugs on my task list concerning NetPlay, some of which are preventing the beta testers from doing additional testing of NetPlay.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual and Rules as Coded (RAC)
Done as far as I’m concerned.

Tutorials and Training Videos
The Tutorials are done. I fixed the last 2 bugs in the Interactive tutorials this month and Rob W. spiffed up some of his text.

The training videos are roughly 2/3rds done. I need to re-record the 6th and create the last three: 10th, 11th, and 12th. The 6th (main form and drop down menus) needs redoing because I have seriously modified some forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics (e.g., declarations of war, neutrality pacts, and aligning minors).

Historical Video, Music, and Sound Effects
I now have all the files I need as WAV files. What’s needed is for me to insert calls into the sequence of play to activate these 3 glitz elements.

Web Site
Nothing new.

Marketing
Nothing new.

[Shannon V. OKeets]

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

Accomplishments of February 2013

Project Management
We are presently looking for a few more beta testers, primarily to give NetPlay a thorough workout. If you are interested and have the time for testing, please post a reply in the forum thread requesting new beta testers.

I was able to make a couple of weekly chorus sessions this past month and substituted as a bass for a half day in one quartet delivering singing valentines. Our first valentine was to a 2 year old girl who was wearing a brand new white dress covered in little hearts - very cute.

Hardware and Software
The open items for Theme Engine remain unchanged: (1) minimizing the game generates a Mad Except error, and (2) so does trying to display detailed listings of file directories (i.e., the dates and stuff) when opening or saving a file.

Beta Testing
In February I released 6 new versions to the beta testers: 10.01.01 (12 fixes), 10.01.02 (22 fixes), 10.01.03 (16 fixes), 10.01.04 (23 fixes), 10.01.05 (24 fixes) and 10.02.00 (11 fixes). My change in numbering to 10.02.00 was to mark the start of the new month and provide a full new version for the new beta testers. That’s 6 new versions and 108 fixes, which, after taking into consideration that February was a short month, is my average (116 fixes/month).

Below is the summary of my Master Task List (MTL) as of March 1st. My task list count is 78, down from 92 at the start of the month. The NetPlay count is still jumping around, since as I fix NetPlay bugs the beta testers reach additional sections of the code to test. Presently I am slightly more concerned about NetPlay than the other bugs, which are at a new low of 62. Any bugs numbered higher than 1760 were reported in February. The bugs with 3 digits are from a time long, long ago.

NetPlay [16] 1510, 1589, 1594, 1616, 1617, 1619, 1620, 1783, 1784, 1785, 1826, 1827, 1828, 1831, 1832, 1833

Sequence of Play [50]
Supply [7]: 191, 192, 1070, 1073, 1036, 1081, 1707
Air Missions [3]: 1611, 1732, 1738
Naval Movement [2]: 1813, 1816
Naval Combat [7]: {874, 1531}, 1566, 1599, 1701, 1724, 1815, 1823
Production Planning [26]: 1341, 832, 556, 612, 1107, 569, {847, 871, 961, 1347}, 326, {1744, 1645, 781}, 1400, {1413, 905}, 1572, 1582, 1598, 1614, 1615, 1641, 1644, 1671, 1679, 1703, 1710, 1825, 1786, 1787, 1788
Search Seizure [1]: 409
Vichy [2]: 1803, 1811
Liberation [1]: 891
Final Reorganization [1]: 1733

Non-sequence of Play [12]
Detailed Map [5]: 1188, 142, 769,140, 1501
Game Save/Restore [5]: 695, 517, 110, 118, 1778
Theme Engine [2]: {1050, 568}, {1513, 1467, 966, 1455, 1573, 1655}

Saved Games
Done, except for 5 bugs.

Map, Units, and Scenarios
This just needs the final naval unit writeups from Warspite.

Optional Rules
I modified the Breakdown and Reform forms and the processing associated with them. This was to support two versions of each depending on whether the optional rule Unlimited Breakdown is On or Off. See the text and screenshots at the end of this report for what the modified entries in the Players Manual looks like for these forms. Unlimited Breakdown was the last of the optional rules I consider crucial for the initial release. Mainly that was because the CWIF code merged that new optional rule with the standard rules for breaking down and reforming corps/army units into divisions. What I had to do was separate the code into two sections, so it supports both the standard rules and the Unlimited Breakdown rules.

Game Engine
The big problem area is Production Planning, for which I only fixed a couple of items last month. The beta testers keep adding bugs to that area, but I suspect many of them have the same root cause (oh - that was a pun). Once I bear down on that phase I should be able to clean it up in a week or so.

I haven’t finished with supply yet. Still left to do are:
1. write a routine to determine if a supply path, that was previously valid, is still valid; this will drastically reduce the time required to recalculate supply,
2. check and evaluate when supply is calculated/recalculated during game play (the beta testers have reported instances when it hasn’t been recalculated when it should have),
3. reduce the time required to calculate supply the first time (i.e., from scratch) to something acceptable.

Player Interface
This is done except for 5 bugs related to maintaining the Detailed Map display in pristine condition.

Internet - NetPlay
I spent a lot of time on NetPlay this past month and expect to continue to devote at least half my time to it in the future. Right now there are 16 bugs on my task list concerning NetPlay, some of which are preventing the beta testers from doing additional testing.

What I now have working are four air missions (strategic bombing, carpet bombing, ground strikes, and ground support), with the other four (port attacks, air transport, paradrop, and air reorganization) needing the loving attention of the beta testers. Today I’m working on fatal bugs in Antiaircraft Combat and Air-to-air Combat. Setup and most of the phases that start a new turn and impulse appear to function correctly, although I do have one bug for when both sides have to set up reserve units.

The technical aspects of playing over the internet seem solid; I haven’t experienced any glitches. One of the beta testers reported that the program generated a Mad Except error (i.e., crashed) when both players left the game unattended for 10+ minutes. I’ll have to look into that.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual and Rules as Coded (RAC)
I sent a half dozen changes for RAC and the Player’s Manual to Matrix Games. These were about the new forms for the Breakdown and Reform phases and text for Reconquest and Reversion. There were two conflicting rules from ADG on the criteria for reconquest: (1) same as conquest, and (2) capturing the country’s capital. MWIF uses the latter.

Reversion applies to when a country is liberated. This is a decision the liberating major power must make about returning hexes to the liberated country. RAW states that reversion can be done on a hex by hex basis, which historically is how the politicians negotiate this stuff - sitting around a table with a map and arguing over where the new boundary lines between countries are going to be. In game terms, that would be a nightmare to code, so I drastically simplified the reversion rule to: (1) either all or none of the hexes in a liberated country are returned to their original owner, and (2) the decision is made once and forever immediately after the country is liberated.

Tutorials and Training Videos
The Tutorials are done.

The training videos are roughly 2/3rds done. I need to re-record the 6th and create the last three: 10th, 11th, and 12th. The 6th (main form and drop down menus) needs redoing because I have seriously modified some forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics (e.g., declarations of war, neutrality pacts, and aligning minors).

Historical Video, Music, and Sound Effects
I now have all the files I need as WAV files. What’s needed is for me to insert calls into the sequence of play to activate these 3 glitz elements.

Web Site
Nothing new.

Marketing
Nothing new.

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

Breakdown Corps/Army

Form Layout

As shown in figure 8.7.2.8.A, the original corps/army unit is displayed at the top, with its accompanying unit data panel. Available divisions of the same type are displayed in the box under First Division Choice, and all available INF and MOT divisions that could be used to break down the corps/army are shown in the box under Second Division Choice.

When using the optional rule Unlimited Breakdown (see section 9.3.8), the divisions are created by the program. That is, the divisions in the force pool are never used. There is only one first division, whose factors depend on the unit type, combat factors, and movement points of the corps/army. In most cases, two divisions are shown as possible second division choices: an infantry and a motorized. The sole exception is for German SS unit, as shown in figure 8.7.2.8.B. When breaking down a German SS corps/army, there are 4 choices for the second division, depending on whether you want the division to be German SS or not.

Using the Form

Select one division from each division list and then click on OK to break down the corps/army. If you change your mind, you can click on Cancel to avoid breaking down the unit. This process is the same whether or not you are using the optional rule Unlimited Breakdown (see section 9.3.8). The primary difference is that when not using the optional rule, you can only break down units into divisions available in your force pool.

Reform Corps/Army

Form Layout

As shown in figures 8.7.2.42.A and 8.7.2.42.B, the divisions to be reformed are on the left. All the possible corps/army units they can be reformed into are shown on the right, with a unit data panel underneath so you can examine the details of each corps/army unit.

The hex shown in this example contains three divisions: a MOT division, an INF division, and an ARM division. In the space between the INF and ARM divisions, you can see which one is being used to reform a corps/army unit. Figure 8.7.2.42.A shows the corps/army units that can be reformed using the INF division, indicated by "Use division above". Figure 8.7.2.42.B shows the corps/army units that can be reformed using the ARM division, with "Use division below" shown.

Note that when playing with the optional rule Unlimited Breakdown, the only divisions that can be used to reform a corps/army are those that were created by breaking down a corps/army. That is, the divisional units that start in the force pool can not be used to reform corps/army units. Instead, they either start the game on the map or can be build individually, like any other unit.

Using the Form

Click on a division on the left to select the one you want to reform into a corp/army unit. You can click on each one in turn to view the pool of units which may be reformed. If only one non-MOT division is in the hex, only one choice is available and is automatically selected.

If you are not using the optional rule Unlimited Breakdown, simply click on OK and the program randomly selects one of the displayed corps/army units. If you are using the optional rule Unlimited Breakdown, you first select a corps/army unit you want to reform and then click on OK. Should you change your mind and decide not to reform a unit, click Cancel at any time to exit the form.

[Shannon V. OKeets]

April 1, 2013 Status Report for Matrix Games’ MWIF Forum

Accomplishments of March 2013

This report is a day late because I had a meeting with our architect yesterday morning and a dental appointment in the afternoon. Together they subtracted 5 hours from my normal workday. The dentist was just replacing a couple of small, decides-old, amalgam fillings with resin fillings (black transformed to white).

With the architect we signed the final contract for her to begin work on the renovations to our kitchen and adjoining guest bathroom. Both are pretty much going to be gutted: new ceramic tile for the floors and shower surround, new tub, toilet, sinks, cabinets (23 by my last count), furring out 17 feet of walls by 4 inches, relocating the range, dishwasher, refrigerator, clothes washer/dryer, and the kitchen sink. Moving things around means rerouting the electric and plumbing lines. We are keeping the same appliances because they were purchased new over the past couple of years. There will be new countertops, including a built in table for breakfast/lunch for two. As part of all this, we are widening several doorways to ADA (Americans with Disabilities) specifications. The work is scheduled to start mid-June (ye gods, city permitting takes a long time) and the project will last 8 weeks! Eight weeks without a kitchen, the refrigerator in the living room, microwave meals on paper plates, the only running water in the master bathroom. It will be just delightful I’m sure. And the cost is 50% more that the price we paid in 1978 for a 4 story town house in Philadelphia. Everybody should by 3 or 4 copies of MWIF so they can give away copies to friends and relatives.[:)]

Hardware and Software
The open items for Theme Engine remain unchanged: (1) minimizing the game generates a Mad Except error, and (2) so does trying to display detailed listings of file directories (i.e., the dates and stuff) when opening or saving a file.

Beta Testing
In March I released 6 new versions to the beta testers: 10.02.02 (27 fixes), 10.02.03 (10 fixes), 10.02.04 (15 fixes), 10.02.05 (10 fixes), 10.02.06 (13 fixes) and 10.02.07 (7 fixes). That’s 6 new versions and 82 fixes, which is well below my average of 116 fixes/month. But on the other hand I did beat both production planning and supply into submission while concurrently making substantial progress on NetPlay.

Below is the summary of my Master Task List (MTL) as of April 1st. My task list count is 70, down from 78 at the start of the month. The NetPlay list is very volatile , since as I fix NetPlay bugs the beta testers reach additional sections of the code to test. Presently I am more concerned about NetPlay than the other bugs, which reached a new low of 54. A dozen of those bugs are “not quite fixed” items I mostly corrected last month. I just need to touch up a few lines of code (where the paint hasn’t dried). Another half dozen have been reported in the last couple of days, so I haven’t really looked at them. I expect there to be ~16 that I can knock off at the rate of 8/day (based on my experience over the past couple months).

NetPlay [14] 1589, 1594, 1619, 1785, 1826, 1827, 1859, 1880, 1881, 1882, 1883, 1884, 1885, 1886

Sequence of Play [42]
Supply [5]: 191, 1070, 1036, 1081, 1707
Setup Phases [1]: 1877
DOW [1]: 1866
Air Missions [1]: 1611
Naval Movement [2]: 1813, 1816
Naval Combat [10]: {874, 1531}, 1566, 1599, 1701, 1724, 1815, 1847, 1868, 1869, 1872
Land Movement [1]: 276, 1878
Land Combat Resolution [1]: 1873
Reorganization [2]: 1855, 1856
Production Planning [10]: 1107, {847, 961, 1347}, 326, 1644, 1671, 1825, 1862, 1863, 1864, 1871
Search Seizure [1]: 409
Reform Units [2]: 1851, 1879
Conquest [1]: 1876
Vichy [2]: 1803, 1811
Liberation [1]: 891
Final Reorganization [1]: 1733

Non-sequence of Play [12]
Detailed Map [5]: 1188, 142, 769,140, 1501
Game Save/Restore [5]: 695, 517, 110, 118, 1778
Theme Engine [2]: {1050, 568}, {1513, 1467, 966, 1455, 1573, 1655}

Saved Games
Done, except for 5 bugs.

Map, Units, and Scenarios
This just needs the final naval unit writeups from Warspite, who sent me writeups for the Polish land units last month.

Optional Rules
Nothing new other than fixing a couple of bugs in last month’s new code for Unlimited Breakdown.

Game Engine
I fixed most of the bugs in Production Planning this month, although the beta testers then identified a bunch of other stuff on that form that could be improved. I had cut the bugs in that phase from 26 down to 5, but they drifted back up to 10 while I was working on supply.

I still have some things to do to finish my new supply routines, but my big worry about elapsed time is gone. I reduced the time to calculate supply from scratch, when the map is full of units scattered all over the world late in the war, down to 8 seconds. It had been 45 seconds. For the small scenarios, calculating supply from scratch happens in the blink of an eye. Since the only time supply has to be calculated for all units from scratch is when a game is restored, players shouldn’t notice the additional 8 second delay when restoring a saved game.

When starting a new game, supply is calculated instantaneously, as each unit is placed on the map. Once supply has been calculated once, it’s only a matter of validating whether the previous determination for all the units’ supply is still good. For most units that status won’t change. Weather and major disruptions in overseas supply can affect a lot of units, but even then a full recalculation for all units on the map won’t be necessary. Still left on my task list are:
1. Write a routine to determine if a supply path that was previously valid is still valid, and
2. Decide precisely when during game play supply needs to be recalculated.

Following this report is one of my ‘dailies’ from working on a supply bug (master task list #1081). There are also four screenshots of the resultant Supply Sources and Paths form, with commentary.

Player Interface
This is done except for 5 bugs related to maintaining the Detailed Map display in pristine condition.

Internet - NetPlay
I continue to spent a lot of time on NetPlay. Right now there are 14 bugs on my task list concerning NetPlay, half of which Rob W. sent me over the past week while I was working on Production Planning and Supply. Some of the 14 bugs are preventing the beta testers from doing additional testing.

Getting the scenarios that begin late in the war to start correctly for NetPlay took several days of my time. Both sides can decide about lend leasing units before anyone places units on the map. That makes Lend Lease the first Setup subphase and it is executed by both sides simultaneously. Whichever side finishes making those decisions first then waits for the other side. Setup also has a Scrap Units subphase for each major power, which gets done before units are randomly selected for the Setup Tray. All of that code now seems to work correctly. But there is at least one bug in the last subphase of Setup, when partisan units are placed on the board behind enemy lines. For instance, the Russians, Chinese, and French get to do that in some of the scenarios where the Axis starts the scenario having already occupied large portions of Allied home countries.

I haven’t gotten Antiaircraft Combat to work. But then I haven’t had time to look at that yet. Air-to-air Combat took up another couple of days of effort and while I made a lot of progress there, it has a ton of possible outcomes with different players making decisions. Each of AX, DX, AC, DC, AA, and DA has its own code mass that needs to run “just so” when there are two computers involved.

The technical aspects of playing over the internet seem solid except for the automatic disconnect (i.e., crash) when both players leave the game unattended for 10 minutes. I’m not sure what to do about that. If I can get the time interval up to 30 minutes before it crashes, I think I’ll ignore the problem. 10 minutes is too short for my taste, but if you walk away from the internet for 30 minutes, you should expect to have the connection dropped.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual and Rules as Coded (RAC)
Some issues arose last month about numbering the sections in RAC, since the Player’s Manual has a massive amount of cross references to RAC. These and other minor details mainly concern the Table of Contents and Index.

Tutorials and Training Videos
The Tutorials are done.

The training videos remain roughly 2/3rds done. I need to re-record the 6th and create the last three: 10th, 11th, and 12th. The 6th (main form and drop down menus) needs redoing because I have seriously modified some forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics (e.g., declarations of war, neutrality pacts, and aligning minors).

Historical Video, Music, and Sound Effects
I have all the files I need as WAV files. What’s needed is for me to insert calls into the sequence of play to activate these 3 glitz elements. I really wanted to get to inserting the sound effects last month, but was unable to find the time. I’ll see if I can get that done in the first half of April.

Web Site
Nothing new.

Marketing
Nothing new.

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

Below is a short history of me trying to fix bugs in the supply routine.

The 4 screenshots show:
Upper Left - Graziani, a secondary supply source, supplying Rommel and other units in the desert. Included in the list of supplied units are those that Rommel himself supplies. Note Graziani’s supply path tracing overseas to Athens and from there via rail to a primary supply source (Trieste) in Italy.
Upper Right - Rommel acting as a tertiary supply source.
Lower Left - Yeremenko out of supply. Yeremenko is under the Russian La-5FN fighter with a range of 3. Because Yeremenko is a hex experiencing Storm weather (shown under the heading Cost in the Path information), his basic supply path is only 2 hexes. It takes him 3 basic path hexes to reach the rail line NW of Kalinin. From there it would cost zero basic path hexes to reach Moscow because he could use rail lines all the way. But he first has to avoid the enemy ZOC exerted by the 5-4 German INF to its NE, so Yeremenko is out of supply. As are all the other units he could otherwise supply, including Timoshenko, who would be a tertiary supply source if Yeremenko were a viable secondary supply source.
Lower Right - MacArthur acting as a supply source for the Free French (note the title above the list of supply sources). MacArthur has two supply paths. One is overseas back to a primary supply source in the US. The other is the one shown, which traces overland to a city in Australia. That is a Mixed supply path since for the Free French it uses both US and Commonwealth supply sources. The two supply sources might both be needed. While the one to the US could supply the units of all countries that cooperate with the US, it uses an overseas path so units themselves would not be able to use it if they trace overseas to MacArthur (only 1 overseas link is permitted in a supply path). The path to an Australia city is overland, so it doesn’t impose that restriction. But because it traces to a Commonwealth primary supply source, it cannot be used by units belonging to minor countries aligned to the US (e.g., Philippines units).

1081 Supply 9.03.05 Post #4 Rob W. #80 January 18, 2012
Several supply problems, notably tertiary supply. There is a saved game from Aaron for testing tertiary supply as well as one from Rob.
May 2, 2012 - Revise the code for finding overland and overseas supply for tertiary sources [currently tertiary supply sources are not calculated]. Three saved games available: CVPSupply and SupplySCS do not find Rommel as a tertiary supply source; TertiarySupply does not find Guderian and Balbao as Tertiary supply sources.
August 24, 2012 - Added code for finding Tertiary supply by land and sea for major powers.
August 27, 2012 - Tertiary supply for majors partially works. It needs to differentiate between paths that include aligned minor and/or cooperating major powers and those that do not.
August 27, 2012 - There is a bug with units in coastal hexes not being able to find overseas supply.
September 2, 2012 - Fixed a couple of bugs with determining supply for units in coastal hexes.
February 10, 2013 - Thomas has another saved game.
March 28, 2013 - In CVPSupply Rommel is not in supply. That appears to be because Graziani is not listed as a secondary supply source for Germany. The 3 units that can trace to Rommel are not listed as in supply or out of supply. The problems with the last is almost certainly because the units are tracing to Rommel but ConnIndex = LastConnIndex, which was producing an infinite loop.
March 28, 2013 - Fixed a bug so secondary supply sources that trace overseas to a primary are added to the list of supply sources for cooperating major powers. In this case, Graziani in North Africa is now a valid supply source for German units. That puts one of the German units in supply, but Rommel (which is adjacent to Graziani) is shown as out of supply. He should be a tertiary supply source. The code reports that he is found to be a tertiary supply source, but he doesn’t show up on the supply report as such.
March 29, 2013 - Fixed the supply problems for Rommel, but now he appears twice in the list of supply sources (sigh). The changes I just made allow for HQs (and cities) to serve as multiple conduits for supply. For instance, it might lead back to a cooperating major power’s primary supply source and be useful for units belonging to both major powers - but not provide supply to units belonging to aligned minors. Or the HQ might trace to a capital of an aligned minor and then by rail to one of its own primary supply sources. In that case it could supply units belonging to itself and the aligned minor, but not those belonging to cooperating major powers. There is yet a third case, where the HQ uses both cooperating major power supply sources and aligned minor supply sources in its path back to a primary supply source. Then the HQ could only supply its own units. The code now searches for all these possibilities and correctly reports multiple supply paths in the Supply Sources and Paths form.
March 29, 2013 - Rommel’s supply is now perfect. There were duplicate entries since Rommel can supply both German and Italian units. I just had to make sure only one was displayed, depending on whether the player is looking at German or Italian supply. There are still German units OOS in a coastal hex of the Black Sea which should be able to trace supply overseas to von Bock who is in supply and also in a coastal hex of the Black Sea. Mao is listed incorrectly OOS as a secondary supply source; as a unit, Mao is in supply. The Japanese HQs in China are OOS when they should be able to trace a rail path to a port and hence overseas to Japan. Curiously, another Japanese HQ in Burma does just that successfully to be in supply, even though he has to go through 3 sea areas.
March 29, 2013 - Fixed the problem with the Japanese HQs. The program now displays 3 routes for Terauchi, who is in China. One goes overseas to Tokyo, one goes to a city in Korea, and one goes to a city in Manchuria. This is all correct. The overland routes to the minor country cities enable units belonging to those minor countries to use Terauchi for supply even if they have to trace overseas to reach him.
March 30, 2013 - The German units are correctly OOS. CWIF showed them as in supply but that’s wrong. HQs in coastal hexes can receive supply from overseas but they cannot send supply overseas. So von Bock cannot send supply over the Black Sea to the German units in a coastal hex. It took me 2 days to figure this out last September and another couple of hours this month to remember that I had previously deduced that the CWIF code for the rule was incorrect. Arrrgh!
March 30, 2013 - In addition to Mao not being listed as a secondary supply source, there are units from Korea, Formosa, and the Netherlands which are incorrectly shown as OOS. All 3 of the minor country units should be able to trace supply overseas to a primary supply source. In the case of the Japanese controlled minor country units, they can also trace overland to a city in Japan. Something is wrong with some minor country units finding supply from their controlling major powers. There is also a 7-4 German INF in Estonia which should be able to trace to the port Parnu and from there overseas to Kiel.
March 30, 2013 - Mao is listed as a secondary supply source for the USSR. The Nationalist Chinese HQs are listed as secondary supply sources for the Communist China.
March 30, 2013 - Fixed the problem with the minor country units aligned to Japan. There was a missing code fragment needed to assign a major power’s primary supply sources as useable by its aligned minor country’s units.
March 31, 2013 - The corrections I made for Rob’s saved game caused new problems in Aaron’s. I took out those changes and now supply is correctly found for the German 7-4 INF. Corrected the bugs in both saved games concerning HQs that can reach the capitals of aligned minors overland as well as a primary supply source overseas. The pointers for the former were interfering with the pointers for the latter.
March 31, 2013 - The Communist Chinese are also showing the Nationalist Chinese cities as primary supply sources. Solved the problem with the Nationalist Chinese cities showing up as Communist Chinese primary supply source. Also fixed the bug with Mao appearing in the USSR secondary supply sources list.
March 31, 2013 - Stilwell does not show up in the list of United States secondary supply sources. Fixed the problem with the Nationalist Chinese HQs showing up as Communist Chinese secondary supply sources.
March 31, 2013 - Added Stilwell to the list of US HQs but he still doesn’t show up as a valid US secondary supply source when he traces supply to a primary Nationalist Chinese supply source (e.g., a Chinese city). Added Stilwell to the list of valid US supply sources when he can trace a rail path to a primary Nationalist Chinese supply source.
March 31, 2013 - Duplicate MacArthur entries are in the list of valid secondary supply sources for the Free France. Fixed; the problem was not in the calculations, but instead in the display of multiple paths.
April 1, 2013 - Fixed the problem with Mao. He was a special case since all other minor country HQs belong to countries that are aligned to a major power. The normal processing of major power secondary sources checks for them having supply. Mao needed his own personal set of code.

[Shannon V. OKeets]

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

Accomplishments of April 2013

Hardware and Software
The open items for Theme Engine remain unchanged: minimizing the game generates a Mad Except error, and so does trying to display detailed listings of file directories (i.e., the dates and stuff) when opening or saving a file. If push comes to shove, I can always substitute in standard Windows code for opening and saving files; that would be uglier, but at least it wouldn’t crash.

Beta Testing
In April I released 3 new versions to the beta testers: 10.03.00 (12 fixes), 10.03.01 (8 fixes), and 10.03.03 (8 fixes). The last of those was on April 14th. I have 20 fixes done for version 10.03.04, which is waiting for me to finish supply. Both the number of new versions and fixes (48) are dramatically below my averages. What can I say, debugging supply takes a lot of my time and effort.

We have a half dozen new beta testers arriving and they are reporting bugs that no one else had encountered (different computer system configurations).

Below is the summary of my Master Task List (MTL) as of May 1st. My task list count is 84, up from 70 at the start of the month. The NetPlay list is volatile , since as I fix NetPlay bugs the beta testers reach additional sections of the code to test. I am still more concerned about NetPlay than the other bugs. The latter jumped up to 72 (from last month’s count of 54), but that is because I have not been fixing them as they are reported. I adamantly refused to look up from my work on supply, so they have accumulated; most of them are minor. Typically, I fix minor bugs when they are reported (which only takes 5 or so minutes for each), hence they never even make it to my task list.

NetPlay [12] 1589, {1594, 1859}, 1785, 1826, 1827, 1911, 1912, 1913, 1914, 1915, 1916, 1921

Sequence of Play [54]
Supply [3]: 191, 1070, 1036
Setup Phases [3]: 1900, 1906, 1908
Reinforcements [1]: 1917
DOW [1]: 1909
Air Missions [3]: 1611, 1890, 1891
Naval Movement [2]: 1813, 1816
Naval Combat [11]: {874, 1531}, 1566, 1599, 1701, 1724, 1815, 1847, 1868, 1869, 1872, 1899
Land Combat Declaration [2]: 1892, 1897
Land Combat Resolution [2]: 1873, 1918
Emergency HQ Supply [1]: 1910
Reorganization [3]: 1855, 1856, 1896
US Entry [1]: 1898
Production Planning [12]: 1107, {847, 961, 1347}, 326, 1644, 1671, 1825, 1862, 1863, 1864, 1871, 1893, 1895
Search Seizure [1]: 409
Reform Units [1]: 1851
Vichy [4]: 1803, 1811, 1903, 1904
Liberation [2]: 891, 1919
Final Reorganization [1]: 1733

Non-sequence of Play [18]
Detailed Map [5]: 1188, 142, 769,140, 1501
Player Interface [3]: 1901, 1920, 1922
Screen Layouts [2]: 1894, 1902
Game Save/Restore [6]: 695, 517, 110, 118, 1778, 1907
Theme Engine [2]: {1050, 568}, {1513, 1467, 966, 1455, 1573, 1655}

Saved Games
Done, except for 6 bugs.

Map, Units, and Scenarios
I am still getting unit writeups from Warspite and Adam Scott (who sent me writeups on a dozen land units last month).

Optional Rules
Nothing new.

Game Engine
The last half of the month I spent on restructuring the data for supply so I could write the code for recalculating supply. Earlier in the month I ironed out the last of the bugs in calculating supply from scratch. There were several weird little instances in the dozen games I have been using for testing the supply code. I’m pretty confident that I now have all the fundamentals working correctly. But I need the recalculations to execute almost instantaneously - for example, whenever a player moves a land unit. To make that happen I changed the data storage for supply paths from dynamic (i.e., ever increasing in number) to static (i.e., a predefined number that never increases). For each secondary supply source there are now 26 possible supply paths. These modifications reduced the number of likely supply paths from over 150,000 to under 13,000. 90% of the latter will never be used, but there is a place in memory to store all that may be needed.

The sad part of this tale is that by making changes to the primitive elements of the supply code I introduced dozens of new bugs. Hence the two weeks I spent debugging it. On the plus side, my understanding of the supply rules and the supply code is pretty awesome at this point - I’m sure that will fade rapidly.

What I am working on today (besides this report) is determining exactly where in the sequence of play supply should be recalculated. I do not want to do it unless it is necessary, since it can take several seconds under some circumstances (e.g., if the weather change worldwide). At the end of this report is my current list of when supply should be recalculated. You’ll notice that I differentiate between overland and overseas supply routes. Sometimes the former need to be redone, sometimes the latter, and sometimes both.

Player Interface
This is done except for 8 bugs related to maintaining the Detailed Map in pristine condition and some new ones found by the new beta testers (who have different computer configurations).

Internet - NetPlay
The first part of the month I spent on NetPlay, getting the bug count for that mode of play down to 5. Of course then Rob was able to test more phases of the game, thereby driving the count back up. At least those were newly discovered bugs. Some of my changes for NetPlay did cause bugs to appear in Head-to-head play during setup. I haven’t looked into those yet.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual and Rules as Coded (RAC)
Getting the final edits done and sending these two documents off to Final Layout has been dragging on for various reasons.

Tutorials and Training Videos
The Tutorials are done.

The training videos remain roughly 2/3rds done. I need to re-record the 6th and create the last three: 10th, 11th, and 12th. The 6th (main form and drop down menus) needs redoing because I have seriously modified some forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics (e.g., declarations of war, neutrality pacts, and aligning minors).

Historical Video, Music, and Sound Effects
I have all the files I need as WAV files. What’s needed is for me to insert calls into the sequence of play to activate these 3 glitz elements. I really wanted to get to inserting the sound effects last month, but was unable to find the time - same story as last month.

Web Site
Nothing new.

Marketing
Nothing new.



Below is my current analysis of where in the sequence of play supply should be recalculated. Each variable is a flag (True/False) that is set to True under the listed circumstances and then tested when the Supply Recalculation routine executes. If it is False, sections of the recalculations can be skipped - since nothing has changed since the last time those calculations were executed.

// SupplyExecutedOnce:
Set to True when supply is calculated from scratch (occurs just once).

// SupplyUpToDate:
Set to True when SupplyOnLandChanged, SupplyAtSeaChanged, or SupplyAtWarChanged is True.
Weather - if the weather changes in any weather zone.

// SupplyUpdateForUnit:
Set to True when an individual unit needs its supply updated (e.g., after it has moved).

// SupplyUpdateForStack:
Set to True when a stack needs its supply updated (e.g., after a naval stack returns to port).

// SupplyOnLandChanged:
Set to True when hex control or ZOCs into enemy hexes change.
Setup at start of game - ZOCs into hexes adjacent to placement hex may change.
Setup aligned minor - ZOCs into hexes adjacent to placement hex may change.
Setup of reserves - ZOCs into hexes adjacent to placement hex may change.
Reinforcements - ZOCs into hexes adjacent to placement hex may change.
Naval movement - ZOCs into hexes adjacent to hex in which a land unit loads/unloads may change.
Carpet bombing - ZOCs into hexes adjacent to target hex may change.
Air transport - ZOCs into hexes adjacent to hex in which a land unit loads/unloads may change.
Unload land unit - ZOCs into hexes adjacent to arrival hex may change.
Invasion - control of landing hex may change.
Paradrop - ZOCs into hexes adjacent to departure hex and/or control of landing hex may change.
Notional - prior to include the notional decision to compute odds ratio.
Land movement - ZOCs into hexes adjacent to starting and/or stopping hex and control of hexes in path may change.
Land combat - ZOCs into hex of destroyed unit and hexes adjacent thereto may change.
Retreat - ZOCs into hexes adjacent to starting and/or stopping hex may change.
Advance after combat - ZOCs into hexes adjacent to starting and/or stopping hex and control of hexes in path may change.
Air rebase - supply of the air unit in the arrival hex undetermined.
Partisans - control of arrival hex may change.
Return to base - ZOCs into hexes adjacent to arrival hex may change; supply of the units in the arrival hex undetermined.
Breakdown - ZOCs into hexes adjacent to unit's hex may change.
Reform - ZOCs into hexes adjacent to unit's hex may change.

// SupplyAtSeaChanged:
Set to True when a major power's ability to use a sea area changes.
Setup at start of game - control of sea area in which a unit is placed may change.
Naval movement - control of sea area in which a unit arrives/departs may change.
Naval combat - control of a sea area in which a unit departs may change.
Return to base - control of a sea area in which a unit departs may change.

// SupplyAtWarChanged:
Set to True when control of large blocks of territory change.
Declaration of war.
Claim of minor country territory.
Alignment of a minor country.
US Entry - control of a minor country territory may change.
Ukraine.
Conquest.
Mutual peace.
Surrender.
Liberation.
Declaration of Vichy France.
Collapse of Vichy France.

[Shannon V. OKeets]

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

Accomplishments of May 2013

Hardware and Software
The open items for Theme Engine remain: minimizing the game generates a Mad Except error, and so does trying to display detailed listings of file directories (i.e., the dates and stuff) when opening or saving a file. There is now a new one (it occurs sporadically when running under Windows XP) having to do with “rolling up a form”; rolling up a form minimizes the form to the size of the form’s top bar.

Beta Testing
In May I released 7 new versions to the beta testers: 10.03.04 (25 fixes - 5 made in May), 10.03.05 (2 fixes), 10.03.06 (9 fixes), 10.03.07 (20 fixes), 10.04.00 (13 fixes), 10.04.01 (12 fixes), and 10.04.02 (10 fixes). The number of new versions is back to my norm. But the fixes (71) are still well below my average (116). Debugging supply takes a lot of time. Another major time destroyer was fixing a couple of overwriting memory bugs.

Overwriting memory is the nastiest bug there is. The program scribbles on its own code causing the code to execute in a bizarre manner. However, it isn’t immediately obvious that the program has done this. Instead, the program runs fine for a while until the problem manifests itself later in the program’s execution, causing code that previously had run perfectly (sometimes for years) to malfunction. So the programmer (me) spends days looking for a bug in the wrong place. Only after absolutely convincing myself that the code where the problem occurs is fine, do I consider the possibility of overwriting memory (OM) having occurred. Proving that OM is the problem takes time and the only real way to locate an OM bug is to do a binary search using what I call canary code. If the canary code fails, then OM has occurred. If the canary code still works, then the OM bug happens later. Typically it takes a lot of dead canaries before the problem can be fault isolated. Mercifully, once the bug is located, the necessary code modification usually requires changing only 1 or 2 lines of code. Prior to the two OM bugs in May, I only had one in the previous 8 years I‘ve been working on MWIF.

Below is the summary of my Master Task List (MTL) as of June 1st. My task list count stands at 80, down from 84 at the start of the month. I am still more concerned about NetPlay than the other bugs. The latter dropped to 63 (from last month’s count of 72). I’m still spending too much time dealing with bugs caused by my rewrite of supply. The only solution is to keep hammering away at them one by one; right now there are 6 of the little suckers left.

None of the other bugs in the sequence of play and non-sequence of play is of much concern to me. For instance, I fixed 10 of them in one day towards the end of May. What happened was that the beta testers had gotten my bug list count over 100, which annoyed me no end. So I spent a couple days knocking off a bunch of easy ones.

NetPlay [17] 1589, {1594, 1859}, 1785, 1826, 1827, 1911, 1912, 1913, 1914, 1915, 1916, 1921, 1932, 1933, 1934, 1935, 1936

Sequence of Play [45]
Supply [6]: 1070, 1947, 1956, 1960, 1966, 1969
Setup Phases [1]: {1900, 1944}
Air Missions [3]: 1611, 1890, 1925
Naval Combat [11]: {874, 1531}, 1566, 1599, 1701, 1724, 1815, 1847, 1868, 1869, 1872, 1899
Reorganization [3]: 1855, 1856, 1896
Production Planning [13]: 1107, {847, 961, 1347}, 326, 1644, 1671, 1825, 1862, 1863, 1864, 1871, 1893, 1895, 1973
Search Seizure [1]: 409
Reform Units [1]: 1851
Vichy [2]: 1803, 1811
Liberation [2]: 891, 1919
Overstacked Digression [1]: 1931
Final Reorganization [1]: 1733

Non-sequence of Play [18]
Detailed Map [5]: 1188, 142, 769,140, 1501
Player Interface [3]: 1901, 1920, 1922
Game Save/Restore [7]: 695, 517, 110, 118, 1778, 1907, 1924
Theme Engine [3]: {1050, 568}, {1513, 1467, 966, 1455, 1573, 1655}, 1928

Saved Games
Done, except for 7 bugs.

Map, Units, and Scenarios
As I get additional unit writeups I add them to the collection.

Optional Rules
Nothing new.

Game Engine
There are ~80 places in the sequence of play where supply is recalculated. At this point I have deleted all the CWIF code concerning supply. For debugging purposes, I installed a temporary message bar to the bottom of the Main form to report the amount of time spent in each of the 23 steps for recalculating supply. In many situations it takes less than 10 milliseconds total. In most it takes less than 100. Even 1000 milliseconds is acceptable when major changes have occurred. For example, when the weather changes for the worst and numerous units are now OOS (out-of-supply).

Simple moves in friendly territory are very fast, since supply only needs to be recalculated for the moving unit. Rail moves, air units returning to base, and most land moves are in this category. Moves into and out of the front line sometimes cause changes in supply because of enemy ZOCs. Moving HQs always has more effects on supply, since the units that the HQ had been supplying now need to find a new source of supply, even if it is just the same HQ in a different hex.

Changing control of a hex, by having a land unit move through enemy territory, or when a minor country joins the war, usually affects just half the units on each side. The side gaining control of new hexes might have previously OOS units now in-supply. The side losing control of hexes might have some of its previously in-supply units OOS. The program logic therefore does not reassess supply for all the units on the map, just those whose supply might have changed. Similar logic applies when units move into and out of sea areas. One side might have previously OOS units now capable of finding supply, while the other side has previously in-supply units now OOS.

From the short discussion on supply above, I think it should be obvious why a lot of code is involved. I have ~20 flags that get set as units move into and out of hexes/sea areas. Then once the units have reached their destination (which may be off-map), I run the 23 step routine to recalculate supply, which executes different steps depending on which flags have been set. The payoff for all this effort is that supply updates quickly and dynamically as units are moved onto, around, and off the map.

Player Interface
This is done except for 5 bugs related to maintaining the beauty of the Detailed Map and 3 found by the new beta testers concerning different monitor configurations.

Internet - NetPlay
I did virtually no work on this in May - very aggravating. I fixed a few tangential items, but none of the serious stuff. It is pointless to work on NetPlay if the game has serious bugs in the sequence of play when running in solitaire mode.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual and Rules as Coded (RAC)
All printed materials are in Final Layout. I’ve seen PDFs of both RAC and the Players Manual, but both of them lack graphics. That’s not too bad for RAC, which only has 20 or so figures. But the Players Manual has 270+ figures, so without them the PDF is really difficult to proof read. The attached graphic is a collage of some of the screenshots in the Players Manual section 7, which describes the sequence of play.

Tutorials and Training Videos
The Tutorials are done. Nothing new on completing the training videos.

Historical Video, Music, and Sound Effects
Nothing new.

Web Site
Nothing new.

Marketing
Nothing new.

[Shannon V. OKeets]

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

Accomplishments of June 2013

Hardware and Software
The open items for Theme Engine remain the same: minimizing the game generates a Mad Except error, trying to display detailed listings of file directories (i.e., the dates and stuff) when opening or saving a file does the same, and “rolling up a form” does too (the last occurs sporadically under Windows XP). Rolling up a form minimizes the form to the size of the form’s top bar.

Beta Testing
In June I released 5 new versions to the beta testers: 10.04.03 (10 fixes), 10.04.04 (14 fixes), 10.04.05 (31 fixes), 10.04.06 (13 fixes), and 10.05.00 (10 fixes). The number of new versions is close to my overall norm. But the fixes (78) are well below my average for last year (116). Something in the 70's appears to be my new average.

Below is the summary of my Master Task List (MTL) as of July 1st. My task list count stands at 93, up from 80 at the start of the month. I remain more concerned about NetPlay than the other bugs.

The latter jumped back up to 84 (from last month’s count of 63) but I am waiting on saved games from the beta testers for a half dozen of the new bugs. Usually, once I get a saved game I can fix the problem in 30 minutes or less. I proved this again to myself by fixing 15 of them in a day and a half last week. I get upset when the count goes over 100 and I knock off a bunch of easy ones to bring the total back down. The easy ones are scattered throughout the sequence of play and occur under very unusual circumstances. Given a saved game for the weird situation, I’m able to fix these without too much effort. As one example from many I could provide: the USSR declaring war on Italy while a neutrality pact with Germany exists, forces a Bulgarian (Bulgaria aligned to Italy) unit in Poland and an Italian unit in Turkey (Turkey aligned to Germany) to both relocate more than 3 hexes from the USSR. That’s a digression that takes place in the middle of implementing all the DOWs by the Allies during the impulse.

The beta testers also provided an influx of bug reports for supply in June. Although I have saved games for virtually all of these, I’ve haven’t given them much of my attention. They mostly have to do with not updating supply when circumstances on the map change. I fixed a half dozen of them. For the remainder, saving and restoring a game lets the beta testers get the supply status for all the units corrected. Therefore, there’s no immediate hurry for me fix the supply bugs. I’ll spend a day sometime this week on them and that should resolve nearly all of them. By the way, many of them are duplicates.

None of the other bugs in the sequence of play and non-sequence of play is of much concern to me.

Graham has been helping me prioritize the order in which I fix bugs. He has also been identifying for which ones I need saved games. There seem to be a lot of high priority items!

NetPlay [9] {1594, 1859}, 1785, 1826, 1827, {1913, 1914}, 1932, 1933, 1935, 1936

Sequence of Play [65]
Supply [14]: 1070, 1956, 1997, 1998, 2025, 2030, 1999, 2004, 2027, 1982, 1988, 2033, 2038, 2041
Setup Phases [1]: 1900
Reinforcements [1]: 2046
DOW [1]: 2021
Air Missions [4]: 1611, 1890, 1925, 1996
Naval Movement [1]: 1990
Naval Combat [11]: {874, 1531}, 1566, 1599, 1701, 1724, 1815, 1847, 1868, 1869, 1872, 1899
Land Combat Declaration [1]: 1995
Reorganization [3]: 1855, 1856, 1896
Use Oil [1]: 2042
Production Planning [15]: 1107, {847, 961, 1347}, 326, 1644, 1671, 1825, 1862, 1863, 1864, 1893, 1895, 1973, 2006, 2014, 2020
Search Seizure [1]: 409
Reform Units [1]: 1851
Vichy [4]: 1803, 1811, 2017, 2028
Surrender [1]: 2009
Liberation [3]: 891, 1919, 1980
Overstacked Digression [1]: 1931
Final Reorganization [1]: 1733

Non-sequence of Play [19]
Detailed Map [6]: 1188, 142, 769,140, 1501, 2036
Player Interface [3]: 1901, 1920, 1922
Interactive Tutorial [1]: 2043
Game Save/Restore [6]: 695, 517, 110, 118, 1778, 1907
Theme Engine [3]: {1050, 568}, {1513, 1467, 966, 1455, 1573, 1655}, 1928

Saved Games
Done, except for 6 bugs.

Map, Units, and Scenarios
As I get additional unit writeups I add them to the collection. Adam sent me a group in June.

Optional Rules
Nothing new.

Game Engine
I’m not doing anything special for the game engine code. I’m just fixing bugs as they are found by the beta testers.

Player Interface
This is done except for 6 bugs related to maintaining the beauty of the Detailed Map and 3 concerning different monitor configurations.

Internet - NetPlay
I spent most of June on NetPlay. Many of my corrections do not show up on my task list as bug fixes. For instance, I’ve been working on Port Attacks since March, slowly making progress through all the subphases. That bug is still listed as one item on my task list, although I have corrected a dozen or more problems with the code so it will support NetPlay. Like many of the NetPlay problems, once I get it running right for NetPlay, the beta testers find new problems with solitaire play and I have to go back and slice the conditional logic a little thinner. I ran into this with the automatic declarations of war just a couple of days ago.

As for Port Attacks, the following subphases seem ok: Combat Air Patrol, Attacker flies bombers with escorts, Defender flies interceptors, Attacker flies interceptors, Inclusion of submarines, Search rolls, Surprise points calculation, Surprise points usage (there are several places in the sequence of play where this is possible), Plotting antiaircraft fire by divisional AA units, Antiaircraft fire resolution, and Port attack on naval units (partially). I’m pretty sure that return to base will work once I get that far since those routines work correctly for other air missions. What I still need to debug is air-to-air combat and naval combat results. I’m ignoring the former for the moment and focusing on getting the two sides to alternate choosing which unit is affected by the destroy/damage/abort results. For port attacks, and naval air combat in general, the attacker chooses the first unit to suffer a result and then the defender decides the second. They alternate thereafter. Surprise points can also be used to change that order. I’ve got the results of the first unit correctly determined, reported to the other player, and displayed on both computers. But when it comes to the second unit, the second player’s combat form is not enabled for him to make his decision. Each one of these subphases takes a lot of patience to get running perfectly.

I’ve gotten through some of the naval movement interception code so it works for NetPlay. However, there are a lot of logic branches depending on what the players decide and the die rolls. Because these are handled as digressions from the normal sequence of play, the logic is quite complex. For instance, naval units can be forced to move during the land movement phase (due to overruns), during the conquest phase, and during aborts from naval combats. The main phases for moving naval units are the naval movement and return to base phases. All of these different phases have their own set of rules as to what is and is not permitted. I’ve got the code functioning well enough now that I can let the beta testers tell me what isn’t working with moving naval units in NetPlay.

I also spent several days working on naval combat. Naval combat has more subphases than any other phase of the game: 28. Yesterday I discovered a bug in choosing the type of naval combat (i.e., naval air, surface, or submarine). When one side declines to make the combat a naval air combat, the other side oftentimes gets to choose naval air. Right now, the second side is not getting that opportunity. The way debugging NetPlay goes, is that I test each of the main logic branches to see if the decision making is given to the right major power (or side) and that the forms and map update on both computers as the program works its way through the sequence of play. This is quite tedious. I have to take detailed notes when debugging NetPlay and do frequent saves on both computers.

Without the notes I can easily forget precisely what happened. Only by knowing what was being displayed on both computers and what actions were taken by each player can I determine where the program was in the code and thereby locate and fix any bugs. The saved games are crucial because it can take a lot of effort to get both computers back to the exact point where a failure occurred. So the cycle is:

1 - encounter a problem,
2 - record what happened and when,
3 - go back to a previously saved game,
4 - get to the point before the problem occurred and save the game,
5 - recreate the problem, this time taking good notes,
6 - read through the code to locate where the bug was generated and put in some diagnostics
7 - restore the saved game before the bug
8 - recreate the bug and interpret the diagnostics
9 - fix the bug
10 - restore the game before the bug
11 - advance the game to make sure the fixes work and the game advances farther in the sequence of play
12 - encounter a new problem ...

For non-NetPlay bugs the cycle is pretty much the same but since only one computer is running, most of the work is cut in half. I also have over 3000 non-NetPlay saved games so I can recreate most normal game situations for all 60 phases and most of the 80+ subphases. But for NetPlay I have less than 100 saved games (they have to be identical on both computers). I’m building up my collection, but it is less than 3% of what I have for non-NetPlay games.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual and Rules as Coded (RAC)
I spent some time working with the woman doing Final Layout for RAC and the Players Manual. She’s making progress on the PM and was up page 168 the last time she sent me a draft for proofreading. I requested that I get the documents piecemeal rather than have them all arrive in one huge mass to be proofread ASAP! I think you’ll like the result. Most likely I’ll post a few sample pages in July, but I won’t do that until she tells me the PDFs are final and on their way to the printer.

Tutorials and Training Videos
The Tutorials are done. There was one bug reported for one of the interactive tutorials; I’m waiting on instructions on how to recreate that since the tests I ran executed without any trouble. Nothing new on completing the training videos.

Historical Video, Music, and Sound Effects
Nothing new.

Web Site
Nothing new.

Marketing
Nothing new.