Matrix Games Forums

To End All Wars: Mountain InfantryPandora: Eclipse of Nashira Announced! Deal of the Week: Command Ops goes half price!New Fronts are opening up for Commander: The Great WarCharacters of World War 1Sign of for the Pike and Shot Beta!More Games are Coming to Steam! Return to the Moon on October 31st! Commander: The Great War iPad Wallpapers Generals of the Great War
Forums  Register  Login  Photo Gallery  Member List  Search  Calendars  FAQ 

My Profile  Inbox  Address Book  My Subscription  My Forums  Log Out

RE: MWIF Monthly Reports

 
View related threads: (in this forum | in all forums)

Logged in as: Guest
Users viewing this topic: none
  Printable Version
All Forums >> [New Releases from Matrix Games] >> World in Flames >> RE: MWIF Monthly Reports Page: <<   < prev  1 [2]
Login
Message << Older Topic   Newer Topic >>
RE: MWIF Monthly Reports - 10/3/2012 11:35:44 PM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
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.


< Message edited by Shannon V. OKeets -- 10/4/2012 2:02:53 AM >


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 31
RE: MWIF Monthly Reports - 12/3/2012 2:48:48 AM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
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.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 32
RE: MWIF Monthly Reports - 12/19/2012 1:05:16 AM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
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.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 33
RE: MWIF Monthly Reports - 1/1/2013 4:03:14 AM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
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, ’ 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.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 34
RE: MWIF Monthly Reports - 2/1/2013 4:40:08 AM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
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.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 35
RE: MWIF Monthly Reports - 3/2/2013 4:27:46 AM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
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.







Attachment (1)

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 36
RE: MWIF Monthly Reports - 4/2/2013 8:35:42 PM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
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.





Attachment (1)

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 37
RE: MWIF Monthly Reports - 5/2/2013 5:07:52 AM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
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.


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 38
RE: MWIF Monthly Reports - 6/2/2013 3:45:47 AM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
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.




Attachment (1)

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 39
RE: MWIF Monthly Reports - 7/2/2013 8:16:59 AM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
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.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 40
RE: MWIF Monthly Reports - 8/2/2013 5:54:39 PM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
August 1, 2013 Status Report for Matrix Games’ MWIF Forum

Overview
Roughly speaking, on January 1st of this year the game was 98% done. Sometime in the spring, it reached 99% (when the code for Supply completed alpha testing and went into beta testing). Since then I’ve been working on the first decimal place, and as I write this I believe the game is 99.9% done. That is, I’m working on the second decimal place. Given that there are ~420,000 lines of code, 0.1% translates as 420 lines of code. That doesn’t convert directly to a specific number of bugs, but the current bug count under 100 seems about right. Now I just need to grind away at the remaining bugs.

As a footnote, this is the 8th anniversary of my monthly status reports on MWIF. By another accounting, I am starting my ~99th month of work on the game.

Accomplishments of July 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 July I released 5 new versions to the beta testers: 10.05.01 (26 fixes), 10.05.03 (11 fixes), 10.05.04 (22 fixes), 10.05.05 (10 fixes), and 11.00.00 (13 fixes). Version 10.05.02 was not given to the beta testers - I used it in alpha testing. The number of new versions and fixes (82) are about my average for this year.

Release 10.05.01 fixed all but 2 of the Naval Combat bugs, which need saved games for me to recreate them. The beta testers then found some more bugs in naval combat, which is par for the course. I’ve now developed a theory for complex phases of the game that when I cut the number of bugs in half, the beta testers bump it back up by half, and the cycle repeats: 32 => 16 =>24 => 12 => 18 => 9 ... The bugs in naval movement, naval combat, Vichy France creation, supply, and production planning were all like that.

Releases 10.05.02 and 10.05.04 fixed all but 3 Supply bugs, which were minor. As above, the beta testers have since found more for me to fix. It wasn’t until the 20th of the month that I managed to devote my time and effort exclusively to fixing NetPlay bugs. The NetPlay bugs remaining aren’t a big concern; half of them are new within the past few days and I’ve done a lot of work on 4 of the older ones (see the NetPlay section below for more details).

Here is a summary of my Master Task List (MTL) as of August 1st. My task list count stands at 95, up from 93 at the start of the month. At one point I had the bug count down to 72 - sigh. Recently I’ve been torn between finishing debugging NetPlay and knocking the bug count in the sequence of play back down below 40. Many of these bugs are recent (high numbers) - which means I haven’t really looked into fixing them.

NetPlay [9] {1594, 1859}, 1785, 1826, 1827, 2056, 2099, 2100, 2101, 2107

Sequence of Play [65]
Supply [11]: 1070, 1982, 1988, 2061, 2064, 2078, 2083, 2086, 2088, 2089, 2106
Setup Phases [1]: 2093
DOW [1]: 2094
Air Missions [8]: 1611, 1890, 1925, 1996, 2052, 2103, 2105, 2082
Naval Movement [1]: 1990
Naval Combat [4]: 1599, 1724, 874, 2104
Land Combat Declaration [1]: 1995
Reorganization [3]: 1855, 1856, 1896
Use Oil [2]: 2042, 2091
Production Planning [16]: 1107, {847, 961, 1347}, 326, 1644, 1671, 1825, 1862, 1863, 1864, 1893, 1895, 1973, 2006, 2014, 2020, 2084
Search Seizure [1]: 409
Conquest [2]: 1047, 2050
Vichy [5]: 1803, 1811, 2017, 2028, 2063
Surrender [2]: 2009, 2073
Liberation [3]: 891, 1919, 1980
Victory [1]: 2090
Overstacked Digression [2]: 1931, 2074
Final Reorganization [1]: 1733

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


Saved Games
Done, except for the bugs listed above.

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

Optional Rules
The optional rule Off-city Reinforcements appears to be bug-free at this point; a couple of months ago I wasn’t sure if it would be ready for the game’s initial release. There are 6 optional rules that are partially coded and which I doubt will be ready for the game’s initial release. But when they are finished, they will be sent to purchasers of the game as patches: City-Based Volunteers, Kamikazes, Naval Supply Units, Guards Banner Armies, Rough Seas, and the uncoded rules for special unit types in Convoys in Flames (i.e., German auxiliary cruisers, sub-hunters, specialized submarine types, tankers).

Game Engine
Other than fixing supply bugs, nothing has really changed regarding the game engine. I have no tasks related to this remaining.

Player Interface
Done, except for the bugs listed above. Like for the game engine, I have no tasks related to this remaining.

Internet - NetPlay
I spent a lot of July on NetPlay. As before, many of my corrections do not show up as bug fixes. In July the classic case of that was the end-of-turn phases. MWIF has 35 phases prior to the end of turn and 28 phases thereafter. This past month I was able to run a NetPlay game through all the end-of-turn phases, although that was with some optional rules turned off (e.g. Use Oil) and some of those phases are not planned for the game’s initial release (e.g., Intelligence, Ukraine). But still, all those phases completed and moved smoothly to the next phase in the sequence of play on both computers. I also debugged the start of new turn phases that are skipped for the first turn: Reinforcements, Lending, and Initiative/Moving First. This required a lot of work, with half the 60+ phases having some small problem that needed to be identified and corrected. On my task list this shows up as one bug ‘fixed’. Testing that code is now in the hands of the beta testers.

Somewhat annoying is that messing around with the code to implement NetPlay occasionally causes bugs to appear in the sequence of play for Solitaire mode, in phases/subphases that have been stable for months, sometimes years. These aren’t difficult to fix, but it feels like a blindside tackle at times.

I still have some combat bugs to fix for NetPlay in air-to-air, naval, and land combat. In all these cases the problems arise when assigning combat losses or other effects. Letting both players choose which units to destroy/damage/abort/shatter and presenting those choices to the decision player is what’s difficult. Sometimes one player chooses (e.g., naval surface combat), sometimes alternating players (e.g., naval air combat), and sometimes both (e.g., land combat where both sides take losses but fewer than they have units engaged in the combat). The combat phases have multiple subphases and the sequence of play loops back for either additional combats and/or additional rounds in the same combat. It’s just very complicated logic to keep both computers synchronized as these subphases are executed and the decision makers switch back and forth. If the code’s not perfect, it’s wrong.

Most of the phases with long subphase sequences have been or are close to being debugged for NetPlay. The only one not tested so far is the creation of Vichy France. Once I get the combat stuff working, I’ll start testing that.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new. But Peter S. is anxious to get back to work on this - as am I.

Player’s Manual and Rules as Coded (RAC)
Work continued in July (by others, with proofreading by me) on completing the final layouts for the Players Manual and Rules as Coded. Those are pretty much done at this point. There are some ad hoc details remaining, concerning artwork and finishing a professional index for the Players Manual. Did you know (I didn’t) that there are people who are professional indexers? Usually they are given a fixed number of pages for the index and develop one to satisfy that requirement. For MWIF I created a list of 400-500 key words for the Indexer to work from.

I still intend to post a few sample pages of the Players Manual to the World in Flames forum once it is ready for printing.

Tutorials and Training Videos
Nothing new on completing the training videos. I listened to a couple of them this past month and haven’t changed my mind about which are okay as is and which need to be re-recorded.

Historical Video, Music, and Sound Effects
Nothing new.

Web Site
Nothing new.

Marketing
Nothing new.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 41
RE: MWIF Monthly Reports - 9/2/2013 5:46:00 PM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
September 1, 2013 Status Report for Matrix Games’ MWIF Forum

Note:
I’ll be traveling to Philadelphia in the last week of September for the second annual followup at Wills Eye Hospital for the surgery on my left eye’s melanoma. Next month’s status report will most likely be a day or two late.


Accomplishments of August 2013


Hardware and Software
I purchased replacement headphones for completing the recording of the training videos. Lovely Hawaiian salt air had dissolved all the thin plastic elements in my old ones. Complementing that purchase, I upgraded my copy of the Camtasia software from version 5 to 8.1; Camtasia is for recording a video of an executing program with audio voice-over.

The three open items for Theme Engine remain the same.

Beta Testing
In August I released 4 new versions to the beta testers: 11.00.01 (18 fixes), 11.00.02 (29 fixes), 11.00.03 (1 fix), and 11.00.04 (10 fixes). Release 11.00.03 fixed a fatal bug that was preventing the beta testers from testing new games. The numbers of new versions and fixes (58) are below my averages. That’s because of the time I spent on the final preparation of the printed material and redoing a couple of the training videos. The former are on the critical path for releasing the game. For the latter, I wanted to re-familiarize myself with the process, since I still have 3 training videos left to do, and the last time I did one was four years ago.

I cleaned up a couple dozen odds and ends in the world of existing bugs, but spent the bulk of my debugging time on NetPlay. I now have all 8 air missions executing correctly in NetPlay. More on that below.

Here is a summary of my Master Task List (MTL) as of September 1st. My task list count stands at 86, down from 95 at the start of the month. However, there are another 17 posts from the beta testers I haven’t checked into yet. Bugs can be corrected quickly (as per the 47 fixes for the first two new versions this month), or slowly, like the last 5 days I’ve spent working on the Naval Combat bug(s) in NetPlay. Grind, grind, grind.

NetPlay [6] 1785, 1826, 2056, 2099, 2100, 2101

Sequence of Play [58]
Supply [13]: 1070, 1982, 1988, 2061, 2064, 2078, 2083, 2086, 2088, 2089, 2106, 2128, 2130
DOW [1]: 2094
Air Missions [5]: 1611, 1890, 1925, 1996, 2117
Naval Movement [1]: 1990
Naval Combat [2]: 1724, 874
Land Movement [1]: 2118
Land Combat Declaration [1]: 1995
Use Oil [2]: 2042, 2091
Production Planning [21]: 1107, {847, 961, 1347}, 326, 1644, 1671, 1825, 1862, 1863, 1864, 1893, 1895, 1973, 2006, 2014, 2020, 2084, 2111, 2112, 2113, 2122, 2126
Search Seizure [1]: 409
Conquest [1]: 1047
Vichy [5]: 1803, 1811, 2017, 2028, 2063
Liberation [1]: 1919
Overstacked Digression [2]: 1931, 2074
Final Reorganization [1]: 1733

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


Saved Games
Done, except for the bugs listed above.

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

Optional Rules
Nothing new.

Game Engine
Other than fixing supply bugs, I have no remaining tasks related to this.

Player Interface
Done, except for the bugs listed above.

Internet - NetPlay
I spent at least half my time in August on NetPlay.

Debugging the NetPlay code is some of the most difficult programming I've ever had to do. I need to keep two images of the code in my head with each computer at different points in the code, with different values for their internal variables. And then I need to envision the actions by the two players causing messages (Game Record Logs) to be sent between the computers which change the status of variables. Besides the normal stuff of timers to control the transmission, receipt, queuing, and processing of messages between computers, I also have the program running timers in some phases waiting for players to make open-ended decisions about what should happen next. Currently I have 582 GRL record definitions for all the different actions that can happen during a game.

I finally got Port Attacks to work cleanly (a bug first reported in March), and I got air-to-air combat (first reported in February) finished as well. Port attacks have all the subphases of the other air missions as well as elements of naval combat (search numbers, excluding submarines, surprise points, and the naval combat results table). Air-to-air combat has 11 subphases with multiple rounds, and there can be multiple combats being resolved for any given air mission. Both of these have random assignments of which side makes decisions at various points in their processing. In NetPlay, having to disable one computer from taking any action while the other player decides what to do occurs a lot in the game. When it happens repeatedly while a complex form is visible on both computers, coding the process is extremely difficult. There are screenshots below showing the sequence of play for air-to-air combat and naval combat.

Naval combat is another bug first reported in February. Naval combat has 28 subphases and like air-to-air combat, there can be multiple rounds and multiple combats being resolved. This has been driving me nuts for the past 5 days. At the end of this report are some screenshots from debugging naval combat, port attacks, and air-to-air combat. The last two are bug free at this point.

In naval combat the program would get as far as the 10th subphase okay. When I put in debug messages to help me analyze the problems with going to the 11th subphase, the Axis computer would get stuck on the 3rd subphase. Because there are so many steps to recreate a problem, I thought I was doing something wrong with the mouse or keyboard on one of the two computers. Eventually I determined that it was merely the presence of the debug messages that was causing the program’s behavior to change. Tracking that down, I found that the timing loops would get out-of-sync if one computer took longer in responding to a debug message. Continuing backwards, I determined that the transition from subphase 0 to subphase 1 was where the real problem occurred. Fixing that, I was able to get the program to advance as far as the 6th subphase, where the Allied computer ran into trouble. As I write this I have gotten up to the 9th subphase (spending surprise points). I’m still trying to get back to the happy days earlier this week when my problems were in the 10th subphase.

While I hacked away at fixing the NetPlay code [picture me with a machete in the hot, humid jungles of Burma while mosquitoes feast on my exposed body parts], the beta testers (mosquitoes?) posted about 1 new bug a day. Mercifully, the importance of those keeps getting less and less, as far as actually playing the game. Some are critical; but some are about cosmetic stuff or "Gee, it would great if ...", which I dutifully record but am unlikely to do anything about for the initial release.

Most of the phases with long subphase sequences have been tested and debugged for NetPlay. The only one untested is the creation of Vichy France. I’ll have the beta testers start testing that next.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing substantially new. Peter S. has been working on the strategic plans for Italy and I added a comment or three from time to time.

Player’s Manual and Rules as Coded (RAC)
These are at the printers. I’ll post some sample pages of the Players Manual to the World in Flames forum once I get permission to do so. By the way, the cover page for the Players Manual is my new desktop background.

Tutorials and Training Videos
I completed my review of the existing training videos, done in the summer of 2009 (four years ago). Of the 9 chapters that I completed that summer, 7 are still accurate:
2 Map basics (20 minutes, 27 seconds)
3 Unit basics (28:27)
4 Sequence of play (33:56)
5 Turns impulse, weather, and supply (25:28)
7 Starting and new game and setting up units (55:40)
8 Air movement and combat (23:43)
9 Land movement and combat (43:46)

This month I re-recorded chapters 1 and 6 which were woefully out-of-date. Chapter 1 is an Introduction to the training videos covering the Opening screen, with an overview of: (1) the picture & text and interactive tutorials, (2) the scenarios, and (3) restoring a saved game. It also examines the first page of the first tutorial: (1) general layout of the picture & text tutorial pages, (2) converting the board game to the computer, and (3) the unified world map. The new version runs 9 minutes and 13 seconds.

Chapter 6 covers the Main form, Information forms, Screen layouts, and Map views. My re-recording of this chapter increased the time from 46 minutes to 66 minutes, 5 seconds. The increase was primarily due to new material. From the Main form’s drop down menus two new forms are available: disabling phases by major powers and the supply sources and paths. Neither of those existed in 2009. Additional time was spent on the production planning form, which has been redesigned from top to bottom. It now provides a lot more information about resources, factories, convoy pipelines, and production/build points.

Disabling phases lets a player turn off some phases for major powers. For example, China rarely wants to perform port attacks or naval air missions, given its few precious air units. Rather than have the program cycle through China for those phases, requiring the player to click on the end-of-phase button, the program skips the phases completely for China if the player has disabled those phases. The main use of disabling phases is for CAP (Combat Air Patrol) for the eight air mission phases. CAP is rarely performed. When the Axis player is the phasing side, that results in up to 40 mouse clicks by the Allied player to end the CAP subphase in just one impulse - very annoying.

The supply sources and paths form didn’t exist in CWIF. I felt it was important to add this form for two reasons. First, new players can use this form to learn the supply rules. Seeing examples of all the supply sources for a major power and the paths that units trace to reach a primary supply source is the easiest way to understand how the system works. This also applies to all those board game players who have played the supply rules incorrectly for years (I know you’re out there). For experienced players, being able to find all the out-of-supply units for friendly and enemy major powers is nice. It’s also helpful to be able to see a report on opportunities for cutting enemy supply paths - and the vulnerabilities of your own.

I still need to record chapters 10, 11, and 12.

Chapter 10 Naval Review & Movement
10.1 Naval review
10.1.1 Units In Hex form
10.1.2 Flyouts form
10.1.3 Naval Review Details form
10.1.3.1 Plain display
10.1.3.2 Section display
10.1.3.3 Status display
10.1.3.4 Filters
10.1.3.5 Cycling through ports and sea areas
10.1.4 Double size global map
10.1.4.1 Sea area names
10.1.4.2 Working with the Units in Hex form
10.1.4.3 Working with the Flyouts form
10.1.4.4 Working with the Naval Review Details form
10.1.5 Naval Review Summary form
10.1.5.1 Filters
10.1.5.2 Working with the Naval Review Details form
10.1.5.3 Cycling through ports and sea areas
10.1.5.4 Saving and restoring displays
10.2 Selecting naval units for movement
10.2.1 Using the Select Units form
10.2.2 Using the Flyouts form
10.2.3 Using the Naval Review Details form
10.2.4 Using the Units In Hex form
10.3 Moving a group of naval units
10.3.1 To an adjacent sea area
10.3.2 To a distant sea area
10.3.3 Dropping off units: at sea & in port
10.3.4 Specifying a path of sea areas
10.4 Loading cargo
10.4.1 Starting in a port stacked with the cargo
10.4.2 Picking up cargo from a port when passing through
10.4.3 From a coastal hex upon arrival in a sea area
10.4.4 From a coastal hex prior to returning to port
10.5 Naval interception
10.5.1 Decision to try to intercept
10.5.2 Attempt to intercept
10.5.3 Decision to stop or fight through
10.5.4 Fighting through
10.5.5 Continuing movement after interception attempt and/or combat

Chapter 11 Naval Combat
11.1 Naval combat occurrences
11.1.1 Phasing side chooses
11.1.2 Non-phasing side chooses
11.1.3 Naval interception combat
11.1.4 Naval air support
11.2 Naval surface combat
11.2.1 Surprise points
11.2.2 Including units
11.2.3 Naval combat results
11.2.4 Multiple rounds
11.3 Naval air combat
11.3.1 Use of temporary carrier air units
11.3.2 Use of optional carrier air units
11.3.3 Air-to-air combat
11.3.4 Anti-aircraft fire
11.3.5 Air attack on surface ships
11.4 Naval submarine combat
11.4.1 Choosing combat type
11.4.2 Anti-submarine warfare (ASW) attack
11.4.3 Submarine attack on surface ships
11.5 Naval abort queue

Chapter 12 Production & Politics
Specifics will be the same as the material covered in the interactive tutorials #19 and #20.

Historical Video, Music, and Sound Effects
Nothing new.

Web Site
Nothing new.

Marketing
Nothing new.


Debugging NetPlay

There are 5 screenshots below. The last two show the sequence of play for air-to-air combat and naval combat. In those the flags indicate which major power is deciding in which subphase/sub-subphase. Tracking back to the top of a column and reading to the left, identifies the parent phase/subphase et al. For example, the air-to-air combat shown is for Ground Support, in the land combat ‘group’, in the land ‘stage’ of the sequence of play.

The other 3 screenshots are annotated debugging screenshots for naval combat, port attacks, and air-to-air combat (ground strike phase). Each of these has top and bottom panels, with the top for the GRLs sent and the bottom for GRLs received. The color of the screenshot indicates the viewing major power: blue for Commonwealth and grey for Germany. The horizontal red lines indicate when one side has completed sending a set of GRLs to the other side. The second number in each GRL is its “entry number”. These usually increment by one for each new GRL.

The first screenshot has black numbers on a yellow background to identify the order in which they were sent. So the naval combat screenshot (in blue) starts with [1] the Commonwealth receiving two GRLS from the Axis (#27093 and #27094) when the Axis player terminates naval movement for Germany and Italy. The Allied computer is always MasterMWIF and sends most of the GRLs ending phases/subphases and for rolling the dice. Here [2] it sends a Phase Done GRL (PhDo #27095) to change the phase to Naval Combat A (phasing side). Having determined that naval combat is possible, it then sends another PhDo (#27096) to change the subphase to Choose Sea Area. The Axis player [3] decides to initiate combat in the North Sea and selects which unit to use to initiate that combat (#27097). The process continues with GRLs being sent and received by both computers.

My annotations are mostly correct, but I was a little sloppy in places where perfect precision was irrelevant for debugging purposes. However, this degree of analysis is what is required to debug the NetPlay code. All of these screenshots are from the middle of August and I have since debugged the problems shown here. I should add that the code works correctly for the Solitaire and Head-to-head modes of play. It’s this jumping back and forth for who decides what when during NetPlay games that still has some flaws.





Attachment (1)

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 42
RE: MWIF Monthly Reports - 10/2/2013 2:31:28 AM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
Just a short note for this month.

In case you didn't hear already, the official release date for MWIF is November 7th.

I made my annual visit to Philadelphia following up on the treatment for the melanoma in my left eye. The cancer cells remain dead and are slowly being cleaned up by natural bodily processes. Its thickness has decreased from 5.1 mm in 2011, to 4.1 mm last year, and 3.4 mm this year. But the micro-radiation treatment has caused (20 months after the event) damage to other parts of that eye's retina. That's getting periodic injections to reduce the inflammation and other poor performance by the cells involved.

---

I finished recording the last 3 training videos while I was in Philly, but I still need to edit them to remove all my hems, haws, and long silences.

I put in the sound effects, music, and historical video clips last month.

For the month I uploaded for the beta testers versions 00.11.00.05, 00.11.00.06, and 00.11.01.00 through 00.11.00.08. That's 11 new versions with a total of 119 fixes. Not too bad considering the last version was uploaded on September 25 before I left for Philly for 5 days.

I'm working my way through the remaining bugs. Those number less than 50 as I write this.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 43
RE: MWIF Monthly Reports - 11/1/2013 8:25:02 PM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
November 1, 2013 Status Report for Matrix Games’ MWIF Forum

The release date is still November 7th.

Hardware
I purchased two 30 inch monitors (Dell U3014) for my main system and they are just lovely. I am able to place the entire Interactive Delphi Environment (IDE, the source code and compiler stuff) on one screen. On the other I have a 40% vertical strip for my task list and the other 60% for an MWIF game-in-progress. This lets me select a bug to work on, fire up the game to recreate the problem, and examine/modify the code, all without having to open and close windows or scroll about madly in a tiny form.

Of my two old 24" monitors, my wife grabbed one for her Apple computer. So I have both a 24" and my wife’s 17" monitor sitting idle. Sometime in the first half of this month I’ll buy two more computer systems so I can start working on NetPlay for 4 players. I had to replace my graphics card to support two DVI cables for the 30" monitors and I replaced my keyboard & mouse because I had worn them out. The Ctrl and C keys on the keyboard were blank (I wore off the lettering) and the palm rest had a hole in it where my left hand rested. That was after only two years. I really like the Logitech wireless keyboard mouse combination, so I just bought the same thing again. Very little has changed, but the new one is much nicer than my old, heavily worn one.

I’ve also replaced my modem and router (8 years old) with a new modem/router. This virtually doubled the up and down speeds for my internet connection. The DSL line itself will be upgraded by the phone company in the next couple of days from 7 Mbps to 15 Mbps. I should replace my main computer too. It will be 4 years old next month and the salt air in Hawaii really does a job on plastics. It etches away at the metal bits too. But that will have to wait until 2014. I expect it to take at least 2 weeks for me to transfer all my files and software over to a new system. Presently I can’t afford that big a down time from my work.

Beta Testing
I have to be doubly sure about any changes I make from now on. I can’t afford to have modifications damage the existing, proven code. There is a never ending list of improvements possible, but I need to keep my eye on the ball and only do those which are important (for one reason or another). Frivolous little stuff doesn’t warrant risking the code base.

Marketing

Now it is up to you, dear reader, to answer the two crucial questions: (1) how big is the market for this niche product, and (2) how much do players like this Matrix version of World in Flames?

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 44
RE: MWIF Monthly Reports - 12/1/2013 9:45:43 PM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
December 1, 2013 Status Report for Matrix Games’ MWIF Forum

Product Release
Releasing MWIF went relatively well. Shipping the manuals and maps got off to a rough start, but everything is shipping smoothly now. While I was expecting some diversity among players who bought the game, I was still rather naive about how wide the range was in three areas: computer systems, familiarity with computer wargames, and familiarity with World in Flames.

Customer computer systems at the low end are single monitor systems, some of them laptops or portables, as well as small home computer systems. Dusting things off to play MWIF appears to have happened in more than one case. There have also been reports of hauling a second monitor out of a closet, attic, basement, or garage. At the other end there are players who have very elaborate computer systems, including RAID and networked disk storage. Multiple computers are not uncommon, with the program being installed in more than one. To round out the range of systems, there are Mac and Unix boxes running MWIF in virtual machines (VM) with Windows as the VM operating system.

Some players have very little experience with computer wargames. They might come from a background of playing Risk, Axis and Allies, 3rd Reich, Advanced Squad Leader, or other board war games, including World in Flames. For these players there is a learning curve of simply downloading and installing the game. Dealing with disk drives, directories/folders, and other basics of the Windows operating system is not second nature to them. A whole new vocabulary needs to be absorbed. Then there are players who own multiple games from Matrix/Slitherine. They can jump ahead of other players in many ways. Their expectations exceed my knowledge of the Matrix/Slitherine gaming world/community. In these cases, I am the one who is learning new stuff.

Looking at the area of familiarity with World in Flames, even players who have a lot of experience with wargames can find MWIF strange because of the game design for simulating WW II. The simple concept of a turn is expanded to include impulses, phasing side, phases, and subphases. Instead of Axis and Allies, each major power operates as a quasi-independent entity. Having to choose an Action for each major power is easy to grasp in the abstract, but very hard to master in practice. Regardless of how it is viewed, learning WIF is a long process. Mercifully, a lot of that learning can be made enjoyable, by playing the game and acquiring various emotional bumps and bruises from trial and error. Some players who have extensive experience with WIF (e.g., grognards) place demands upon MWIF far beyond its ability to satisfy. The board game is 28 years old and has undergone dozens of revisions and enhancements over the years. In fact, that process continues to this day. What is the game World in Flames? The answers to that question are almost as numerous as the players who play it. MWIF is a computer program - it provides only a single answer, which rarely matches perfectly with all the other definitions of WIF.

The endpoints in these three areas generated a lot of questions, and answering them all has taken a lot of my time - given willingly, but reducing the time I have for other MWIF related tasks. Enabling players to get started playing MWIF has been a high priority for me. There are many possible stumbling blocks when using any new program, and MWIF is no exception. Despite me (and others) going to extreme lengths to help with the MWIF learning curve, (e.g., tutorials and manuals), players still have difficulties and questions early in their ownership. These can relate to their computer systems, their familiarity with computer wargames, and/or with their familiarity with World in Flames.

Oftentimes, these questions are reported as ‘bugs’, but after investigation turn out to be something other than defects in the MWIF code. No one knows that at first; only after delving into the details of a problem can they be separated into non-MWIF causes and MWIF bugs. Because players start with different expectations, communications can be difficult until a common understanding is achieved. Not that everyone is fully sated then, but at least the question of whether the unfulfilled expectation is a bug or not gets answered.

Bugs
The worst bugs in the first couple weeks were:
(1) Loading saved games, which was fixed by 1.0.1.0 (available on the day of release).
(2) Port attack anti-aircraft fire, which started as a NetPlay bug, but my fix for that transformed it into a Head-to-head bug, and my fix for that transformed it yet again into a Solitaire bug. Only with version 1.0.4.1 was I able to eliminate it completely.
(3) Accessing the NetPlay Seeking Opponent database, which still isn’t perfect but at least it is now understood and correctable. The problem is that Slitherine maintains a registry of customers with user names, passwords, and a list of games they own, by serial number. When accessing the Seeking Opponent database, the user name and password provided by MWIF has to match. If it doesn’t, then the message about being unable to access the Seeking Opponent database is generated. Meanwhile, MWIF maintains a user name and password associated with the player’s serial number on a local disk. When the player logs into the NetPlay forum, MWIF sends that information to the server. This saves the player from needing to type in his user name and password every time he enters the forum. The local disk file is NetPlayReg.txt, and the user name and password are the first two lines in that file. It’s possible to have a mismatch between the local disk file and the Slitherine master registry. The solution is to edit NetPlayReg.txt so the user name and password match those for the player in the Slitherine master registry.

There are a lot of things to fix. Many occur rarely but nonetheless are annoying to the player and even more so to me, since I get an emailed report from each player who runs into them. Every time I fix a bug, that means I will no longer get emails about it - a very strong motivation. Take for instance, the Seeking Opponent database problem. I probably received close to 200 emails about that, plus all the reports in the forums. The tide rolled in, and there I stood with just a small plastic pail with which to bail.

Other bugs have workarounds, and I am letting most of those slide for now. I knock off a couple a day, but I really give a higher priority to the Mad Except errors. Keeping track of everything reported takes a lot of my time. Once I reduce the numbers of items being reported, I’ll have more time for other code changes.

Customers
Without making a comprehensive survey, I know that MWIF is being played in: Canada, the United States, Brazil, Norway, Sweden, Finland, the United Kingdom, the Netherlands, Germany, France, Switzerland, Croatia, Italy, Spain, Russia, Japan, China, Thailand, Australia, and New Zealand. Truly a world at war.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 45
RE: MWIF Monthly Reports - 1/3/2014 10:04:12 PM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
January 1, 2014 Status Report for Matrix Games’ MWIF Forum

Product Support
I’m slowly coming around to a new definition of self: author of a recently released computer war game. As such, I am in communication with hundreds of players and I struggle to find the time to interact with them all. My wife pointed out that I am vastly outnumbered. Hence my terse replies or sometimes total silence: “everybody’s talking at me, can’t here a word they’re saying”. Actually it’s not bad, or even sad, but I wish I could maintain dialogues with more people.

I did finish the year keeping my one 2013 new year’s resolution: no trips to the emergency room. For 2014, I have the same resolution with the addendum: no new specialists. In December I added a dermatologist as the 7th in my medical support team (periodic 6 or 12 month visits): dentist, internist, cardiologist, urologist, optometrist for my good right eye, and retinal specialist for my bad left eye. The dermatologist removed a small basal cell carcinoma from my back: a 15 minute in and out visit with only a band-aid necessary afterwards.

Because the pressure to work on the game has abated somewhat, I’m taking a 70 minute walk to the beach every other day. I should be back to singing with the chorus weekly this month and hopefully will once again be delivering singing valentines come February. Maybe I’ll get out on the golf course in the spring.

I see my work as three general activities: answering questions about MWIF, investigating reported bugs, and fixing bugs. The first occupied a lot of my time in November and early December. By the end of the month, it had tapered off significantly. Investigating and fixing bugs both need more of my attention, but there are only so many hours in a day. What I do have set up and running well now is processing my 3 data streams: emails, World in Flames forum posts, and beta tester reports.

I log all my emails about the game into a spreadsheet. It might take me time to get around to each of them, but none of them is lost. Paul has been maintaining a second spreadsheet for me of the bugs reported in the Tech Support forum. That has been of tremendous assistance. We’ve developed a set of categories which I use to sort the bug reports so all those concerning similar topics are together. That let’s me identify duplicates. I use a similar system for the email spreadsheet. Besides helping me solve a group of problems in one sitting, it also gives me a feeling of being in control, replacing my earlier sense of having a pile of disparate issues to figure out.

Bugs
I’ve been releasing a new update on average once a week. Most likely that will continue for the next month. While I would like to have NetPlay running smoothly, I have a marked bias towards fixing the solitaire bugs. Partially that is because they are easier to fix, but primarily it’s because if the bug appears in solitaire, it is also certain to appear in NetPlay. The types of bugs in solitaire fall into two broad groups: obscure and newly created. The latter happen when I make a change to fix one bug and cause another. Two examples from the past week: leaving out the word ‘not’ in a line of code, which caused naval combat to fail, and using ‘or’ when ‘and’ was the correct boolean operator, which caused the anti-aircraft fire subphase to be skipped. Naval combat has 20,000 lines of code and anti-aircraft fire has at least 5,000 lines, but all of that was totally worthless because of two mis-thinks. Programming is either perfect or wrong.

AI Opponent

I’m not suppose to be working on this yet but I’ve found a necessary task that is undemanding and serves as a break from debugging. I take 20-40 minutes a day typing in the land region IDs for land hexes. All sea hexes already have their Sea Area IDs which can be used by the AIO when making decisions involving movement and control of all sea hexes. For the land hexes, Peter S. and myself have worked out 321 different land regions. Those are grouped into Areas of Operations, which are grouped in turn into Theater of Operations. But that information has to be communicated to the AIO so it can ‘think’ in terms of “defending western France from invasions”, or “advancing into the Ukraine.” To do that I am editing the TER data file, adding a land region ID to the end of each line of data: one line per hex. So far I’ve completed all of Europe, from Iceland to the Canary Islands, from Karelia to Suez. I’m going to do the USSR next, up to Sverdlovsk, which should be enough for the AIO to ‘play’ Barbarossa. There are a lot of hexes in the USSR and each one of them needs their own little Land Region ID number.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 46
RE: MWIF Monthly Reports - 2/1/2014 7:40:22 PM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
February 1, 2014 Status Report for Matrix Games’ MWIF Forum

Product Support
I’m doing better about my health: making weekly chorus rehearsals (3 hours standing on the risers singing), I’m scheduled to sing in a quartet delivering valentines all day Valentine’s Day (from 9 AM to 9 PM), and I’m making it out to the golf driving range once a week. Muscle memory for these activities is slowly coming back after a hiatus of 4 years.

Most of my work is now down to two general activities: investigating reported bugs and fixing bugs. But as always, there’s never enough time in the day. The flow into my email inbox is now approaching something reasonable. In November it was 29.1 per day, in December 14.5, and for January 9.2. I still see a lot of duplicates for bugs reported - but it’s attenuated from roughly 70% duplicates down to 60%.

Bugs
I release a new update once a week. Most likely that will continue for the next month. Only small progress on NetPlay in January; February should be the breakthrough month for NetPlay. Within the first half of February, I also expect to be able to clean up the bugs in overseas Supply.

Missing Optional Rules & Half Map Scenarios

I want to make some progress on these in February. Obviously, bugs have a higher priority at the moment. However, when time permits, my preference is to whittle away at larger tasks, such as these, so they are not quite so monolithic when they rise to the top of my to-do list.

AI Opponent
This mostly dropped off my radar in January, but I expect to be able to get back to assigning Land Region IDs to Africa in February. One of the reasons I stopped was that I had achieved my first goal: assigning land regions to every hex in the European Theater of Operations, which means the basic data necessary for the AIO to play Barbarossa is in place. Getting the AIO to play both sides of Barbarossa will be the first ‘actual’ game for testing the AIO. Concurrent with that, we will be testing the scripts for setting up units in the other scenarios. There are a lot of scenarios and a lot of major powers, plus all the minor countries, so creating and testing the scripts for simply setting up units is a non-trivial task in coding the AIO.

Oh, as I have mentioned before and should repeat again now, Barbarossa, Guadalcanal, Global War, and Fascist Tide will be the scenarios we will primarily focus on for the AIO. These 4 scenarios are the ones most players want to play, so they sit at the forefront for the AIO to learn to play well.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 47
RE: MWIF Monthly Reports - 3/5/2014 7:30:15 PM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
March 4, 2014 Status Report for Matrix Games’ MWIF Forum

Product Support
Two doctor visit/checkups yesterday - I passed the first one with my internist okay and the second doctor (retinal specialist) said the vision in my bad eye is getting better (20/50 now). On Valentine’s Day and the day before, I helped deliver singing valentines (I sang bass in the quartet). We did 8 deliveries each day and did slightly better this year: more than half of the recipients were in tears. Usually that happens early in the first of the two short songs we sing - the women love the romance of it all. But this wiped out two days for working on MWIF (8 hours plus 11 hours on the road).

I purchased two new computers in February and set them up for testing NetPlay on 4 machines. Most likely I won’t get to that until April though. Because the demolition of our kitchen and guest bathroom is scheduled to start the last week of March, I wanted to get the additional systems installed and checked out before chaos descends upon our apartment.

Bugs

My work continues to be investigating reported bugs and fixing bugs. But as always, there’s never enough time in the day. The flow into my email inbox is abating: down to 5/day, which is about half of what it was in January. As always, February was a short month, even more so with the loss of a couple days for singing and a couple days installing computers.

The goal of releasing a new update once a week wasn’t met. And there will probably be only 3 updates in March. The beta testers want more time for testing each release, primarily because of the problem with the unacceptable delay in response time for moving units introduced by version 1.1.5.0 (and corrected by 1.1.6.0). Supply occupied almost all my time in the last half of the month. Below is an “under the hood” discussion of Supply if you are interested in what the program is actually doing for all those CPU cycles.

NetPlay got some fixes in the beginning of February and I should be able to clean it up in the first half of March. That’s even given that I want to correct the few remaining bugs in recalculating supply while the code is fresh in my mind: (1) recalculating supply for secondary supply sources which had previously been using overseas supply, (2) territorial units belonging to a conquered minor country and controlled by the conqueror tracing supply to cities in their homeland, and (3) notional units tracing supply after the enemy units have ‘landed’ in their hex.

Missing Optional Rules & Half Map Scenarios

Unfortunately I made no progress on these in February. Obviously, bugs had, and have, a higher priority.

AI Opponent

This also got none of my attention in February. But as the saying goes: hope springs eternal. In this case for making progress in March on background preparation for the AIO.



Supply Calculations


There are 23 steps in calculating supply. All of them are executed when a game starts or is restored, when the weather changes, and when countries join/leave the war. At other times during game play, some of them are executed. Most often that is when the player moves units onto, off of, or about the map.

But once the original calculations have been run, the program is much faster doing supply ‘recalculations’. That’s because the program records the supply paths for every secondary supply source to a primary, every tertiary to a secondary/tertiary, and for every unit. Having the paths stored in memory let’s the program start the recalculation task by testing each previous path to see if it’s still valid. New searches are required only for old paths that fail.

Steps 1-4
The first step is to identify which countries might need supply. If the country is a governed area (i.e., doesn’t have any units) or is a neutral minor country, then it can be ignored for supply purposes. Then the sea areas are initialized in step #2 based on which optional rules are in effect. For instance, if Limited Overseas Supply is being used and a side (i.e., Axis or Allied) doesn’t have a convoy or transport in a sea area, then clearly the sea area cannot help transmit supply for that side. The next two steps are obvious: identify all the primary supply sources for major power and minor country units, followed by identifying potential secondary supply sources.

Steps 5-7
The fifth step is to attempt to find a rail path from potential secondary supply sources to primaries. That gets a little tricky. To begin with, the search is limited to overland paths and restricted to secondary supply sources controlled by a major power to its own primary supply sources. These paths are the best because when they are found, the secondary supply source can provide supply for all tertiary supply sources and units for the major power, cooperating major powers, and aligned minor countries. Internally these supply paths are referred to as Pure. If a secondary supply source cannot find a Pure path, then the search continues for a path to a primary supply source belonging to a cooperating major power. When found, these are labeled Coop paths. Simultaneously with searching for Coop paths, the algorithm looks for primary supply sources belonging to a minor country aligned to the major power controlling the secondary supply source. These are labeled Aligned paths. The fourth type of path is from a secondary supply source belonging to an aligned minor country to a primary supply source controlled by a cooperating major power: Mixed paths. There is one more type of path: Minor. These are from a secondary supply source belonging to the given major power or one of its aligned minors to a primary supply source for an aligned minor.

Some examples should help clarify the 5 types of paths: Pure (von Leeb to Berlin), Coop (von Leeb to Rome), Aligned (Mannerheim to Berlin), Mixed (Mannerheim to Rome), and Minor (Mannerheim to Helsinki). As mentioned above, Pure paths can be used by the given major power, cooperating major powers, and aligned minor countries. Coop paths can be used by the given major power and the given cooperating major power. Aligned paths can be used by the given major power and the aligned minor country. Mixed paths can only be used by the given major power. Lastly, Minor paths can only be used by units belonging to the given minor country. The last is the only type that cannot be used by the given major power.

The 6th step is to search for overland paths from secondary supply sources without a Pure path to see if they can be tertiary supply sources. First the search is limited to secondary supply sources with Pure paths back to a primary. If that fails for a secondary supply source, then another pass (step 7) is made that broadens the possible secondaries to include those with path types other than Pure. Any paths found in these searches are also labeled as Pure, Coop, Aligned, Mixed, or Minor. It is possible for secondary and tertiary supply sources to have more than one type of path. For instance, Mannerheim could have a Mixed path back to Rome only usable by German units and a Minor path back to Helsinki only usable by Finnish units. These situations occur rarely, but the program is thorough in checking for them all. Indeed, the program allocates memory for as many as 4 Coop paths and 20 Aligned paths for each potential secondary supply source. There is only one slot each for Pure and Mixed paths. Minor paths are stored in the Pure slot for the given minor country.

Steps 8-14
The 8th step identifies all the sea areas that can be used by major powers to trace supply to one of their own primary supply sources. This determination is performed by tracing FROM ports to the supply source. It only uses predefined ports for each major power rather than checking all the ports on the map. There are thousands of ports on the map (something over 5000 if I remember correctly). So, for Germany the list of ports is limited to those in Europe, omitting all the ports in the Americas, the Pacific, and most of the ports in Africa and Asia.

If a port can trace to a primary supply source, then the adjacent sea areas can be used for overseas supply. Furthermore, overseas supply can be propagated to include adjacent sea areas in an ever expanding network of sea areas. Of course, some sea areas are unusable, as determined in step #2. Other restrictions may apply to some major powers when trying to move between sea areas (e.g., Gibraltar and Suez may block supply). An example of propagation is that if Liverpool is a valid port for the Commonwealth (it almost always is) then both the Bay of Biscay and the Faeroes Gap can be used, assuming the other requisite conditions are met for those sea areas. And from there the North Sea, the Norwegian Sea, the Denmark Straits, the North Atlantic, etc. can also be valid sea areas. Once Cape St. Vincent becomes valid, Commonwealth units in Gibraltar will be in supply.

The 9th step checks for out-of-supply (OOS) secondary supply sources which can then use the newly available sea areas for overseas supply. To ascertain this, another search is necessary, from the OOS secondary supply sources TO a port that is adjacent to a valid sea area. These are rail paths so the search can theoretically be of infinite length.

The 10th and 11th steps are the same as the 8th and 9th except the search includes ALL ports, not just those hard coded for each major power. These steps are skipped under certain conditions (i.e., if the work done by steps #8 and #9 rendered them unnecessary).

The 12th an13th steps are the same as the 8th and 9th except the search is expanded FROM ports to secondary/tertiary supply sources. The 14th step is similar to the 13th with the 14th not limiting the destination supply sources to those controlled by the given major power. Because the 13th step might find Pure paths, those are done separately and first. The 14th step can only find non-Pure paths which are of lesser utility.

Steps 15-18
These steps are similar to those of steps #8 through #14 with the only change being that the search from tertiary to secondary is for secondary supply sources with a valid overseas path. That means that the tertiary to secondary search must be overland, since only one overseas link is permitted in a supply path.

Step 19
This is the first time the search is for paths from units themselves to supply sources.

Steps 20-22
These steps repeat the pattern for finding overseas paths, but for minor countries. Note that in almost all cases a minor country unit gets supply from supply sources belonging to its controlling major power.

Step 23

This final step is for minor country units that are still OOS after running step #19, in the hopes that they might find supply from their own cities because of the newly enabled sea areas in steps #20 through #22. This comes up from time to time. For example, Rumanians might need to use the Black Sea to find a path to primary supply in Bucharest.

Summary
Supply for MWIF was one of the 3 most difficult things to code. The others also involved sea areas: production planning routes and naval movement (with naval interceptions and naval interception combat). In general coding MWIF involved a lot of grunt work because of the sheer size of the map, the number of units, and the number of rules. There are thousands of lines of code just for setting up units on the map for each scenario based on the chosen optional rules. Then there was a lot of tedium counting pixels for displaying hexes and units on the map and positioning various visual elements on the 150+ forms. Mercifully, being clever wasn’t a precondition for the vast majority of the programming.

Still and all, supply is the only item that required optimization of execution to keep the CPU cycles to a minimum. To achieve that I needed to draw upon methods I learned back in the 1960's, 1970's, and 1980's when there was a limited amount of memory available and the CPU speed was pitiful. In 1985, the Atari 800 had 64 KB of RAM with only 32 KB available for an application; its CPU speed was 1.2 KHz. Today MWIF has over 1 GB of RAM available (it uses ~500MB) and CPU speeds measured in GHz. Those are improvements of a million times in both RAM and CPU speed. Doing calculations once and storing the results for fast retrieval is one tactic used by MWIF. Another is understanding the task in exquisite detail so efficiencies could be introduced based on certainties of which steps could be skipped under specific conditions.

I might need to revisit Supply another time or two if game situations push the existing code to use too many CPU cycles, making the response time too long. But writing that type of code is very unpleasant and is only undertaken when doing so is absolutely essential.


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 48
RE: MWIF Monthly Reports - 4/3/2014 6:32:02 PM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
April 3, 2014 Status Report for Matrix Games’ MWIF Forum

Product Support
I didn’t get much work done in the last half of March. Our chorus’ annual show was on the 22nd and we had either a rehearsal or a performance every day for the entire week before that. Meeting all those people (instead of hunkered down with my computers) I picked up a head code that wiped me out for 4 days the following week.

The demolition of our kitchen and guest bathroom started on the 27th which was preceded by several days of us needing to clear the decks for action. Progress on the remodeling is now going well, with a crew due to arrive this morning to haul all the wreckage away. Meanwhile the construction guys have been bringing in all the new stuff and storing it around and about our apartment: 7 new doors, a bathtub, a toilet, lumber, and plumbing fixtures. That collection joins the 30+ boxes holding the kitchen and bath cabinets that have been keeping us company for the past 11 months. The rough estimate is that things will be finished at the end of April, plus or minus a week.

Bugs
Erik and I decided to do a complete review of where we stand on fixing bugs.

It took almost a full week just bring my record keeping up-to-date. That meant going through all the posts in the Tech Support forum and adding any new items therein to my spreadsheet. The Tech Support spreadsheet was originally done by Paul, but I have substantially modified it, sorting it into rough categories (e.g., supply, production planning, land, air, naval). In the process I downloaded all the saved games provided in the Tech Support forum and assigned them file names to match the numbering system I have for the spreadsheet.

The second spreadsheet I maintain (emailed bug reports) only needed a modicum of editing to bring it up-to-date. Like the Tech Support spreadsheet, this one also has a set of associated saved games, to which I assign numbers. I now make a point of getting both spreadsheets current at least once a week.

My third source of bug reports is from the beta testers. I am both better and worse at processing their input. At times I make changes immediately in response to what they post in the private Development forum. That’s to fix new bugs in my currently in-development version of MWIF. But I am not as good at acquiring a complete record of the bugs they report - mainly because I fell so far behind when the game was released.

All the input streams of bug reports are rife with duplicates. Sometimes that a report is a duplicate isn’t obvious, so I end up with multiple entries in the spreadsheets. A sort of insidious problem is that once I correct a bug, I then have to go through all my record keeping and mark items as fixed.

The last step in my record keeping was to create a new Word Perfect text file with a one line entry for each problem. That summary is sorted by category, like the Tech Support spreadsheet, and merges all 3 bug report input sources. Based on the bug report numbers, I can tell at a glance their source: under 2500 are from the beta testers, 2500 to 2999 are from Tech Support, and 3000+ are from emails. This system lets me examine, for instance, all the bugs reports on Supply using the Summary file and then delve into the specifics looking at the descriptions in the Tech Support spreadsheet, an email, or a beta tester Development forum post.

Having completed a review of where we stood, the decision was made to prioritize Solitaire bugs ahead of NetPlay bugs. Furthermore, the Supply bugs were given pride of place, accompanied by critical bugs (i.e., those that were halting games and could not be worked around). Once all Supply bugs are fixed, we’ll move on the Production Planning followed by the Naval bugs (movement and combat).

Another change in our operations was to validate changes in the program using Open Beta versions. These are available to players who want the latest and greatest, but understand they come with the caveat that there might have been some new bugs introduced. So far we just did one of these: version 1.1.7.2. It has gone a week with no new bugs reported by the beta testers or other players who opted to test the version, so it will now be made available as an ‘official’ update.

I have been working on the next Open Beta in the meantime, fixing primarily supply bugs. There are still seven on my task list, 4 of which are unlikely to occur during most game play. See below for some visuals of my various records. We think that going forward, we should have a new version available every other week, with each version fixing all the known bugs in a ‘section’ of code plus those that halt game play. The first three ‘sections’ are: Supply, Production Planning, and Naval.

Missing Optional Rules & Half Map Scenarios

Unfortunately I made no progress on these in March.

AI Opponent
This got none of my attention in March.



The attached composite screenshot, from top to bottom, shows: Summary of supply bugs, Details of supply bugs (mostly from beta testers), Tech Support spreadsheet section on Supply bugs, and the remaining email bug reports from January which need to be investigated (those concerning supply have a status of Open - S). The summary form has Master Task List numbers colored green if a saved game is available to recreate the problem. That is a key piece of information and appears in all 4 lists. The items in pink are the ones I will work on next.

Note that the email spreadsheet has separate pages for each month and the entries generally have less information about the game-in-progress at the time the problem occurred (e.g., unknown mode of play, scenario, turn, phase, decision making major power, player action that generated the problem, etc). On the other hand, when a Mad Except has occurred, I do get the program version number and precisely where in the code the Exception occurred, with the call stack so I can trace back to all the calling routines. Sometimes that is enough, but many times I have too little information to go on to understand what happened. Far better are the beta tester and Tech Support reports which have saved games and instructions on how to reproduce the problem.





Attachment (1)

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 49
RE: MWIF Monthly Reports - 5/3/2014 2:58:29 AM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
May 2, 2014 Status Report for Matrix Games’ MWIF Forum

Product Support
Work continued on our kitchen and guest bathroom throughout the month of April. Currently it’s expected to be finished May 16th. With 2-4 workmen coming in and out 5 (or 6) days a week, from 8 AM to 4 PM, wielding various saws, drills, and hammers with great energy, plus their various conversations, it would be an understatement to say my programming environment for debugging has been less than ideal. Meanwhile it is paper plates and plastic forks for meals, with a lot of take-out and MTH (microwave-til-hot). My wife prepared 30+ dinner meals in advance of the invasion and froze them to see us through the duration. As one example of the poor working conditions, the week the electrician was here he turned power off to the apartment on 3 days, twice for over 3 hours. They also cut my internet connection several times.

The attached picture is a composite of what some of the wire runs looked like on the day the electric work passed inspection by the city. The two pictures show partial views of the wall between the kitchen and the living room. That is, the picture on the left has 5 wires running through the wall heading to the right. Those same wires are shown on the picture on the right, coming in from the left. In the right picture is the back of the electric panel, with the old solid cable connections being 3 at the top and 5 at the bottom. The new ones are the flexible cable connections: 2 at the top, 2 at the bottom, and the 5 on the left side. If you look at the ceiling, you can see how far the wall has been moved out to the left (the white popcorn ceiling on the far left use to be in the living room). The kitchen is now 10 inches bigger and the living room 10 inches smaller.

The change in the ceiling is also visible in the picture on the left, of the chase for the plumbing and dryer vent. The large opening in the wall is a pass through, where dishes can be passed from the kitchen to the living room, without having to walk around. The old dryer vent in the chase had a flexible plastic duct which had partially disintegrated over the past 40 years. The resulting opening to the outside (19 floors up) had been noticed by some birds, which had built a nest in the bottom of the chase. The new dryer vent duct is metal, with some sexy black tape used to bind sections of it together (the black tape is heat resistant since the duct is apt to get quite hot). In the left picture you can see the 5 wire runs going through the new wall into the chase, and out the left side to the new, furred out wall on the left. That concrete wall on the left is part of the building’s exterior (“do not do anything to that wall!”) and in order make room for the plumbing after we moved the clothes washer over against it, we had to fur out the wall 4 inches - making the usable kitchen space 4 inches smaller. All those wires are for: the dishwasher, clothes washer, garbage disposal, lighting strips (under the wall cabinets), and electric outlets (also under the wall cabinets). If you are curious how 5 wires became 6, the 6th is one of the bottom cables from the electric panel and it runs under the pass through.

We’re getting close to being done. Since those pictures were taken, all the dry wall has been installed, enclosing those wires etc. We also have half the tile work done for the floors and the shower surround. The base cabinets are in and the wall cabinets are suppose to be installed tomorrow (Saturday). Best of all, the clothes washer and dryer now work, so we don’t need to make trips to the laundromat any more. Next week should see the tile work finished, the countertops installed, and the bathroom wallpapered.

Bugs
I have kept my record keeping of reported bugs up-to-date, including those from: posts in the Tech Support forum, emailed bug reports (from when the program crashes), and from the beta testers.

Version 1.1.7.2 was released as an official update after a week or so as an Open Beta. The beta testers then tested versions 1.1.7.3 through 1.1.7.9, before we made version 1.1.8.0 available as a Public Beta. That had one serious error, which I fixed within a day, for version 1.1.8.2 (another Public Beta).

I’m currently working on version 1.1.8.4, fixing the last of the supply bugs (newly reported for version 1.1.8.2). That should be available next week as a Public Beta. The goal of generating this series of versions is to eliminate all known bugs relating to supply. Those bugs keep getting more and more obscure, but we want to kill them all off before moving on to fixing Production Planning bugs.

Here are a couple of the recent supply bugs fixed for version 1.1.8.4:
• Fixed a problem where capitals and HQs belonging to a minor country aligned to a major power (MP-1) were tracing overseas supply to primary supply sources belonging to major power (MP-2) that cooperated with MP-1 instead of to primary supply sources belonging to MP-1.
• Added code so the HQ of an aligned minor country which is using an overseas route to reach a primary supply source, can provide supply to units of its own country.

Missing Optional Rules & Half Map Scenarios
Nothing new in April.

AI Opponent
Nothing new in April.





Attachment (1)

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 50
RE: MWIF Monthly Reports - 6/3/2014 2:34:49 AM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
June 2, 2014 Status Report for Matrix Games’ MWIF Forum

Product Support
Construction work on the kitchen and second bathroom was finished in May. New carpet is going to be installed in the second bedroom tomorrow morning and next week that room gets a custom made “closet system”. That will complete the renovations for the second bedroom, which my wife uses as a combination office and sewing room. She still uses the sewing machine we bought from Sears the day we got married (which will be 43 years ago come July). I don’t think they make parts for that steam engine model anymore.

It certainly is delightful to be able to code without incessant interruptions and construction noise 5-6 days a week.

Bugs
My record keeping of reported bugs remains up-to-date.

During the month there were many versions released to the beta testers and most of them were also made available as Open Betas. Version 1.1.9.2 is currently in the hands of Matrix Games to make available as an official update. That resolves almost all of the Supply bugs. I have a few additional ones for Supply that need my attention (I’ve fixed a couple of them since uploading 1.1.9.2). But those corrections won’t become available in an official release until first going through beta testing and Open Beta testing.

I’m presently working on version 1.2.0.0, which, besides including the last Supply bug fixes, is focused on correctly problems in Production Planning. I did take the time to fix a few bugs in the Conquest phase over the weekend. Those had to do with relocating units belonging to neutral major powers that were in a conquered country (e.g., Japanese units in Persia when the USSR conquers Persia, while not at war with Japan. Again, those changes need to go through additional testing before becoming available as an official release.

Missing Optional Rules & Half Map Scenarios

Nothing new in May.

AI Opponent
Nothing new in May.


< Message edited by Shannon V. OKeets -- 6/3/2014 3:36:31 AM >


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 51
RE: MWIF Monthly Reports - 7/2/2014 11:36:32 PM   
Shannon V. OKeets

 

Posts: 18180
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
July 2, 2014 Status Report for Matrix Games’ MWIF Forum

Bugs
My record keeping of reported bugs remains up-to-date.

Version 1.1.9.2 was released as an official update in June. Likewise, version 1.2.0.2 was made available as a public beta in June.

Version 1.2.0.6 is currently in the hands of the beta testers and if they do not report - before the end of today (Tuesday, July 2nd) - any new problems created by that version, I’ll upload version 1.2.0.7 (same as 1.2.0.6 but with debugging disabled) for Matrix Games to make available as a Public Beta. This process of having new versions go through testing by the beta testers, followed by a Public Beta, and only then an official release, takes more time, but avoids the mess created when a new version causes significant new problems. When a public beta performs well for about a week, it then becomes an official release.

Because this is a short week in the US (4th of July holiday on Friday), Matrix Games might not be able to make 1.2.0.7 available as a public beta before the weekend. If that happens, then I’ll do more work over the rest of this week and weekend with the result that the public beta version will be numbered 1.2.1.0 and made available early next week (e.g., July 7th - 9th).

This past month I worked almost exclusively on problems with Production and Production Planning. For the former, the issues were primarily with Saved Build Points. I had to go down to the fundamental ‘object’ definition of Build Points (two types: saved and newly created) and modify some of those methods/functions. At the start of Production the program goes through all the hexes containing saved build points and determines how many can be used in production. It’s possible to store 4 build points in a hex containing only a port (e.g., Plymouth), but only 1 saved build point can be recovered from that hex for use in each Production phase. What the program does is take the maximum number of usable saved build points from each hex and leaves any excess on the map. For this example, the number of saved build points in Plymouth would be reduced from 4 to 3 while the number of build points the Commonwealth would have available for production would be increased by 1.

The difficulty I had with getting all of this to work was that build points may be part of trade agreements. That necessitates calculating the number of build points for each major power at the start of the Production phase. If a major power doesn’t have enough build points to fulfill a trade agreement, then that has to be detected and recorded. In performing those calculations, the program removes build points from the map, which made the calculation of available build points wrong later in the Production phase. That is, only Germany, which was doing Production first, was able to recover saved build points. By the time other major powers got to do Production, their saved build points had already been removed from the map. The obvious solution was to record all saved build points at the beginning of the phase and use the recorded amounts later in the phase, instead of dynamically recalculating the number of saved build points for each major power. As often happens, these changes, which required new variables to be created, meant saved game files (GAM) had to store and retrieve values for new variables. More code had to be changed and tested. That was essential for games that are saved in the middle of the Production phase.

The hassle with Saved Build Points is typical of the problems I work on these days. After running a saved game that displays a problem, next I have to refresh my memory on all the pertinent rule particulars. Then I read through the corresponding code, and if nothing obvious jumps out at me, I run the saved game again with debug statements displayed in the relevant code segments. That lets me see what the program is doing. Having fault isolated the problem, I then need to devise a solution, code it, and test that is solves the problem. The testing is not just a single run of the saved game. There have to be other runs starting farther in advance in the sequence of play and continuing on to phases well past the point where the new code executes.

At this point I have no remaining bugs related to the Production phase (building Militia and convoys now work correctly under all circumstances). There are two or three Supply bugs that have been reported and confirmed by the beta testers as serious. I need to get to them next.

But before the Supply reports came in, I fixed some of the more egregious bugs in Production Planning. Those concerned: (1) players being able to use sea areas in overseas resource routes that were valid in a previous turn but no longer valid, (2) fulfilling overseas trade agreements which contained build points, (3) displaying overland resource routes in Barbarossa, and (4) sending the Japanese build point to the US.

I also got around to fixing the code for repairing Blue factories. There is still a problem with damaging and repairing Red factories, but I need some fresh saved games for figuring out what is going wrong with that section of code. For July, my task list is to fix the remaining Supply and Production Planning bugs, then move on to fixing the naval movement and combat bugs.

Missing Optional Rules & Half Map Scenarios
Nothing new in June.

AI Opponent
Nothing new in June.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 52
Page:   <<   < prev  1 [2]
All Forums >> [New Releases from Matrix Games] >> World in Flames >> RE: MWIF Monthly Reports Page: <<   < prev  1 [2]
Jump to:





New Messages No New Messages
Hot Topic w/ New Messages Hot Topic w/o New Messages
Locked w/ New Messages Locked w/o New Messages
 Post New Thread
 Reply to Message
 Post New Poll
 Submit Vote
 Delete My Own Post
 Delete My Own Thread
 Rate Posts


Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

0.191