Matrix Games Forums

 Forums  Register  Login  Photo Gallery  Member List  Search  Calendars  FAQ 

My Profile  Inbox  Address Book  My Subscription  My Forums  Log Out

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 >> MWIF Monthly Reports Page: [1] 2 3 4 5   next >   >>
Login
Message << Older Topic   Newer Topic >>
MWIF Monthly Reports - 4/3/2010 2:44:41 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		April 2, 2010 Status Report for Matrix Games’ MWIF Forum


Accomplishments of March 2010

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

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

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

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

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

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

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

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

Scenarios and Optional Rules
Nothing new.

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

Player Interface
Fixed some bugs in the Victory form.

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new.

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

Historical Video, Music, and Sound Effects
Nothing new.

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

Communications
Nothing new.


< Message edited by Shannon V. OKeets -- 9/3/2012 8:38:32 PM >

_____________________________

Steve

Perfection is an elusive goal.
Post #: 1
RE: MWIF Monthly Reports - 5/3/2010 7:31:08 PM   
Shannon V. OKeets

 

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


Accomplishments of April 2010

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

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

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

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

Saved Games
Nothing new.

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

Scenarios and Optional Rules
Nothing new.

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

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

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

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

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

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

Here is the processing sequence for determining supply for all units on the map:
// ****************************************************************************
// UnitMenuTraceSupply.
// ****************************************************************************
// Step 1: find all valid supply sources for major powers and minors.
// ****************************************************************************
IdentifyMajorPowersSupplySources;
IdentifyMinorsSupplySources;
// ****************************************************************************
// Step 2: find all valid secondary supply sources that do not go overseas.
// ****************************************************************************
IdentifyMajorPowersValidSecondarySupplySources;
IdentifyMinorsValidSecondarySupplySources;
// ****************************************************************************
// Steps 3 and 4: initialize the sea area supply sources and identify all the
// sea areas that can be used by major powers and minors to trace supply to a
// primary supply source, by either a Basic (3rd step) or Rail (4th step) path.
// ****************************************************************************
InitializeSeaAreaSupply;
IdentifySeaAreasSupply(True);
// ****************************************************************************
// Step 5: identify all the secondary supply sources for both major powers and
// minors that can trace to a primary via an overseas Basic or Rail path. This
// search doesn't care what the path type is.
// ****************************************************************************
IdentifyMajorPowersOverseasSecondary;
IdentifyMinorsOverseasSecondary;
// ****************************************************************************
// Step 6: identify all the tertiary supply sources that do not go overseas.
// ****************************************************************************
IdentifyMajorPowersValidTertiarySupplySources;
IdentifyMinorsValidTertiarySupplySources;
// ****************************************************************************
// Step 7: identify all the sea areas that can be used by major powers and
// minors to trace supply to ANY supply source (which didn't become a valid
// supply source by going overseas), via a Basic path.
// ****************************************************************************
IdentifySeaAreasSupply(False);
// ****************************************************************************
// Step 8: identify all the tertiary supply sources that go overseas.
// ****************************************************************************
IdentifyMajorPowersOverseasTertiary;
IdentifyMinorsOverseasTertiary;
// ****************************************************************************
// Step 9: determine supply for all units,
// ****************************************************************************
TraceUnitSupply;
My general strategy here is to determine not only supply for each unit but to also record the supply path the unit used when it last traced supply. When supply has to be redetermined, each unit will first check to see if the path it used last time is still valid. If so, there is no need do a new search for a supply path for that unit. I record each supply path as a series of links (e.g., from unit to HQ to primary supply city). Then I also record which units are using which links. This enables the AIO to immediately know which supply links are being most heavily used: for defense and for offense. I’ve created a form so players can monitor this too (see below).

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

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

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new.

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

Historical Video, Music, and Sound Effects
Nothing new.

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

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

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

Communications
Nothing new.


_____________________________

Steve

(in reply to Shannon V. OKeets)
Post #: 2
RE: MWIF Monthly Reports - 6/5/2010 10:03:35 PM   
Shannon V. OKeets

 

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


Accomplishments of May 2010

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

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

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

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

Saved Games
Nothing new.

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

Scenarios and Optional Rules
Nothing new.

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

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

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

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

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new.

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

Historical Video, Music, and Sound Effects
Nothing new.

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

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

My involvement in the fan site remains close to nil.

Communications
Nothing new.


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 3
RE: MWIF Monthly Reports - 7/2/2010 2:26:49 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		July 1, 2010 Status Report for Matrix Games’ MWIF Forum


Accomplishments of June 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

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

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

Historical Video, Music, and Sound Effects
Nothing new.

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

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


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 4
RE: MWIF Monthly Reports - 8/1/2010 9:16:42 PM   
Shannon V. OKeets

 

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


Accomplishments of July 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

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

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

Historical Video, Music, and Sound Effects
Nothing new.

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

Communications
Nothing especially new.

===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 5
RE: MWIF Monthly Reports - 9/1/2010 8:10:13 AM   
Shannon V. OKeets

 

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


Accomplishments of August 2010

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

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

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

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

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

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

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

Scenarios and Optional Rules
Nothing new.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

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

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

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
The MWIF fan site still looks good.

Communications
Nothing especially new.



< Message edited by Shannon V. OKeets -- 9/1/2010 8:12:12 AM >

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 6
RE: MWIF Monthly Reports - 10/1/2010 10:15:49 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		October 1, 2010 Status Report for Matrix Games’ MWIF Forum


Accomplishments of September 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
The MWIF fan site still looks good.

Communications
Nothing especially new.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 7
RE: MWIF Monthly Reports - 11/1/2010 4:20:47 AM   
Shannon V. OKeets

 

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

Accomplishments of October 2010


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

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

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

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

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
The MWIF fan site still looks very good.

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

Communications
Nothing new (that can be reported).





Attachment (1)

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 8
RE: MWIF Monthly Reports - 12/2/2010 10:40:37 PM   
Shannon V. OKeets

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Scenarios and Optional Rules
Nothing new here.

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

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

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

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

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

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

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

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

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

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

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

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

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

Historical Video, Music, and Sound Effects
Nothing new.

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

Communications
Nothing new.

=========================== 
// ****************************************************************************
function UFilterSearchAndSeizure(const U: TUnit): Boolean;
// ****************************************************************************
// •	you must have an SCS, CV, or SUB in the sea area;
// ****************************************************************************
begin
  Result := (MajPower(U) = UFMajorCountry) and
            (U.UnitType in [utCarrier, utLightCarrier, utBattleship, utCruiser,
                            utLightCruiser, utAuxiliaryCruiser, utASWEscort,
                            utASWCarrier, utSubmarine]);
end;
// ****************************************************************************
function UFilterSearchAndSeizurePrevention(const U: TUnit): Boolean;
// ****************************************************************************
// •	there must not be an SCS, CV, or aircraft unit with an air-to-sea factor,
//    controlled by a major power with which you are at war in the sea area (nor
//    a US unit that can escort there because of US entry options 11, 20, 29,
//    38, or 50 ~ see RAC 13.3.2).
// ****************************************************************************
var
  Surface: Boolean;
  NavAir: Boolean;
begin
  Surface := (U.UnitType in [utCarrier, utLightCarrier, utBattleship, utCruiser,
                             utLightCruiser, utAuxiliaryCruiser, utASWEscort,
                             utASWCarrier]);
  NavAir := (U.UnitType in AirUnitSet) and
            (TAirUnit(U).AirSea > 0) and
            (U.TransportedBy = nil);
  Result := (UFMajorCountry.Relations[U.Country] = crWar) and
            (Surface or NavAir);

  if Result then Exit;
// ****************************************************************************
// Check for US entry option exceptions.
// ****************************************************************************
  Result := (UFMajorCountry.Relations[U.Country] <> crWar) and
            (UFMajorCountry.Side = sdAxis) and
            (UFConvoyMajPow = UnitedStates) and
            (MajPower(U) = UnitedStates) and
            (Surface or
             (NavAir and						
              USEntry.OptionChosen(useAirEscort))) and
// ****************************************************************************
// If unrestricted naval warfare has been declared, then all US combat units in
// any section box in all sea areas prevent search and seizure.
// ****************************************************************************
            (USEntry.OptionChosen(useUnrestricted) or
             ((U.Section = 0) and
// ****************************************************************************
// If Arm Merchantmen has been declared, then US combat units in the zero
// section box of any sea area prevent search and seizure.
// ****************************************************************************
              (USEntry.OptionChosen(useArmMerchantmen) or
               (USEntry.OptionChosen(useNorthAtlanticEscorts) and
                (UFSeaArea in [EastCoast, NorthAtlantic, CaribbeanSea])) or
               (USEntry.OptionChosen(useEastCoastEscorts) and
                (UFSeaArea in [EastCoast, CaribbeanSea])))));
end;


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 9
RE: MWIF Monthly Reports - 1/1/2011 6:22:43 PM   
Shannon V. OKeets

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Internet - NetPlay
From Mitchell (edited by Steve):

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

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

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

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

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

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

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

Artificial Intelligence (AI)
Nothing new.

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

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

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Paul is now the administrator for the fan site.

Communications
Nothing new.

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

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

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

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

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

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

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

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

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

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

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

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





Attachment (1)

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 10
RE: MWIF Monthly Reports - 2/1/2011 10:56:58 PM   
Shannon V. OKeets

 

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


Accomplishments of January 2011


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

There are 125 bugs remaining for basic solitaire play.

Rolf and Matt have joined the programming team and are getting up to speed on how the game plays. Rolf will be working with Mitchell on Pascal code for NetPlay and the AIO. Matt will be working with Peter on AI Opponent scripts, which are written in LAIO. You’ll find more information on these under NetPlay and AIO below.

From Mitchell:
As I continue to learn my way around the MWIF code base Steve has asked that I first focus on three areas: (1) tracking down and fixing the cause of the delays occurring when changing Major Powers, (2) get NetPlay working to support multi-player beta testing of MWIF, (3) collaborate with Rolf to finish the AIO parser.

My availability in January was negatively impacted by a two week business trip abroad, leaving me precious little time to sink my teeth into the items Steve has me looking at. However, I did manage to make some progress in each these three areas [see the “From Mitchell” paragraphs below]. I look forward to a much freer schedule throughout February and a corresponding increase in my productivity with respect to MWIF.

Hardware and Software
From Mitchell:
Note that Theme Engine is a third-party component library use in MWIF to manage the color schemes and other screen elements associated with each major power.

The delay experienced when switching major power appears related to the mechanism used by the Theme Engine library to communicate the potential need for individual screen elements to repaint themselves. Theme Engine employs a Windows message broadcast model that is apparently less specific that it could be, which causes hundreds or even thousands of Windows elements to be unnecessarily queried and processed with each change of theme. For example, it examines all components in all applications that are running (e.g., word processing, spreadsheet). Fixing this will require us to subclass and tailor Theme Engine to better suit the needs of MWIF, which should not be a problem, but first we have to determine exactly where to make the needed changes. Even without the shortcomings of the Delphi debugger, issues like this are difficult to trace. Essentially, one needs to step through the executing code line by line as each Windows element is processed, which is a tedious and time consuming process. We are working through it, though, and gradually bracketing the list of components that actually need to respond to the Theme Engine broadcasts so the others can be skipped.

Beta Testing
I released versions 7.01.02 (16 fixes), 7.01.03 (14 fixes), 7.01.04 (11 fixes), 7.01.05 (3 fixes), 7.01.06 (12 fixes), 7.01.07 (27 fixes), 7.02.00 (20 fixes), 7.02.01 (17 fixes), 7.02.02 ( 23 fixes), and 7.02.03 (25 fixes), to the beta testers last month. This totals 10 new versions and 168 fixes, which is 40% above average for fixes. I changed the numbering to 7.02.00 because the patch count reached 7 for 7.01. The next version will be 7.03.00 so there will be a full new version to accompany a complete source code upload for Rolf.

Fatal errors still occur and some remain inexplicable, although I solve some of them every month. Most of the bug reports are related to recent changes. There are so many interconnections in the WIF rules and corresponding MWIF code that try as I might it is difficult to anticipate all the repercussions of even small changes.

One thorny area has been naval air combat. That is the nexus of numerous rules: DOW surprise, spending search rolls surprise points, air-to-air combat, multiple rounds of air-to-air combat, antiaircraft fire, aborting air units from air-to-air combat and antiaircraft fire, naval combat results, multiple naval combat rounds, aborting naval units from naval combat, and interception of naval units aborting from naval combat. Throw in land based air units and carrier air units which can either be printed or temporary carrier air units representing each carrier, and you have a lot of detailed steps. For instance, if a printed carrier air unit is destroyed, then it just goes into the force pool. But if a temporary carrier air unit is destroyed, then its parent carrier becomes damaged. All carrier air units also need to be assigned roles as either fighters or bombers for each round of naval combat, although their roles do not change within an air-to-air combat.

I’m working my way through that code but it is difficult enough just to set up the saved games needed to test everything. Nonetheless, I have reduced the number of bugs for Naval Movement and Naval Combat from 59 (28 + 31) as of December to 21 (6 + 15) as of today.

Saved Games
Saving and restoring games is stable.

Map and Units
Rob continues to send me updates of the naval unit writeups.

Scenarios and Optional Rules
I fixed a few bugs related to setting up partisan units behind enemy lines after all the major powers have been set up. This was a tricky subphase of the Setup phase. It needs to perform a preparatory check to see if there is enough room for the units to be placed on the map. If the occupying major power positions his units well, he can sometimes cover all possible placement locations with enemy zones of control. That results in no partisan units being capable of setting up.

MWIF Game Engine and CWIF Conversion
Solved all outstanding bugs related to land combat. I still need to add an additional subphase at the end of the processing sequence for disorganizing units. Presently that is done when combat results are applied. It should occur following the Advance After Combat subphase. I also corrected most of the bugs related to land movement. What remains to be done for that phase pertains to imposing restrictions on undoing moves that affect supply status so players can not ‘cheat’.

I killed off the bugs related to creating Vichy France. As part of that I created a small new form so the Vichy France controller can allocate countries that were aligned or conquered by France to Axis major powers. There are still some small changes that I need to make based on my better understanding of those rules. But the main task of getting the creation of Vichy France to flow from start to finish is done. I must of run the opening segments over a hundred times this month. As I did that I found many small improvements to make to their efficiency and clarity. As a simple example, when a unit has to be moved to the nearest hex, the program now identifies exactly which hex is nearest. There might be several, but providing the first one enables the player to get the general idea of where to look for others. I thought about providing the full list but decided the pain of coding that wasn’t worth the gain.

As part of my quest to fix all problems with Vichy France I rechecked the code for making Vichy hostile and collapsing Vichy. There was a least 1 serious problem regarding the latter.

Here is the new sub-subphase sequence of play for determining country and hex control at the start of the Vichy creation:
• Dice are rolled for all the Vichy Groups and each is assigned to either Free or Vichy France.
• Each country France has conquered is aligned to an Axis major power (if the die rolls indicate that it belongs to the Axis).
• Each country France has aligned since the start of the war is conquered by an Axis major power (if the die rolls say so).
• After all the new alignments and conquests have occurred, units are rebased - if any need to be. These are handled as ‘overrun' digressions.

I rewrote most of the code related to transported units. I was having a devil of a time trying to debug that. In fact I still have one item left to correct during the Return to Base phases. The new data structure enables me to find and fix bugs in a fraction of the time it use to require.

I replaced a CWIF component for grids (TSimpleGrid) with one from the JEDI library (TJvStringGrid). The former was generating program crashes when the mouse wheel was touched while the grid was displayed. There were nine uses of TSimpleGrid and it took me almost a full day to make the substitutions. Visually there is no apparent difference. But TJvStringGrid does not crash the program, so the time and effort were worthwhile. I have now standardized on the use of TJvStringGrid throughout MWIF; it appears in 85 places.

Player Interface
Modified the OverStacked form and reset where in the code the checks for overstacking occur. I need to add one more check at the end of the land movement phase for overstacked air units that have been deserted by an HQ or engineer that had previously provided a stacking bonus.

Imposed a restriction on moving land units so you are no longer able to partially move a unit, move a second unit, and then go back and continue moving the first unit. Doing this would violate the WIF rules. However, you are permitted to continue moving a stack of units that performed an overrun if you do so immediately after any overrun air and/or naval units have finished rebasing.

Corrected a few small error in the Selectable Units form (e.g., the Help button didn’t work). Almost all the forms are the way I want them. Exceptions are the PBEM and NetPlay forms which either need to be created or undergo heavy use to identify any rough edges.

Internet - NetPlay
After Mitchell transfers the code from the stand alone test program for NetPlay into the main MWIF program, he’ll be working on testing it there. To help out, Rolf has joined us and together they need to convert the Windows messaging system that CWIF used to Game Record Logs. I have done about 2/3rds of that work already and there are slightly less than 100 GRLs to implement. I’m not sure how fast that work will go but it could take as little as a month or as much as 2 months to put in the basics. Then the real work begins with having multiple players on different computers test playing a game over the internet.

From Mitchell:
I am building a class wrapper around suitable Indy components to facilitate integration of NetPlay into MWIF. The idea is to encapsulate the TCP and PBEM functions needed to support multi-player testing, exposing methods that make it simple for the main MWIF code to pass the Game Record Log structures it is already programmed to build. I am nearly finished with a new version of the NetPlayComTest utility designed to test the new NetPlay class. I had hoped to get this out to the beta testers before my trip but I simply ran out of time. I now plan to finish it this week.

PBEM
Once Mitchell gets the NetPlay communications working, he’ll do the same for the PBEM communications. This should be a lot easier than the NetPlay code, partially because Mitchell has previously created PBEM applications (although not for games).

Artificial Intelligence (AI)
Peter is anxious to write more scripts and test the ones he has already completed. The latter are for setting up minor country units when they enter the war. I think he has a script for each minor country at this point. There are a lot of small decisions in WIF and I’ve set up the AIO decision making so each one is a separate decision point. The task is to work out the process for how the AIO should make each decision and then write it up as a LAIO (Language for an AI Opponent) script.

Matt should be a great help on this. I find that everyone contributes new insights into what needs to be done for the AIO and how to accomplish it.

From Mitchell:
I studied the AIO language and a few of the scripts. Finishing the LAIO parser should not be too difficult but I have yet to coordinate with Rolf to get started - will do so next.

Player’s Manual
I updated the Players Manual with a few small changes. However, I have several other additions and edits to make that I am delaying until the bugs in the sequence of play code are ironed out.

Tutorials, Training Videos, and Context Sensitive Help
Made some changes to the context sensitive help messages based on feedback from the beta testers.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Paul is the administrator for the fan site. He has offered to set up Rolf and Matt with access so they can review and comment on it.

Communications
Nothing new.


_____________________________

Steve

Perfection is an elusive goal.

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

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		March 1, 2011 Status Report for Matrix Games’ MWIF Forum

Accomplishments of February 2011

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Nothing new.

Communications
Nothing new.


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 12
RE: MWIF Monthly Reports - 4/2/2011 12:38:51 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		April 1, 2011 Status Report for Matrix Games’ MWIF Forum
Accomplishments of March 2011

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PBEM
Nothing new.

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

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

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

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

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

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

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

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Nothing new.

Communications
Nothing new.



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

< Message edited by Shannon V. OKeets -- 4/2/2011 9:51:30 PM >

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 13
RE: MWIF Monthly Reports - 5/2/2011 7:52:40 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		May 1, 2011 Status Report for Matrix Games’ MWIF Forum

Accomplishments of April 2011

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

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

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

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

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

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

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

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

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

Saved Games
Nothing new.

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

Scenarios and Optional Rules
Nothing new.

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

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

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

PBEM
Nothing new.

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

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

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

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

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Nothing new.

Communications
Nothing new.



Changes Since Versions 08.01.00
(as of April 8, 2011)
(1) I fixed the FTC problem with moving a minor country HQ into a minor country aligned to the same side (Michael, 7.01.03, Post #14; Michael, 8.01.00, Post #1).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Changes Since Versions 08.01.01 & 8.01.02
(as of April 10, 2011)
(1) Corrected the Theme Engine background colors when restoring a saved game (Peter, 8.01.01, Post #1).

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Changes Since Versions 08.01.04
(as of April 17, 2011)
(1) Fixed the problem with modifying trade agreements not working (Lars, 8.01.04, Post #3).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Changes Since Versions 08.01.05
(as of April 24, 2011)
(1) Added code to destroy all transported units when a naval unit is destroyed (Lars, 2.01.04, Post #46).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Changes Since Versions 08.01.06
(as of April 27, 2011)
(1) Added a line of code so Partisan units do not show up in the Scrappable list (Lars, 8.01.05, Post #115).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Changes Since Versions 08.01.07
(as of April 29, 2011)
(1) Added a check for no assigned destination when saving oil during Production Planning. This prevents a MadExcept error (Aaron, 8.01.06, emailed bug report #37).

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

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

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

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

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

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

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

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

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

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

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

Changes Since Versions 08.02.00
(as of April 30, 2011)
(1) Added some more checks to Flyouts to avoid MadExcept errors (Michael, 8.02.00, emailed bug report).

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

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

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

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

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

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

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

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

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

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 14
RE: MWIF Monthly Reports - 6/2/2011 8:30:07 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		June 1, 2011 Status Report for Matrix Games’ MWIF Forum


Accomplishments of May 2011


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

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

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

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

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

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

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

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

MWIF Game Engine and CWIF Conversion
Set NetPlay below.

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

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

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

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

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

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

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

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

PBEM
Nothing new.

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

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

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

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

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Nothing new.

Communications
Nothing new.


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 15
RE: MWIF Monthly Reports - 7/1/2011 6:34:23 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		July 1, 2011 Status Report for Matrix Games’ MWIF Forum

Accomplishments of June 2011

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

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

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

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

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

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

Saved Games
Nothing new.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PBEM
Nothing new.

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

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

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

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

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

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

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

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

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

Marketing
Nothing new.

Communications
Nothing new.

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

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

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

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

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

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 16
RE: MWIF Monthly Reports - 8/2/2011 8:44:33 AM   
Shannon V. OKeets

 

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


Accomplishments of July 2011


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

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

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

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

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

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

Saved Games
Nothing new.

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

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

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

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

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

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

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

PBEM
Nothing new.

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

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

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

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

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

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

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

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

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

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

Communications
Nothing new.


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 17
RE: MWIF Monthly Reports - 9/2/2011 4:34:51 AM   
Shannon V. OKeets

 

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


Accomplishments of August 2011

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Player Interface
Nothing new.

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

PBEM
Nothing new.

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

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

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

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

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

Communications
Nothing new.


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 18
RE: MWIF Monthly Reports - 10/2/2011 6:00:02 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		October 1, 2011 Status Report for Matrix Games’ MWIF Forum


Accomplishments of September 2011

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PBEM
Nothing new.

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

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

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

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

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

Communications
Nothing new.


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 19
RE: MWIF Monthly Reports - 11/2/2011 3:08:13 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		November 1, 2011 Status Report for Matrix Games’ MWIF Forum
Accomplishments of October 2011

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PBEM
Nothing new.

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

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

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

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

Marketing
Nothing new.

Communications
Nothing new.



Sound Effects for MWIF

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

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

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

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

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

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 20
RE: MWIF Monthly Reports - 12/3/2011 2:00:10 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		December 1, 2011 Status Report for Matrix Games’ MWIF Forum
Accomplishments of November 2011

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

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

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

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

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

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

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

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

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

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

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

Scenarios and Optional Rules
Nothing new.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The advantages of this algorithm are several:

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

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

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

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

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

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

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

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

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

PBEM
Nothing new.

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

Player’s Manual
I have a handful of small edits waiting the Matrix Games editor. He should begin working on the Players Manual and the Rules as Coded documents this week.

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

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Nothing new.

Communications
Nothing new.





Attachment (1)

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 21
RE: MWIF Monthly Reports - 1/2/2012 8:11:36 PM   
Shannon V. OKeets

 

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

Here is 2011 in review.

Accomplishments of 2011

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

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

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

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

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

The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file). In my opinion, neither of these is important. Theme Engine is the software library I use to transform all the forms and buttons into something other than the bland gray backgrounds and images that are the Microsoft defaults. Early in the year I converted the Main from standard Windows style to Theme Engine. So, aside from the just mentioned two problems, Theme Engine is now in use for all 160+ forms and runs cleanly under Win XP, Vista, and Win 7.

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

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

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

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

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

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

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

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

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

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

In July (I think) I added code to enable the beta testers to change many of the optional rule settings on-the-fly. This will not be part of the released product but it gives the beta testers another tool when setting up saved games for testing how the game performs with various optional rules On/Off.

Saved Games
Saving and restoring games was stable throughout the year. I added the name of the current major power to the label for automatically saved games during 10 additional phases. This makes it possible to restore a game to a more precise point in the sequence of play.

Michael created 5 Fast Start saved games. Many people like to jump into a new computer game as soon as it is installed, picking up the rules as they go. To facilitate this, MWIF comes with Fast Start saved games for 5 of the most commonly played scenarios: Barbarossa, Guadalcanal, Fascist Tide, Global War, and Missed the Bus. All the Fast Start games use the solitaire mode of play and the Novice set of optional rules. The Fast Start games begin at the first major decision of the scenario. For instance, Barbarossa starts with Germany deciding whether to align Hungary or Finland.

Starting in August, Aaron began building a large library of saved games for testing the numerous phases in the sequence of play. Of course this is complicated by the number of different scenarios and optional rules, as well as modes of play (e.g., solitaire, head-to-head, NetPlay). But with the help of many other beta testers, he generated a large library of saved games. From my perspective, the best part of this are the saved games related to specific bugs. Those let me immediately reproduce bugs so I can both fix them and prove to myself that my changes work.

Map and Units
The data and graphics for the map and units were mostly unchanged in 2011. I added a graphic to visually indicate when captured red factories are not producing. I still need to figure out how to indicate visually that a factory has lost a production point. There was a small data correction for a couple of City Based Volunteer units.

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

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

Fascist Tide and Day of Infamy
These are the two half-map scenarios. For each scenario I made half the sea areas illegal to enter. For instance, when playing Fascist Tide (the war in Europe), entering the Indian and Pacific Oceans is not permitted. I also made corrections for the rules uniquely associated with the half map scenarios. In particular, I intend to use the Azanian Sea (for Fascist Tide) and the Eastern Med (for Day of Infamy) as holding areas for the “Transfer Pool”. This way when a naval combat has to occur in the Transfer Pool, the players will be able to see the units therein just as for any other naval combat.

The victory cities for these scenarios are now correct and so are the lists of which countries are legal. I fixed a couple of bugs when setting up Day of Infamy: New Caledonia now goes to Free France and Vichy France gets French Polynesia and aligns Madagascar. Japan is then able to align Madagascar as long as Madagascar is controlled by Vichy France. What was so difficult about getting this code correct (almost a full day) was that Vichy France doesn't officially exist in the scenario. I still need to add code for the external/European event of Germany collapsing Vichy France so it occurs at a fixed point in the game.

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

Warlords
I fixed all reported bugs related to Warlords.

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

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

Convoys in Flames
This is difficult to code because it has so many pieces. I’ve added the code for the +2 penalty when trying to intercept auxiliary cruisers. That was a bear to get correct because of the complexity of search roll modifiers and search numbers. I changed the production form selection of repaired Auxiliary Cruisers so which one is repaired is randomly selected. In all other cases, the player can choose which naval unit to repair.

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

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

Kamikazes
This optional rule requires a tailored variation of the ubiquitous Unit Dialog form. For instance, when the Japanese player chooses whether his naval air bombers are flying as kamikazes, a Unit Dialog form appears listing all the bombers so the player can select which ones should wear head scarves.

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

Rough Seas
No work done towards this in 2011.

Naval Supply Unit
No work done towards this in 2011.

Rules Precision (a.k.a. MWIF Game Engine and CWIF Conversion)
In the beginning of the year I spent a lot of time trying to debug the code for naval movement and naval combat. That became so tedious that I stepped back and revised the code for the internal record formats to determine into which sea areas/ports the units-in-hand can move. That is, once you select a group of naval units to be moved, the program has to check each hex the cursor moves over to determine if it is a viable destination. CWIF used the same record layouts for air rebases, all land unit moves, and all naval moves. I split those into 3 different record types (air, land, naval) since different information was needed for each record type. That let me clarify the names of the fields in each record so they explain the data better. The changes for the air and land moves had zero effect - since they effectively were just cosmetic. My main motivation was to make it easier to debug the naval movement code. I

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

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

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

I added some new code for the factory destruction phase. That was a little tricky because there are rarely occasions when a player wants to destroy his own blue factories. The two that come up are: France destroying a factory in Vichy France before Vichy France is declared, and the USSR destroying a factory in the Ukraine before Germany declares the Ukraine as a separate country. Most of the time the program ‘knows’ that destroying your own blue factories is senseless and can skip the phase completely.

At one point I had killed off most of the bugs related to creating Vichy France. In doing so I created a small new form so the Vichy France controller can allocate countries that were aligned or conquered by France to Axis major powers. But then Rob went through the rules about Vichy line by line and word by word. In November he found 17 more bugs related to Vichy, that are a lump in my task list.

As you can tell from the following, many of the ‘bugs’ reported by the beta testers in the last 4 months of the year were due to them either: (1) rigorously testing how the program performs under a variety of obscure circumstances, or (2) going through the rules with a fine tooth comb. I made changes for:
• Imposing a setup restriction on the Communist Chinese units so they have to be within 9 hexes of a Communist controlled city. This number of hexes is greater than what is stated in WIF FE because of the MWIF change in scale for China.
• Overrun naval units in iced-in ports, although having rolled well and being permitted to escape, are instead destroyed.
• Which major power decides about continuing to fight or abort from a naval combat is redetermined at the end of each round, and is decided by the major power on each side that has the most units still capable of fighting in the sea area.
• The WIF FE rules weren’t clear as what should happen when the Collapse of Vichy France causes Vichy France controlled minor countries to become owned by an Axis major power which has a unit present in the minor country. For instance, if Italy has a unit in Tunisia (which is controlled by Vichy France), then the rules state that Tunisia goes to Italy. But the rules say nothing about if there are both German and Italian units present. I decided to count the number of units and ‘give’ the country to the Axis major power with the most units present.
• Vichy France can be both hostile to and/or at war with Allied major powers. I revised the Relations form so those conditions are shown accurately.
• I fixed a bug in declaring Vichy France when non-French naval units are forced to rebase. This is the one place in the rules where ‘overrun’ naval units have to rebase to the nearest port, but can be intercepted when doing so. In all other cases the units either can not be intercepted, or else they have the freedom to choose any port within twice their range.
• I fixed a bug where liberating France while Vichy France still exists wasn’t converting all Metropolitan Vichy France hexes to French control.
• I fixed a bug so Vichy units can only move into hexes controlled by Vichy or by a country with which Vichy is at war.
• If France is liberated while Vichy France still exists, the major ports previously held by Vichy are undamaged when converted to French control. Usually when a major port changes control from one side to another, it becomes damaged. The problem this rule ‘interpretation’ avoids is having newly acquired French naval units overstacked in, say, Toulon.
• I added code so Vichy France can not build pilots or offensive chits.
• Minor country units are not permitted to enter the home country of another minor country on the same side unless Foreign Troop Commitment requirements have been met. That rule stops Hungarian units from entering Rumania, as one example. But in the case where the second minor country has been completely conquered, it seems that entry should be permitted. In one of the beta testers’ games the USSR had conquered Persia (which had been aligned to Japan) and then Italy aligned Iraq and had Iraqi units ready to enter and liberate Persia. Here the general rule would prohibit Iraqi units (minor country aligned to Italy) from entering Persia (minor country aligned to Japan, on the same side as Italy). But since Persia is completely conquered, it is now ‘owned’ by the USSR, with which Italy is at war, hence the Iraqi units are free to enter Persia. At least that is how I have coded it. My change is that if a minor country on your side has been completely conquered, then the FTC requirements no longer apply.
• Land units can now only be loaded on air transports if they are organized (Harry Rowland clarified this rule).
• I changed the code so when the US claims Greenland/Iceland/Northern Ireland, units belonging to other Allied countries therein are relocated to the nearest hex, rather than rebased. As part of claiming Northern Ireland, the US is permitted to place convoy reinforcements in Ireland - but not any other type of unit.
• I fixed a bug where the US was being permitted to DOW another major power after failing in an attempt to DOW a major power during the same impulse.
• When the US DOWs both Germany and Italy in the same impulse, two separate die rolls for US Entry are made. Furthermore, those die rolls and the associated mandatory movement of US Entry markers from the Entry Pool to the Tension Pool are made prior to the implementation of the optional movement of markers due to the automatic execution of US Entry Options. The automatic execution of US Entry Options only occurs if the US is at war with both Germany and Italy (or those countries have been completely conquered). This is another instance where Harry Rowland clarified the rule. There are a couple of more subtleties to this rule which are now coded correctly in MWIF.
• I implemented the following rule interpretation: Unit U is not permitted to fly to a naval combat sea area if:
(1) U's controlling major power is surprised by all the enemy units in the sea area, or
(2) all units friendly to U in the sea area are neutral or surprised [by all enemy units in the sea area].
• I fine tuned the code so land based air units that voluntarily abort from a naval air combat are handled differently from those that abort under any other circumstance. If they voluntarily abort from an air-to-air combat, then they return to the sea box section from which they entered the naval combat. If they otherwise abort, they must return to base (i.e., to a land hex) where they are disorganized.
• I removed the ability of land attacks being declared against a hex containing only enemy supply units.
• I enabled conducting ground strike and carpet bombing missions against a hex containing units with which you are not at war, if the hex is controlled by a country with which you are at war.
• AA units that fire during the ground support phase are not disorganized until after the Advance After Combat subphase.
• I fixed a bug where attacked partisan units were able to receive ground support from countries other than their controlling major power.
• I changed the test for conditions under which the Nazi-Soviet pact can be broken. Specifically, setting up or moving units within one of the countries listed for breaking the pact (e.g., Turkey, Sweden), no longer qualifies for breaking the pact, regardless of to whom the minor country is aligned. Basically, as long as the only units you move in the specified minor countries belong to the minor country itself, then the conditions for breaking the pact are not met. But if you move a unit from a different country into one of the listed minor countries, then the other side can break the pact. For example, if the USSR DOWs Turkey, which is then aligned to Germany, and Germany moves the Rumanian HQ into Turkey, then the USSR can break the pact. However, moving an Italian unit into Turkey would not affect the status of the pact, since Italian units are not controlled by Germany. This applies not only while setting up units, but throughout all phases of the game (e.g., including air units returning to base).
• When the US player has the option to move, or not to move, markers from the Entry Pools to the Tension Pools and there is more than one marker to be moved for an entry option, he has to either move all the markers for the entry option or none. The US player gets this choice when US Entry Options are made automatically after the US goes to war with Axis major powers.
• The requisite conditions have to be met before the US can occupy Greenland and Iceland even when that US Entry Option is ‘automatically’ selected due to the US going to war with both EuroAxis major powers.
• Allied units in Italy that count towards the conquest of Italy garrison value must be controlled by a country at war with Italy (clarification from Harry Rowland).

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

Player Interface
I created 6 new forms in 2011:
• Supply Sources and Paths. This identifies all the supply sources, primary and secondary, and shows how many units are being supplied by each. When you click on a supply source, the supplied units are shown in a list at the bottom of the form. For secondary supply sources, the supply path it uses to reach a primary is shown. Clicking on a unit image causes the supply path for the unit to appear. There is a special button for displaying all the units and secondary supply sources that are out of supply.
• Liberation. This tiny form simply asks a player if he wants to liberate, revert, or ‘neither’ when he controls the capital of a country that was on his side originally. The change here is to include the option to revert. Liberation of a minor country means it is aligned to its liberating major power. Reversion means it is aligned to the major power to whom it was originally aligned. If you do neither, then it is conquered by the major power controlling the capital. This is a ‘nag’ form, since if you choose neither, then you will be asked the same question again at the end of the next turn. I really dislike having ‘nag’ forms in the sequence of play but I couldn’t come up with another solution and remain true to WIF FE, where you can liberate/revert a minor country during any later turn if you so desire.
• US Entry Actions. This form is purely informational but I think compared to RAC it is a much cleaner presentation of the information. Hopefully having this accessible from within a game will make these concepts easier for new players to understand.
• Private NetPlay Forum. This form is used by players to find opponents for NetPlay (i.e., playing over the internet). It is only available to players who have purchased the game, and is accessed from the Opening MWIF screen. It is also used for each game session, letting players restart/join their game in progress.
• Keyboard and Mouse Commands Help.
• About the Current Game. This reports which scenario is being played, mode of play, and which players are playing. It is of minor importance for game play but is helpful for debugging purposes.

I substantially modified 7 existing forms:
• OverStacked. I revised where in the code checks for overstacking occur. When overstacking is detected, this form appears.
• Choose Naval Combat. The changes I made here give more emphasis to the list of sea areas. These modifications were part of a general revision of the form to fix a few bugs.
• Drop Off Units. The changes here clarified what happens when a group of naval units enters a port. It was easy to get confused when some of the naval units stopped in the port, while others in the moving group picked up cargo and continued moving.
• Select Units. The change was the addition of filters for movement points and range. For example, when examining a large stack of naval units, you can quickly select just those with 6 movement points. I also increased the size of the form so more units are visible.
• UnitData. This data summary panel now shows if a unit is flying a night mission and/or at extended range. This helps when returning air units to base after an air mission since now you know which ones flew at extended range. It also is of value when choosing targets in an air-to-air combat and for anti-aircraft fire.
• Status Indicators Help. This needed to be updated, especially the graphics, because it was a year out-of-date.
• Chat. CWIF had 3 forms for sending a message: Chat, New Message, and Recipients. I reduced that to a single form. The list of who receives a message isn’t very long, since is a maximum of 6 players in a game. The form now just has a checkbox for each player.

Within 9 minor forms I replaced a CWIF component for grids (TSimpleGrid) with one from the JEDI library (TJvStringGrid). The former was generating program crashes when the mouse wheel was touched while the grid was displayed. Visually there is no apparent difference. But TJvStringGrid does not crash the program, so the day I spent making the changes was well spent. I’ve now standardized on the use of TJvStringGrid throughout MWIF; it appears in 85 places.

I updated the Unit Status Indicators because there was a ‘hole’ in the design logic. Land based air units at sea during naval combat, which were not participating in the combat, were shown without any status indicator. I added a new value for these units to indicate that they are ‘flying’, even if they are not part of the naval combat. Another set of changes I made to the unit status indicators was to clarify when a unit was receiving HQ support and/or engineer support in a land combat. And to accompany the changes made to the UnitData panel mentioned above, I added indicators for units flying night missions and/or at extended range.

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

I imposed a restriction on moving land units so you are no longer able to partially move a unit, move a second unit, and then go back and continue moving the first unit. Doing this would violate the WIF rules. However, you are permitted to continue moving a stack of units that performed an overrun if you do so immediately after any overrun air and/or naval units have finished rebasing.

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

The number of unique record types is around 400, one for each decision/event that occurs in the sequence of play. That number will probably increase slightly once we get heavily into testing NetPlay. For example, there are a bunch of optional rules which will need their own personal GRLs (e.g., Guard Banner Armies, Kamikazes, and Naval Supply Units). On average, each conversion required about 50 edits, spanning a dozen different modules. Making those 20,000 edits was spread out over several years, since I knew they would be onerous to do and had been chipping away at them off and on since way back when. With Rolf’s help I was able to finally finish them off.

The conversions to GRLs were essential for NetPlay and PBEM (that is: whenever more than 1 computer is being used). The most difficult were for moving units, especially naval moves, because of all the information required to keep track of exactly which units are moving through which hexes to reach their destination. Another reason behind creating the GRLs is that I am a firm believe in compartmentalized software. The GRLs isolate and completely remove NetPlay and Message Control code from all the details of how the game/simulation operates. NetPlay gets a simple string value with an identifier (ID number). It then sends it to its twin on another computer. That the game being played is World in Flames never impinges on the NetPlay code. To be clear about this, the code for NetPlay and the code for the game’s simulation of WW II are mutually exclusive.

As stated at the beginning of this report, Mitchell completed NetPlayComTest, version 2.0 which I then integrated into MWIF. It can be called either as a stand alone program or from within MWIF when a game is in progress. For those of you who don’t know, NetPlayComTest uses Indy10 to send and receive messages over the internet. It deals with all the issues of establishing communications between two or more computers. Then it permits the users to send messages back and forth. Its original purpose was to test the software for use by MWIF proper. But it will be included in the released product so players can test their communication links without having to run the game itself. If as a player you get NetPlayComTest to work for communicating between all the players in your game, then MWIF should run NetPlay without problems. Some of the issues it needed to deal with are IP addresses, port numbers, and firewalls - all that good stuff.

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

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

Artificial Intelligence (AI)
Peter finished the geographic breakdown for the AI Opponent. To go with that, I revised the documentation on the AIO command structure so each element of the geography has a corresponding decision maker. There are 16 Theaters of Operation (TOs) that span the global map. Within each TO there is a breakdown for naval units into Sea Area Groups (which contain individual Sea Areas) and for land units into Areas of Operations (which contain Land Regions).

I changed the fundamental map data structure to include information on the geographical breakdown. This should have zero effect on game play as far as human players are concerned. The change to the Terrain data adds a new field to each land hex to store the Land Region ID #. Along with this I added a new field to the Sea Area data to store the Sea Area Group ID #. And as the final pieces, I created simple files listing the Theaters of Operation, Areas of Operation, Land Regions, and Sea Area Groups which hold the details on each of those elements, including cross references. In practice, this means that the AI Opponent code can trace any land hex back to its LR, AO, and TO, and can trace an all-sea hex back to its sea area, SAG, and TO. In order to validate the new data I added a (debug) line under the Main form that shows and updates the TO, AO, LR, and SAG values as the cursor is scrolled across each hex.

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

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

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

After completing the geographic breakdown of the entire global map (a massive task which required assessing all 70,200 hexes), Peter worked on the data structures for AIO strategic plans. I had already done some preliminary work on that. The goal is to design variables for holding all the information necessary to define a strategic plan for a major power. The 3 main elements are: (1) objectives to hold/take, (2) geographical areas to defend/attack, and (3) time lines for declarations of war/offensives, with accompanying production schedules.

Some of the strategic plan data defines conditions for when something should happen (e.g., when to start building garrison units). Defining data structures for conditionals is always difficult, but Peter and I already did some of that when we were working on setup scripts. It isn’t easy to take the amorphous advice provided by the forum members and render it into a rigidly structured outline for processing by a computer program. For instance, late in the year he was grinding out the precise conditions under which France should surrender.

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

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

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

I added a subsection on Dropping Off Units to the Players Manual. That form is used for both dropping off units and, when in port, picking up cargo while passing through. I reviewed and updated section 10 of the Players Manual so it accurately lists all the RAC deviations from Rules as Written (RAW).

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

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

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

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

I have a handful of small edits waiting the Matrix Games editor that I have accumulated since August 1st. There is only 1 glaring hole remaining in the text for the Players Manual: NetPlay instructions for starting, joining, and resuming a NetPlay game. There are a couple other bits associated with that too: chatting with other players and monitoring internet communication links.

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

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

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

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

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

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

Marketing
Aaron worked with Sean Drummy of Matrix Games on updating the World in Flames screenshots displayed as part of the game’s description in Matrix Games’ list of products. Virtually all of them had been out-of-date.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 22
RE: MWIF Monthly Reports - 2/3/2012 1:58:35 AM   
Shannon V. OKeets

 

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

Accomplishments of January 2012

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

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

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

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

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

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

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

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

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

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

Map, Units, and Scenarios
I fixed a couple of odd setup issues. But mostly this code remained intact.

Optional Rules
Nothing new.

Rules Precision
With the quasi-consent of the beta testers, I set the maximum production multiple for the US at 2.25. According to RAW it could get higher if the US enters the war early and the game goes past 1945. This limit prevents the US production from getting astonishingly high.

Player Interface
Private NetPlay Forum. This form is used by players to find opponents for NetPlay (i.e., playing over the internet). It is only available to players who have purchased the game, and is accessed from the Opening MWIF screen. It’s also used for each game session, letting players start/restart/join a game in progress. Because this form performs so many tasks, I split it into 5 layouts. This is a common design solution choice by me to deal with busy forms. The player simply clicks on one of the radio buttons in a list of 5 and the form is transformed into the selected layout.

Registration and posting a new request for Seeking Opponent are two of the layouts. The others are for: sending and receiving messages from other players, reviewing the post in the Seeking Opponent database, and reviewing games-in-progress. The last serves a second purpose: starting/restarting/joining a NetPlay game.

Internet - NetPlay
I did a lot of work on the World in Flames NetPlay Private Forum. The paragraphs that follow are from my current draft on the documentation for that. Following the text are screenshots of the Registration and New Post forms. All these sections currently work except for posting to the Seeking Opponent database. For that I need to get Indy10 Cookies to function correctly. I would welcome comments on my draft. This is complicated stuff and I would like the text to provide a lot of help for players who have no experience playing games over the internet.

Introduction
Matrix Games/Slitherine Games provides a dedicated server to host a private forum for World in Flames NetPlay games. Herein the abbreviation NPF is used to reference the NetPlay Private Forum. The purpose of NPF is to enable players to find opponents, chat with other players about NetPlay games, and begin NetPlay game sessions.

Besides the obvious advantage of encouraging the creation of a community of World in Flames internet players, the NPF also simplifies setting up an internet session by automating some technical details. For example, the players don’t need to type in their own or other players’ IP (Internet Protocol) addresses.

The NPF is only accessible by clicking on the button labeled Private WIF NetPlay Forum on the Opening Splash Screen. When you click on that button, the program validates your serial number. The first time you log in, the program then displays the registration form.

Registration
Registration is required for using the NPF. It is a fairly painless process since the program looks up the serial number. Note that the serial number data field can not be edited.

Be careful when choosing your user name and password, since you will not be able to modify them later. The program records all the registration information in the data file NetPlayRegistration.txt so you do not need to type it in each time you access the forum. You can always call up the registration form (using Change Port, described in the next section) to modify the other 3 data fields: residence, email address, and port number. Getting back to the user name and password, very few special characters are permitted. You may only use: a-z, A-Z, _ (underscore), and 0-9. Specifically, blanks are not allowed. The user name must be between 4 and 20 characters and the password between 5 and 20.

The tricky data field is the port number. To start with, MWIF sets it to a default value of 5950. Try using that. If you are able to receive messages from other players, then you can forget about the port number and ignore all the information in the next section. If you do change the port number, please use a value between 5950 and 5959.

Port Number
To set the value for your port number, you need to understand how MWIF uses ports. Unfortunately, that requires understanding some background information. Perhaps you already know a lot about port numbers, but for those readers who haven’t acquired that knowledge, I am going to go into some detail here. I have found that the best way to communicate technical information is by example. So, for explaining about port numbers, I am going to describe how I set the port numbers for my home computers.

I own 3 computers: a desktop running Windows 7, a laptop running Vista, and a Mac running the Mac operating system. Those systems go through my router to connect to the internet (via my phone’s land line). Although it doesn’t have a mouse, keyboard, or monitor, the router is also a computer. These 4 computers form a LAN (Local Area Network), with the router in charge of transferring messages between the computers. Because the router is my only access point to the internet, it handles all outgoing and incoming messages between my computers and the internet.

Each computer on my LAN is assigned a LAN address by the router. The router always uses 192.168.0.1. The other 3 computers get a similar LAN address, with only the last digit changing: to 2, 3, or 4. Which computer gets which LAN address depends on when they are powered up: first come first served. The important point here is that the LAN address is dynamically set by the router as computers connect/disconnect. The laptop usually gets either 192.168.0.3 or 192.168.0.4.

When one of my computers sends a message out to a website on the internet, the router notes which computer did so. That lets the router take the website’s response and send it back to the correct computer. As long as the connection originates from one of my computers, the router knows what to do with the response messages it receives. But if a message arrives unexpectedly from somewhere in the world, the message itself has to have sufficient information for the router to know to which computer to direct the message. That is where port numbers come in.

A port number is comparable to an extension on a phone line. When a message comes into the router, the router uses the port number to identify which of my computers should get the message. If I only had one computer, then I would not need a specific port number to play MWIF over the internet. The default port number would be fine. But because I have multiple computers, I need to have a different port number for each of my computers. The port number is associated with the LAN Address. I set those up using my router’s software. After I have the associations between port numbers and LAN addresses in place, the router can translate a port number into a LAN Address, and knows to which computer to send the incoming message.

Each LAN Address has its own set of port numbers for MWIF. I’ve assigned ports 5950, 5951, 5952, and 5953 to 192.168.0.2 (a LAN Address), ports 5954-5956 to 192.168.0.3, and 5957-5959 to 192.168.0.4. Theoretically, I could assign just 1 port number for each computer on my LAN. But since I have 10 available, I used them all. If I buy another computer someday, I’ll have to revise which port numbers are associated with which LAN Address.

Continuing the analogy of a port number being an extension, the router’s IP (Internet Protocol) Address is comparable to a phone number. When my router is turned on, it connects to my ISP (Internet Service Provider) which assigns my router an IP Address. The value of the IP Address is dynamically assigned, so I can not depend on it being the same from day to day. Because all my computers go through the router, they have the same IP Address. In order to play MWIF over the internet, the players’ computers need to know the IP Addresses and port numbers for the other players’ computers. The IP Address acts as the phone number and the port address acts as the extension. This combination lets the Internet direct the message to my router (using the unique IP Address) and the router to direct the message to the correct computer (using the port number to look up the associated LAN Address).

Mercifully, NPF takes care of figuring out everyone’s IP Address so you never need to worry about that.
NPF records each player’s IP Address every time he logs in and stores the current value as part of the data it has for the player. Although IP Addresses can be dynamic, NPF always has on hand each player’s current IP Address when a game session starts. It sends that information out to all the players automatically: no typing required.

You might need to change your port number from time to time (see section 6.1.3.7). I do that when my laptop LAN Address changes. If it has the LAN Address 192.168.0.3, I use port number 5955. When it is given the LAN address 192.168.0.4, I use 5957. Clicking on the Change Port radio button lets me do that easily. After I change my port number, MWIF logs me out of the NPF and immediately logs me back in again, sending my new port number to the NPF so its data about me is up-to-date.

Messages Layout
After you have registered your game, (and when you log in after you have registered), MWIF brings up the NPF form so you can see what if happening in the forum. There is a slight delay at this time while the program connects to the forum and downloads data on the current status of the forum. Figure 6.3.1.C shows the layout for sending messages and reviewing those that you have received. The program will also ‘ping’ the NPF every 2 and a half minutes so the NPF doesn’t ‘drop’ you from the list of on-line players.

You can create a new message at the bottom of the form and then click on the Send Message button to send it to all the players currently on-line. The list of players currently on-line is displayed in the upper left. You might want to refresh that list from time to time. Whenever you desire, you can clear all the text from the New Message and Messages Received panels by selecting all the text (Ctrl-A) and then pressing Delete on your keyboard.

Seeking Opponent Layout
Players who are seeking opponents can post information about what they would like to play, where they live, and when they would like to play. Let’s call this ‘Requests’. Those requests are collected in a database and remain active for 1 month, or until they are removed by the original poster. The complete list of Seeking Opponent requests is displayed in a grid in the upper right of this layout. See section 6.3.1.5 for a description of each of the fields in this grid.

By clicking on a request in the Seeking Opponent grid, you can review all the replies to the request in the bottom right corner (see figure 6.3.1.D). You can send your own reply by entering it in the lower left corner and clicking on Seeking Opponent - Reply. If you want to review the proposed optional rules from the original post, click on the Optional Rules column in the Seeking Opponent grid. That will bring up the standard Optional Rules Help form (see figure 6.3.1.E).

New Post Layout
When you want to add a new post to the list of Seeking Opponents, click on the radio button labeled New Post. That brings up the form shown in figure 6.3.1.F. The data fields for this form are described fairly well in the form itself. Please only enter the name for one of the scenarios. If you have an interest in playing other scenarios, then create a separate post. The program stores the values you type in, so the next time you access this form, the form is preloaded with the values you used last time.

Side is the side you want to play. If you have no preference, you should enter Either in that data field.

Optional rules has a label that provides a general description of the optional rules you want to use. The purpose of the label is to communicate quickly to other forum members how you would like to play the game vis-a-vis optional rules. If you want to use a lot of optional rules in the Advanced Set, then that is what you should enter. Novice players will then know to avoid playing against you. But more experienced players may express an interest in being your opponent.

You can craft exactly which optional rules you want to use by clicking on the Specific Optional Rules button and using the Optional Rules Help form (see figure 6.3.1.D). Notice that this form has 4 buttons on the middle right which let you start from something close to what you want to use: Novice, Standard, Advanced, and Personal. From those starting points you can tweak individual rules On/Off by right clicking on them. Left clicking on an optional rule brings up a description of the rule; it is the same text that appears in the Players Manual. Your Personal Set of optional rules can be created using the Start New Game form (see section 4.3).

Days of the week is simply when you would like to play. This is a free form field so you could type in: “any day except Mo or Tu”. Hours per session is simply how long you want to play each time you start a session with your opponent. What you enter in these two fields has no effect on the game itself. Their sole purpose is to start a discussion with your prospective opponent about when and for how long you would play.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Rules as Coded (RAC) & Player’s Manual
I uploaded a half dozen changes to RAC for the Matrix Games Editor. These were all clarifications from Harry that I hadn’t inserted into RAC previously. A couple were recent, from November, but most were from the first half of 2011.

I wrote my first draft of section 6.3.3 (see above), which describes setting up a NetPlay game. Because of the introduction of the NetPlay Private Forum (NPF) into that sequence, most of the text and the screenshots are about the NPF.

Tutorials, Training Videos, and Context Sensitive Help
I decided to eliminate the one missing page in the Picture and Text tutorials. It was suppose to describe bidding for major powers, but that topic is a little too complex to describe in a half page of text. I simply cut it off my task list. Other than that, nothing new here.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Nothing new - unless you count the After Action Report that Aaron worked on diligently throughout January.




Attachment (1)

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 23
RE: MWIF Monthly Reports - 3/2/2012 6:53:23 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		March 1, 2012 Status Report for Matrix Games’ MWIF Forum

Accomplishments of February 2012

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

My health shouldn’t be an issue in the near future. All the various specialists that have scanned and probed my inner being and sampled my precious bodily fluids over the past two months have grown bored with me as a patient. I’ll revisit them all in 6 months.

Hardware and Software
I am still unsuccessful in using the Indy10 library to send HTTP requests that include cookies. Early in February I gave this a small part of my attention but then bypassed the problem to work on more important things. I’ll take another look at it this coming week.

The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file).

Beta Testing
I released versions 9.04.00 (14 fixes), 9.04.01 (7 fixes), 9.04.02 (3 fixes), and 9.04.03 (4 fixes) to the beta testers in February. There wasn’t very much new for them because I was getting NetPlay to work. The last 2 of these versions had some NetPlay functionality for them to test. There’s more on NetPlay below.

Jimm has begun going through all the naval movement rules, testing them line by line, phrase by phrase. This is similar to what Rob W. did for the air missions. Basically, they go through Rules As Coded sections and run tests to see if the code performs in accordance with the rules.

Saved Games
Nothing new. I need to write some new code for restoring internet games. Mercifully the existing routines for saving games do not need to be changed. The trick to restoring them is to make sure both players are logged in to the NetPlay forum and using the same saved game: saved at precisely the same point in the sequence of play.

Map, Units, and Scenarios
Nothing new.

Optional Rules
Nothing new.

Rules Precision
Nothing new.

Player Interface
I am still tweaking the Private NetPlay Forum. That form is used to find opponents for NetPlay (i.e., playing over the internet) and start/restart internet games. This morning I added more checks for the registration data fields. Previously the error messages about invalid data had been vague to the point of being opaque.

Internet - NetPlay
I spent virtually the entire month working on NetPlay. After getting it to work the first time, it failed as soon as I made a minor change. Another week of work by me and it returned from the dead and breathed a few more breaths. Then it fell into a coma for a few days. To say the code was fragile is like saying a snowball has a long life expectancy in Hades. I finally figured out how to get the various client and server routines to work with the timer routines and the other code that keeps track of what has been sent and received over the internet and processed. Synchronization of ADG’s WW II simulation on multiple computers is a non-trivial exercise.

But after all that, it was a real rush to place a unit on the map on one computer and see the unit moved to the same location on the other computer. How fast does it work? Well, even sending the data over the world wide web results in the second computer updating its map faster than I can turn my head to look at the second computer’s monitor three feet to my right. When I send a batch of moves (e.g., restoring saved setup locations for several dozen naval units), it is just as fast. As far as humans are concerned, it is instantaneous. This is the advantage of a using a TCP/IP connection (continuously connected) instead of an HTTP connection (where the connection is reestablished for each transmission).

I’m working my way through the sequence of play fixing bugs related exclusively to NetPlay. For instance, I had to relocate the random selection of units from the French force pool for transfer to the Vichy French force pool for scenarios that start with Vichy already in existence. After my changes all the setup stuff that requires generating random numbers is separate from the work that can be done on both computers independently.

Let me explain that a little better. The person who starts a NetPlay game sends 85 GRLs (Game Record Logs) over to the second player’s computer. Those list all the optional rules, the scenario, the player names, and who is playing which side. Then both computers execute the next 8200 GRLs independently. This is equivalent to what over the board players do when they sort all the counters and place them in different pools (or cups). Once both computers are ready, the player who sets up units first sees a setup tray loaded with the units to be set up. The other player’s screen shows an empty map. As the first player transfers units from the setup tray to the map, both screens show the units being placed on the map. For me, who has written 10,000+ lines of code to make this happen, it is a miracle, or possibly just plain old fashion black magic.

There is some good news for you, dear reader. But it is bad news for me, the poor programmer. Matrix/Slitherine has decided to host all the NetPlay games on a dedicated server. What that means is that no one is going to have to deal with ports, firewalls, and all the other security/protection features that computers have these days. Instead, you simply log into the dedicated server, which validates your copy of the program, and then you’ll be able to play a game over the internet with a worthy opponent. The reason this design avoids security hassles is that you will being logging into the server and ‘requesting’ data. The same is true for your opponent. There won’t be any need for you to permit another computer to ‘call’ your computer and go through all the security related to starting a “conversation with a stranger”.

For me, this means that a lot of the work I spent weeks on over the past two months was unnecessary. Indeed, I now need to spend time writing code to support the new design. This is a classic aggravation for programmers: specifications changing after code has been written and debugged. It’s right up there with dysfunctional software tools and non-existent documentation for making programmers froth at the mouth. Down the road life will be easier for everyone, including me, since players won’t be asking about how to configure their routers and sate the demands of their security software.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Rules as Coded (RAC) & Player’s Manual
John (the person assigned by Matrix to be the editor for World in Flames) has completed editing RAC. I reviewed his edits and, aside from adding an index, RAC is ready to go to Marc (the layout guy - who places the graphics within the document and hand tailors each page). Once Marc is done his task, it goes to the printer.

I am going to have to substantially revise my draft of section 6.3.3 in the Players Manual, which describes setting up a NetPlay game (see the section on NetPlay above). However, I was able to finish up a few other odds and ends for the Players Manual. Right now the only area other than 6.3.3 that needs work is gathering examples of different screen layouts: placing the map and other forms in different screen locations depending on the number and size of the monitors a player has available. I would like to have a half dozen screen layouts so players can have one available that is sort of close to their own configuration.

Matrix is negotiating with several printers on printing RAC and the Players Manual. Because the size of these documents is larger than for other games, getting a good deal on the price of printing them is important.

Tutorials, Training Videos, and Context Sensitive Help
Context sensitive help is now done except for a half dozen entries for the NetPlay forms. There are ~350 entries completed which cover all phases/subphases in the sequence of play and all the forms. As reported last month, the Picture and Text Tutorials are done.

Rob W. has acceded to my request (it was more like me begging) that he make a first pass on the text for the interactive tutorials. There’s a bunch to do, but none of it requires programming. Being able to immediately see your work on the screen is another bonus; instant feedback is always nice.

The Training Videos (8 out of 11 completed) cover the same material as the tutorials. The difference between the two is active versus passive. The players can watch the Training Videos listening to the narrator comment on what he is doing. Alternatively, the interactive tutorials let a player control the mouse and keyboard, fiddling around with other stuff if he wants to. He won’t get as much commentary - which may be good, may be bad.

The match up between the Interactive Tutorials and the later Training Video chapters is:

11 Introduction to Interactive Tutorials (Training Video 6 part I)
This tutorial focuses on the Main form, the drop down menus, and the various buttons and panels that are tightly packed into the Main form, which is ubiquitously present during game play.

12 Screen Layouts and Map Views (Training Video 6 part II)
MWIF introduces two innovative game features: screen layouts and map views. Screen layouts enable you to control the visibility and positioning of dozens of forms. More importantly, it lets you design layouts where multiple detailed maps are visible simultaneously. Map views provide a dynamic means of jumping from one battlefield to another effortlessly.

13 Setting Up Units (Training Video 7 part II)
Setting up units only happens at the start of a scenario, although the setup tray is also used at other times. For example, it appears when bringing in reinforcements, placing reserve units on the map, and setting up the units of attacked minor countries.

14 Land Unit Movement and Combat (Training Video 9)
Land movement itself is pretty easy in MWIF, so the first part of this tutorial explains the Unit menu, Flyouts, overruns, and status indicators. The second part of this tutorial takes you from declaring attacks, through adding in artillery and air support, and ultimately to resolving individual combats. Invasions and paradrops are also covered in this tutorial.

15 Naval Unit Movement (Training Video 10)
Naval movement in MWIF is somewhat complicated. To start with, designating groups of naval units that are to move, and determining how far they can move, is quite different from land movement. Additionally, enemy naval units already at sea can intercept your naval moves. Lastly, picking up land and air units with naval transports is done during the naval movement phase.

16 Naval Combat (Training Video 11)
MWIF has three types of naval combat: air-to-sea, surface, and submarine. This tutorial takes you through all three types, including the assignment of losses, damage, and aborts.

17 Air Unit Movement (Training Video 8 part I)
Air movement is easy and this tutorial lets you conduct 3 types: strategic bombing, carpet bombing, and ground strikes. For the first two of these air mission phases, a strategic bombing attack is subjected to anti-aircraft fire, while the carpet bombing attacks go in unmolested.

18 Air-to-air Combat (Training Video 8 part II)
Air-to-air combat in MWIF has it own set of sub-subphases, and each combat can have multiple rounds. This tutorial lets you go through several air-to-air combats and experience a variety of outcomes.

19 Production (Training Video 12 part I)
Production in MWIF is done in two separate phases: Production Planning and Production. This tutorial lets you examine the details of both planning for production and actually building units.

20 Politics (Training Video 12 part II)
The last interactive tutorial covers the Declaration of War phase, which has many subphases, most of which deal with changing international relationships between major powers and minor countries.

Historical Video, Music, and Sound Effects
Nothing new last month, but I’m going to see if I can implement all of these in the first 10 days of March.

Marketing
Nothing new.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 24
RE: MWIF Monthly Reports - 4/2/2012 5:47:31 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		April 1, 2012 Status Report for Matrix Games’ MWIF Forum

Accomplishments of March 2012

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Hardware and Software
Matrix solved my difficulty with HTTP requests that included cookies. The problem was that the expiration date on the cookie indicated it was no longer valid, so the Indy10 software package did not use it. Once the Matrix programmers changed the cookie’s expiration date so it was valid, all was well. I am now able to access the NetPlay server’s Seeking Opponents database. The Matrix programmers also finished their changes to the NetPlay server so players no longer need to work with IP addresses, port numbers, and security issues to play the game over the internet. There is more on that topic below under NetPlay.

The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file).

Beta Testing
I released versions 9.05.00 (4 fixes), 9.05.01 (29 fixes), 9.05.02 (31 fixes), 9.05.03 (2 fixes), 9.05.04 (27 fixes), 9.05.05 (15 fixes), 9.05.06 (15 fixes) , and 9.05.07 (7 fixes) to the beta testers in March. This is about my normal number of new versions (8) and fixes (128). While I was waiting for Matrix to make the necessary NetPlay changes (completed late in the month) I bore down on the bug list.

My first batch of fixes were for air mission bugs. Rob had detailed a lot of those and I was able to fix most of them; there are still 13 to do. Then I cleaned up all the setup, Declaration of War, and reorganization bugs. The last large batch I fixed were for naval movement and naval combat; I now have the naval bugs down to 7. The other large list of bugs to fix is in Production Planning. I keep trying to clean up other issues so I can focus exclusively on that phase of the game, but distractions abound.

Some of the new beta testers are getting involved. Peter v. in particular has been working closely with Rob W. on the interactive tutorials. That’s discussed more below.

Saved Games
Nothing new. I need to write a bit of new code for restoring internet games.

Map, Units, and Scenarios
Changed the Zuider Zee to IJsselmeer in the map data so the correct name appears on the map.

Optional Rules
Nothing new.

Rules Precision
Nothing new.

Player Interface
I automated the creation of default screen layouts for new players. In a nutshell, the program checks out what monitors you have on your system and makes an intelligent guess at the best size and location of important forms. This way the program appears tailored for your system. At the end of this report is an excerpt from the Players Manual that describes that automation in more detail.

Internet - NetPlay
I spent the last third of the month mostly working on NetPlay. I had to trash the code I had just gotten to work for exchanging data directly between two players’ computers. The new design is cleaner and easier to support but it was painful to remove code that functioned correctly.

The new design avoids the security hassles with one computer permitting another computer to ‘call’ and initiate a “conversation with a stranger”. Instead of having to deal with ports, firewalls, and other security/protection features, a player simply logs into the Matrix server dedicated to World in Flames to play a game over the internet with a worthy opponent.

The past couple of days I have been working with the JSON data structure, which is what the Matrix server uses for posts. I’m close to getting that to work. Behind the scenes, the JSON database stores the NetPlay “seeking opponent posts” by players. You will be able to post a request and reply to other players requests. Ideally this will let players find opponents for NetPlay games easily.

I still need to write new code to have the players’ computers send/receive messages and game data when playing over the internet. Once I get the Seeking Opponent and Messaging systems working I can take the final screenshots and finish the last few paragraphs of the Players Manual. Then I’ll be reduced to just tearing my hair out whenever I see a typo in the Players Manual.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Late in March John sent me his final edited version of the Players Manual. It was 523 pages without figures. Of course the number of pages depends on the page size, margins, font size, and line spacing. For instance, my version came in at 350 pages and that was with all the figures included. As of today, I have proofread 404 of John’s 523 pages and I should finish the rest in a few days. The figures are also almost ready for Marc (who will merge the text and figures). My last count was 271 figures for the Players Manual of which 265 are ready for Marc, with 3 screenshots to be retaken and 3 new screenshots needed for NetPlay.

After Matrix’s discussions with the printers it looks like the Players Manual and Rules as Coded will be separate volumes. There had been some consideration of making them a single volume containing two ‘Parts’.

Tutorials, Training Videos, and Context Sensitive Help
I corrected the graphics used in the 10th picture and text tutorial (sequence of play) so they use underlined text instead of colors. This had been a problem for some beta testers with difficulty distinguishing colors.

My wife updated the Content Sensitive Help messages for the revised Screen Layouts section and a few other sections that I updated while proofreading the Players Manual. Only the NetPlay message will need further revision - once I finish coding NetPlay.

Rob W. Has completed 8 of the 10 Interactive Tutorials, with Peter v. beta testing them heavily and finding a bunch of improvements for Rob to make. He and Rob are working out the details. I am trying not to get involved since I’ve got so much else to do. Hopefully with the new beta testers also putting those tutorials through their paces, the group will be able to buff and polish them without me doing very much.

One of the changes Rob and Peter decided on was to change the order of the tutorials so the sequence is air, land, and naval. Because naval units are the most difficult units to move and engage in combat, we’ve put it last - after the player has had a chance to build up his familiarity with unit movement and combat in general.

Because the beta testers were complaining that they didn’t understand what they were suppose to do with the interactive tutorials, I’ve created a title page for each. It gives a short overview of the tutorial and itemizes what you will have learned once you complete it. To address the problem of how to execute the tutorial, the title page contains some standard paragraphs at the bottom that explain the instruction form, which the player uses when going through the tutorial. If you want to see what the title pages look like, last week I posted the first 7 (#11 through #17) in the thread MWIF Game Interface Design. Rob just sent me #18, so I’ll do a title page for that tomorrow.

At this point I think the interactive tutorials will be a popular way for players to learn the player interface and other important game elements (e.g., setting up units, moving units, engaging in combat, and production).

Historical Video, Music, and Sound Effects
Nothing new. I am still trying to find a week of time to embed all of these into the sequence of play.

Marketing
Nothing new.



Excerpts from Players Manual section 8.6 Screen Layouts

Form Dimensions and Locations
Many forms have fixed dimensions and locations, though they can all be rolled-up by clicking on the small icon in the upper left corner of the form. That reduces the form to a thin horizontal bar (i.e., just the top of the form). You can restore the full form by clicking on that icon a second time.

The more important forms can be resized to meet your personal taste: detailed maps, the global map, the setup tray, the screen layouts list, map view lists, selectable units, naval review details, etcetera. Each screen layout stores the location (and usually the size) of the following forms:
1. Main form
2. Screen layout list
3. Map views list (a separate entry with size, location, and content is made for each major power)
4. Detailed maps (a separate entry with size, location, and display controls is made for each detailed map on the screen).
5. Global map
6. Sequence of Play (only the location is stored since the size is dynamic)
7. Setup tray (this can be expanded horizontally to see more units).
8. Units in hex (this can be expanded horizontally to see more units).
9. Selectable units (this can be expanded vertically to see more units).
10. Naval review details (this can be expanded vertically to see more units).
11. Naval review summary (a separate entry with size, location, and content is made for each major power)
12. [Task force details. Not used.]
13. [Task force summary. Not used.]
14. Land combat resolution
15. Dice
16. Chat
17. Interactive Tutorials

New Game.SLY
One of the most important things to know when starting a new game is that for each scenario there is a screen layout with the name “New Game.SLY”. These are the 11 SLY files that the program uses to start new games. The “New Game.SLY” files are slightly different for the 11 scenarios, since the number of major powers and the frontlines change from scenario to scenario. So, if you start a new game for the Barbarossa scenario, then MWIF uses the “New Game.SLY” file in the Barbarossa directory to determine the location and dimensions for all the forms listed immediately above.
.
.
.
If MWiF cannot find New Game.SLY, it automatically creates a New Game.SLY for the scenario. The newly created screen layout takes into consideration how many monitors are on the system and the size of the monitors. Based on that data, the program defines positions and sizes for all the forms listed above. It also defines a set of map views for each major power for each scenario, and stores that information within the new screen layout file.
.
.
.
After you acquire some familiarity with game play, it behooves you to spend some time modifying (i.e., Redefining) the “New Game.SLY” file to suit your own preferences.
.
.
.
Minimal Screen Size (1024 by 768)
Figure 8.6.C shows the default screen layout for the minimal configuration. It positions the Main form at the top left of the screen and the Detailed Map below it. To the right of the Main form, at the top of the screen, are the screen layouts list and the map views lists.

When other forms appear, they overlay the detailed map, and possibly even the main form - if they use the full 1024 by 768 footprint. The first few forms you see when you start a new game (lend lease and scrap units) and all the forms used during combat require this maximum footprint. In contrast, the setup tray has been made as small as possible and is positioned at the bottom of the screen, to maximize the amount of viewable area on the detailed map. So too the Main form, Screen Layouts list, and Map Views list have been scrunched down to as small a foot print as possible.
.
.
.
There are numerous helpful forms that you might want to examine during game play. The Global Map, Sequence of Play, Units in Hex, and Selectable Units forms are just some examples. With the minimum monitor size you will probably just toggle these on and off using the short cut keys defined for them. Or you could “roll them up” using the small up-arrow triangle icon in the upper left of every form.
.
.
.
Other Single Monitors
If you have more than the minimum width available, MWiF repositions several forms when it creates a new New Game.SLY. Figure 8.6.E shows the layout for a monitor that is 1280 by 1024. It has the Main form positioned somewhat to the right, leaving room for the Selectable Units form to appear between it and the left edge of the screen (i.e., in the upper left corner). The detailed map is extended to use almost the full width of the monitor, leaving room for the Global Map to peek through on the far right. Notice that the screen layouts list and map views lists are no longer cropped vertically as they are for a minimally sized monitor.

With very large monitors, the Global Map is placed at the top, making the entire width of the form available for the detailed map. Figure 8.6.E is an example of the default screen layout for a monitor that is 1920 by 1080.
.
.
.
Dual Monitor Systems
Dual monitors provide more real estate for the MWIF forms and therefore more flexibility in screen layouts. The automatic creation of the New Game.SLY file only considers the situation where there are two monitors. If you have more than two, then the two leftmost monitors are used. You can create your own New Game.SLY file for three or more monitors by starting with the one automatically created for two monitors.
.
.
.
The left monitor is devoted to the detailed map, with the setup tray placed at the bottom, when in use. The Selectable Units for appears on the left side of the left monitor when that form is active (as shown). The default position for the Units in Hex form is in the upper right corner of the detailed map (not shown).

The right monitor holds principally: the Main form, Global Map, Screen Layouts list, Map Views list, Sequence of Play, Naval Review Details, Naval Review Summary, and all other forms that appear during game play. The basic concept here is that your main detailed map is never obscured by large forms, and is omnipresent. The exceptions are the Setup Tray, Selectable Units, and Units in Hex forms; the reason they overlie the detailed map is so the “mouse distance” from a unit in those forms to a location on the detailed map is minimal. For example, moving the mouse back and forth from the setup tray to the detailed map can be tedious if the two are far apart and you have 50+ units to set up.

Of course, you can design the layout however you like, and there are going to be numerous variations given the variety of monitor combinations possible. Indeed, the entire purpose behind the screen layouts feature is to enable you to tailor MWiF to accommodate your particular hardware configuration and personal preferences.




Attachment (1)

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 25
RE: MWIF Monthly Reports - 5/3/2012 4:44:05 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		May 1, 2012 Status Report for Matrix Games’ MWIF Forum

Accomplishments of April 2012

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Hardware and Software
Matrix Games programmers fixed the problem with dropped server messages when using the NetPlay Forum to communicate with other players that are logged in. That capability is crucial for starting/restarting a NetPlay game. The same correction was made to the game server, which is used when playing an game over the internet. They also enabled deleting Seeking Opponent requests. This means that players are able to delete their posted requests to the Seeking Opponent database once an opponent has been found; therefore all listed posts should be active.

The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file).

Beta Testing
I released versions 9.06.00 (9 fixes), 9.06.01 (10 fixes), 9.06.02 (1 fix), 9.06.03 (8 fixes), 9.06.04 (6 fixes), 9.06.05 (12 fixes), and 9.06.07 (19 fixes) to the beta testers in April. Version 9.06.06 was used by me but never uploaded to the beta testers. This is about my normal number of new versions (7) but half my typical fixes (65).

One reason there were so few fixes this month is that I have been running alpha testing for NetPlay, besides being time consuming (working with two computers), that means I was both discovering and fixing bugs rather than dividing the labor between the beta testers (finding) and me (fixing).

I fixed one bug in creating detailed maps which must have dated back to 2005. I’m kind of baffled that anything worked with this bug present (there were two separate copies of the detailed maps). See the comments regarding NetPlay below for most of the changes I made for the new versions I uploaded for the beta testers.

Saved Games
I revised the format for saved games (*.GAM) a couple of times so it contains the necessary data for switching decision makers (e.g., USSR, US, Italy) during setup for a NetPlay game. This was the reason version 9.06.06 was never uploaded for the beta testers.

Restoring NetPlay games now works. To accomplish this required a handful of coding changes. For instance, the autosaved games needed to be synchronized so they are created simultaneously on all computers. The program checks that both players are restoring the same game at the same point in the sequence of play. To make that determination, the program uses the Game Number and the Next Entry Number, which are written out to the GAM file. Prior to restoring a game, players should check those numbers to make sure they match. The program displays that information for each saved game when a player ‘considers’ whether or not to restore a game. When NetPlay executes, it checks for matching numbers and reports any discrepancy. The same system will be used for PBEM games.

Map, Units, and Scenarios
I removed Ceylon as part of the setup area for the Commonwealth in Guadalcanal. I also updated the naval unit writeups with the latest from Rob J.

Optional Rules
Nothing new.

Game Engine
Getting NetPlay to work forced me to revise the code for the Weather phase. It is now what I consider ‘beautiful’ code. Rarely do I go to the effort of writing code that might be considered beautiful. But the requirements for the weather phase are both few and weird. Having the weather preset for some scenarios but not for all of them is one strange aspect. Having it rolled every other impulse is another. In addition, MWIF rolls for the weather and reports it to both players. In practice that means reporting it for one major power for each player. After all players have closed the weather report form, the game advances to the next phase.

This combination of unusual requirements dictated that the code had to be crystal clear. Previously I had been patching the CWIF code to implement the weather phase, but the result became so confusing. So I more or less started over. Now the weather phase has its own module, similar in structure to all the other phases. Not a lot of code but it’s very easy to understand how it handles the unusual weather rules.

Setup is one of the most complex phases and I finally admitted that it also needed its own module with 3 subphases: (1) lend lease at the start of the game between major power on the same side, (2) placing each major power’s units on the map, and (3) placing partisan units on the map after all other units have been set up. I think of these as: lend lease, set up major powers, and set up partisans. It was a struggle to get these to execute correctly for NetPlay.

Lend lease involves all the major powers on a side which make decisions simultaneously. On the other hand, setting up the major powers is processed by each major power in a rigidly defined order. That is also preceded by a scrap units sub-subphase prior to randomly drawing units from the force pools. Always a pain to code was setting up the Nationalist Chinese and then the Communist Chinese - because they are one “major power” set up by two major powers. Setting up partisans is similar to setting up major powers, but with the kicker that there might not be an available hex for some units (“No room for the partisan unit on the map.”).

Here are the routines I gathered together in the Setup Phase module:
function SettingUpPartisans: Boolean;
procedure Setup__Initialization;
procedure Setup__ChangeSubPhase(const NewSubPhase: TSetupSubPhase);
procedure NextSetupMajorPower;
procedure NextSetupPartisans;
procedure Setup__Process;
procedure FinishedSettingUp;
procedure Setup__TerminateMajorPower(const MPI: TMajorCountries);
procedure Setup__Terminate;

Many other phases of the game needed revisions to support NetPlay. The most common problem is how to process an event so it is only done once, by one major power, but gets reported to all the players (e.g., setting up reserves). Again, the changes I made here were also required by PBEM. Mandatory DOW on major powers was a major hassle to revise but that now functions correctly. I currently have a similar problem with the mandatory DOW by Germany on Poland - that’s next on my list of things to fix.

Player Interface
Nothing new.

Internet - NetPlay
I spent the month mostly working on NetPlay. I finished the code for working with the JSON data structure, which is used for Seeking Opponent requests. Players can post a request and reply to other players requests. The intention of this functionality is to enable players to easily find opponents for NetPlay games.

I also finished the code for players to send and receive messages and game data when playing over the internet. Getting that accomplished let me take the last couple of screenshots for the Players Manual. A typical game starts with 13,000 game record logs being created and transmitted between computers. That’s a pretty severe test for the game server.

Sending and receiving messages while logged into the NetPlay Forum is useful for resolving any outstanding issues about starting a NetPlay game (e.g., negotiating about optional rules). It can also be helpful just before starting/restarting a game to coordinate when to start and how long the session will last.

One aspect of NetPlay that I now have working correctly is that the flags in the main form accurately report which major powers currently have decisions to make. Those flags also indicate whether the local player controls the major power or not: a large image means the local player control the major power, a small image means he does not. In addition there is a little ‘Waiting’ message in the main form when a player is waiting for another player to make a decision.

I’ve been able to run the Barbarossa, Global War, and Missed the Bus scenarios through to the completion of setup in NetPlay mode. A couple of beta testers have been able to do the same for Global War. I’ve actually run Barbarossa through several impulses, but that was by taking mostly Pass actions for both sides. Testing NetPlay takes a lot of effort because it involves either two people or running two computers with a lot of back and forth. Now that I have saving and restoring NetPlay games working it will be much easier. That starting every game from the very beginning got old super fast.

PBEM
Nothing new, other than the comments above about saved games and the game engine.

Artificial Intelligence (AI)
In making changes to support NetPlay I reviewed, and made a couple of changes to, the code determining which major powers are decision makers (I was able to reduce the code from over 1000 lines to 825). The important thing was to enable a player, who currently has no decisions to make, to have full access to the map, units, and various forms to review the status of his position vis-a-vis his opponent.

Another change I made for NetPlay, that has direct bearing on the AI Opponent code, was that I created a separate thread to run some code “in the background”. It is a minor technicality but I am happy to now have a working example of how to code background threads using Delphi. Virtually all the AIO code will execute in separate (i.e., background) threads. The intent is to have the AIO figure out what to do, while its human opponent is moving and clicking the mouse and using the keyboard. When the time comes for the AIO to decide something, it should be able to do so quickly.

Player’s Manual
I have finished with the text and screenshots for the Players Manual and Rules as Coded. Next up for my involvement with the documentation is proof reading the final layouts for how those will appear in print.

Tutorials, Training Videos, and Context Sensitive Help
Content Sensitive Help messages are finished (350+ messages totaling 693 kb). The 20 tutorials are also finished, although Rob W. is still worrying over the text for the interactive tutorials (261 kb). Rob wrote the text for all 10 of the interactive tutorials and Peter v. diligently went through them all, checking for clarity and typos. I made a bunch of code changes to support the interactive tutorials; there are still a couple of coding loose ends that I need to look into.

All that really remains here is for me to re-record the 6th and create the last three Training Videoes: 10, 11, and 12. The 6th (main form and drop down menus) needs redoing because I have seriously modified some of the forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics.

Historical Video, Music, and Sound Effects
I now have all the files I need for this except for the Italian National Anthem. For that I have a MP3 file, but I need a WAV file. All the sound files are WAV and the video files are WMV.

Marketing
Nothing new.

< Message edited by Shannon V. OKeets -- 6/3/2012 2:43:04 AM >

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 26
RE: MWIF Monthly Reports - 6/2/2012 7:31:40 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		June 1, 2012 Status Report for Matrix Games’ MWIF Forum

Accomplishments of May 2012

Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Hardware and Software
Matrix/Slitherine Games programmers revised the code at the NetPlay server end and cut the log in time down to 10 seconds. Since it had been 90 seconds, that made a big difference for debugging NetPlay. This should be acceptable for the released product too. What is done during that period is to verify the game’s serial number, log in to the lobby, list the other players who are logged into the lobby, log into the Seeking Opponent database, download the list of all entries in that database, and list all the replies to the first entry in the database. This gives the player a lot of information on his screen immediately after logging in, without him having to enter more commands.

The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file).

Beta Testing
I released versions 9.07.00 (22 fixes), 9.07.01 (1 fix), 9.07.02 (13 fixes), 9.07.03 (24 fixes), 9.07.04 (22 fixes), 9.07.05 (27 fixes), 9.07.06 (46 fixes), and 9.07.07 (8 fixes) to the beta testers in May. This is about my normal number of new versions (8) but 40% more that my typical number of fixes (163).

One reason there were so many fixes this month is that I was able to work with saved games from the beta testers that reproduced bugs immediately. That saved me the time and effort of trying to recreate the problems on my own. I am still running alpha testing for NetPlay, but the technical issues have been ironed out, so fixing those bugs involves working with the sequence of play rather than synchronization issues and queues. In particular, that means that the beta testers are able to find NetPlay bugs instead of me having to check every aspect of the game personally.

One point of my focus this month was to eliminate bugs in Production Planning (i.e., identifying who owns/controls the resources and factories and getting the former to the latter). There are a lot of detailed subtasks involved: mandatory fulfillment of trade agreements, convoy capacity, saving oil, and overseas routes. Since I hadn’t looked at these bugs seriously in over a year, they had accumulated to a count of 43. I reduced that to 19 and should be able to clean up the rest in the next week or two.

There seem to be a lot of minor details to straighten out. For instance, during the past month I added code so:
• When the US successfully DOWs a major power, a message is now shown to all the other players stating the totals in each of the 4 US Entry Pools.
• Bombers that fly naval air missions at extended range can now use extended range when returning to base.
• Added a check for an off-city reinforcement so it can only be placed in its home country. This came up when a home city was adjacent to a different, but friendly, country (e.g., Vienna next to Czechoslovakia).
• Excess overstacked naval units (just captured) in a damaged major port are destroyed by the owning player until stacking limits are met.
• Relocated code for calculating the production multiple bonus for being attacked in your home country so it is applied even if all the attacking units are destroyed.
• When Bessarabia is recovered by Rumania, a Hungarian fighter in Bessarabia was not being counted as having started the impulse in Rumania. Fixing this prevents the fighter from being destroyed because of foreign troop commitment limits.
• Rail movement of factories to cities wasn’t counting the factories “on the move” to the city, with the result that more than 2 blue factories could end up in a city.
• When Denmark is conquered, its territories become neutral. RAW doesn’t say what is to be done with naval units in those territories (e.g., Iceland). I decided to just leave them there. They can exit the port whenever they like but no additional units can arrive unless there is a DOW on the territory (which is now a minor country).
• I added a data field and code so the negation of the movement point penalty for “In the Presence of the Enemy” only occurs if the friendly unit (which provides the negation) was present in the sea area from the beginning of the turn. CWIF had this coded as from the beginning of the impulse (perhaps a rule change from long ago)?
• Foreign troop commitment limits should not be imposed on Commonwealth air units flying air missions into France. But it should be imposed on Finnish air units leaving Finland.
• I corrected the flag image for Free France in the Production Planning form - it was wrong in 2 of the 3 places where the flag is displayed.
• Placing partisan units on the map can be tedious because it is difficult to identify where they can be placed if there are only a couple of possible hexes. The program now identifies the first two eligible hexes for the player.
• I added code so the Commonwealth has only half of their activity limits once the United Kingdom has been conquered.
• I modified the bitmaps and labels for damaged oil resource markers so they state the resource’s hex. This lets the player choose which one to repair during production if there is more than one damaged oil resource.
• I added code to fulfill the rule in of RAC 8.2.10, Swedish resources to Germany. The consensus of the beta testers was: IF Narvik = Allied AND Arctic Weather is Snow or Blizzard THEN Swedish Resources are lost. Note that for Germany to receive the Swedish resources they always need to be convoyed through the Baltic Sea.

Saved Games
I continue to tweak the format for saved games (*.GAM). These are small changes, and some are merely me keeping everything neat (i.e., eliminating data fields that are no longer in use).

Map, Units, and Scenarios
For this category there were a handful of minor corrections this month. In Decline and Fall, Albania was being shown as controlled by Italy, which isn’t part of that scenario, so we changed Albania to neutral. There was an Ethiopian reserve militia appearing in the Commonwealth reserve pool at the start of scenarios where the Commonwealth had liberated Ethiopia; we moved it to the Commonwealth force pool. I needed to add a missing French partisan to the setup list for Darkness Before the Dawn scenario.

I also updated the naval unit writeups with the latest from Rob Jenkins.

For the Fascist Tide scenario I modified the USSR resources and factories in the same manner as described below for Barbarossa. Also in Fascist Tide, the Commonwealth is suppose to get 3 non-oil resources and 3 factories from outside the playable map area. I simply converted these to 3 production points and ‘gave’ them to the Commonwealth comparable to how the bonus production points are given to the Commonwealth when using the optional rule Food in Flames. There are no restrictions on these 3 PP. I still have to write new code for dealing with the Transfer Pool in the half map scenarios Fascist Tide and Day of Infamy.

The only thing I spent significant time on under this heading was getting the resource and factory counts right for Barbarossa. What follows is my analysis and resulting implementation.

Analysis of German production
From the scenario booklet: Germany receives 3 resources from Sweden that must be transported via the Baltic Sea to be useable, and 19 factories, 1 oil, and 14 other resources off the western map edge.

There are 20 factories in Germany on the Western European Map so 1 German factory is not usable. I made that the factory in Munich. Controlled by Germany on the Eastern European Map there are 3 non-oil resources, 3 oil resources, and 5 factories: Lodz, Breslau, Vienna, Bratislavia, and Bucharest. The Hungarian factory is available once Germany aligns Hungary and the Finnish resource once she aligns Finland. The Hungarian resource is available through a trade agreement before Hungary is aligned. Therefore, at the start of the scenario Germany should have 24 factories available for production.

There are 8 non-oil and 2 oil resources in Germany on the Western European Map so 1 oil resource is not usable and 6 non-oil resources have to be added. Germany receives 6 non-oil resources through trade: Hungary, Sweden (x3), Turkey, and Spain. She also gets 1 oil resource from an Iraqi trade agreement. Since it is easiest to modify resource counts using trade agreements, I eliminated the Iraqi trade agreement (minus 1 oil resource), increased the Spain agreement to 4 non-oil resources, added a new Bulgaria trade agreement for 1 resource, and include the 2 non-oil resources that Germany controls in Yugoslavia. This results in Germany getting 6 non-oil resources from outside of Germany. The subtraction of the Iraqi oil is offset by including both oil resources in Germany/Austria.

At the start of the scenario Germany has 5 oil resources: Rumania (x3) and Germany (x2); in addition she has 23 non-oil resources: 5 in the east (including the 2 in Yugoslavia), 8 in the west, and 10 in trade. So, if saving oil is possible, Germany should be able to keep 24 factories producing while saving 4 oil per turn.

Analysis of USSR production
From the scenario booklet: The USSR has 4 factories, 6 oil, and 11 other resources off the eastern map edge. Furthermore, from Jul/Aug, the USSR receives 5 resources via Archangel (while not frozen) and/or Murmansk (Soviet player’s choice), if those ports are Soviet controlled.

There are 7 factories, 7 oil resources, and 12 non-oil resources controlled by the USSR on the Asian and Pacific Maps. Therefore the USSR factory total has to be reduced by 3, its oil resources by 1, and other resources by 1. I eliminated the non-oil resource west of Sverdlovsk (hex 88, 39), the oil resource in Perm, and the factories in Sverdlovsk and Perm.

At the start of the scenario there are 22 factories, 3 oil resources, and 8 non-oil resources controlled by the USSR on the Eastern European Map. So the USSR has 26 factories, 9 oil resources, and 19 non-oil resources available. That gives her 26 factories at full production while saving 2 oil (if that is permitted).

As for the 5 resources arriving starting with the Jul/Aug, I made the following decision (call me Winston). All 5 resources arrive in Archangel, if that is possible. If not, then they arrive in Murmansk, if that is possible. Otherwise they are lost for the turn. The player has no involvement in this decision (Churchill decides). Not all the beta testers were happy with this decision (they wanted the player to be able to decide exactly how many resources went to each city as stated in the WIF scenario booklet). But implementing that would require more specialized code and provide marginal benefit in this 5 turn scenario. I have more pressing concerns than the potential loss a 4 production points to the USSR (in the worst case).

Optional Rules
I fixed a bug in reinforcements arriving in off-city hexes. But I still need to make one more modification to that code to fully solve the problem.

Game Engine
Supporting NetPlay has caused me to acquire a better understanding of what the game engine has to do in each phase/subphase/sub-subphase/digression. There are four tasks within each of those simulation elements:

1. Determine which major powers need to make decisions - this is done separately by each player on his computer. In some phases, e.g., Weather, a representative major power is chosen for each player.

2. Each deciding major power makes decisions - this is done by the controlling player for each of his major powers and the results of his decisions are sent to the other players so all computers have identical data on the simulation/game state.

3. A major power terminates making decisions - this is done by the controlling player for each of his major powers and the results of his decisions are sent to the other players so all computers have identical data on the simulation/game state. This may be as simple as closing the weather report form.

4. One computer (MasterMWIF) makes the determination that the simulation element (e.g., phase) is over - upon doing so, MasterMWIF determines what simulation element occurs next and sends that information to all players so all computers have identical data on the simulation/game state.

Like most things having to do with programming, this is pretty obvious in retrospect. But before someone (in this case, me) has thought it out completely and in excruciating detail, it is a large ball of fog with several nasty bear traps embedded within.

Now when I think of debugging the sequence of play for NetPlay, I focus on each of these 4 tasks separately. Did each computer determine the deciding major powers? Are the decisions made by one major power being sent correctly to the other players? Is each major power’s end-of-phase command being sent to all the other players? Is MasterMWIF, and only MasterMWIF, making the decision when the phase is over and informing all the players? All die rolls and other random events are made by MasterMWIF. Obviously that introduces additional complexity at times.

I methodically went through the code for each of the 152 simulation elements checking #3 and #4. I was already pretty sure that #1 was working correctly. Most of the remaining bugs lie in the realm of #2. There are 550+ GRLs (Game Record Log) record types that are used to send data on the different WIF decisions to the other players. And each of those has 6 code segments that must be done as a series of steps. All tolled, there are 44,000+ lines of code devoted solely to task #2.

Player Interface
Nothing new.

Internet - NetPlay
I spent half the month working on NetPlay.

I have moving and undoing moves working correctly for land, air, and naval units. What I am currently trying to fix are the combat forms so both players receive the decisions made by the other player and the die rolls made by MasterMWIF. For instance, when a ground strike is conducted, both players need to see the results (right now only one of them does). In naval combat the use of surprise points has to be communicated to the other player (that isn’t happening). And in land combat, after the results have been determined for a combat, the attacking player’s computer isn’t being informed that the subphase has changed and he has things to decide (i.e., advance after combat).

None of the problems here are really nasty, although there are a few than snarl rather aggressively. Like all bugs I am working my way through them one at a time, a chair in one hand and a whip in the other.

The beta testers have been able to run through an impulse and advance into the next impulse. A bunch of stuff runs smoothly:
• Setting up units in all the various places in the sequence of play where units get placed on the map.
• All the declaration of war subphases.
• Simple phases such as: lend lease, scrap units, weather, initiative, naval air, and air rebase.

A couple of the beta testers were able to complete the setup for Brute Force. They did that carefully, thoughtfully placing units on the map, as well as making good decisions for the other aspects of starting a game. It took them two and a half hours but they had no problems. In other words, NetPlay connections seem to be both stable and reliable.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Both the Players Manual and Rules as Coded are in the hands of the Matrix Games graphics person, who is doing the final layouts for how those will appear as PDFs and in print.

Tutorials and Training Videos
I still have one bug to fix for the tutorial on Production (so production can be performed for multiple countries within the tutorial). Otherwise the tutorials are done.

I need to re-record the 6th and create the last three Training Videos: 10th, 11th, and 12th. The 6th (main form and drop down menus) needs redoing because I have seriously modified some forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics.

Historical Video, Music, and Sound Effects
I now have all the files I need as WAV files. To those of you who provided information that let us find the Italian national anthem during the war years, thank you! When I get a day or two free, I’ll insert the calls into the sequence of play to activate these glitz elements.

Marketing
Nothing new.








< Message edited by Shannon V. OKeets -- 6/3/2012 2:42:22 AM >

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 27
RE: MWIF Monthly Reports - 7/5/2012 9:31:30 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		July 1, 2012 Status Report for Matrix Games’ MWIF Forum

Project Management
In the first half of June I monitored all the threads in the MWIF World in Flames forum daily. Then I took another one of my 2 week vacations. This time is was for a heart attack and triple bypass surgery. I am sure that you will greet this information with as much joy as I did.

I was in the hospital for 12 days but got out a day earlier than the doctors’ had expected (4 days after the operation). The surgery itself went well and it is just a question of mending my body and my ways. For the latter, I have set up a structured daily routine, with meals at fixed time, as well as exercise and rest. There is an absolute maximum on the number of hours I can work (5 hours a day), but that is only if I am doing well and keeping up with my exercise and rest regimen.

Bypass surgery involves cutting open the sternum, rerouting the arterial blood flow to the heart muscle so the entire heart is getting oxygenated blood, using thin titanium threads to reconnect the bone back together and then suturing the skin tissue. Like for any other broken bone, the healing process is 6-7 weeks. Until then I can’t lift anything weighing 8 pounds or more.

I am being careful about going back to work. So far the only thing I have done is write this short status report. I’ll probably wait another couple of days before putting my task list back in order and up-to-date. Then I’ll ease the car back into gear and see how it runs on the straightaways.

Sorry that I don’t have better news.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 28
RE: MWIF Monthly Reports - 8/3/2012 3:45:03 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		August 1, 2012 Status Report for Matrix Games’ MWIF Forum

Accomplishments of June and July 2012

Project Management
As indicated by the title above, this report includes items that were done in June and July. My last month’s report hadn’t provided any details on June.

I am mending the MWIF code, mending my body, and mending my ways. It’s now 5 weeks since my bypass surgery and a month since I left the hospital. The Docs say I’m doing extremely well. I’ll see all 3 of them again in the middle of August. Hopefully that will be my last visit with the cardiac surgeon. The cardiologist says he will still want to see me annually. My visits to my internist are more frequent, monthly or bi-monthly. He draws blood each time and does a fairly full analysis of its chemical composition.

I’m taking a 1 hour walk each day, which is mostly boring, and my body is insisting on 10+ hours of sleep daily. That doesn’t leave a lot of time for work - which is just as well, since I have trouble staying focused for more than a couple of hours at a stretch. I’ve lost 24 pounds since I left the hospital, most of which was during the first 2 weeks. But I continue to lose a pound every 4 or 5 days. Weighing less is really great (45 pounds more to go) since it increases my flexibility and makes changing clothes a lot easier: my clothes are now oversized so they go on effortlessly and my pants fall off as soon as I undo the button at the waist.

In the first half of July I was pretty much good for nothing, although I did manage to bring my task list up-to-date. That was somewhat difficult to accomplish since I had dropped a lot of balls when I went into the hospital. It took me a while to figure out what I had actually completed and what was only partially done. Also the beta testers had reported a lot of items over the 3 week period I wasn’t keeping a close eye on them. I had to add all their new bug reports to my task list. In the second half of July I was able to get back to working on bugs again.

Hardware and Software
Matrix/Slitherine Games programmers made more revisions to the code at the NetPlay server end. I haven’t tested those changes yet. The goal is to cut the login time from 10 seconds to under 5 - perhaps that has been achieved.

The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file).

Beta Testing
In June I released new versions 9.07.08 (13 fixes), 9.08.00 (13 fixes), 9.08.01 (25 fixes), 9.08.02 (9 fixes), and 9.08.03 (10 fixes) to the beta testers. That totals 5 new versions and 70 fixes. I didn’t release a new version in July although I am close to doing so - I want to finish up the work on factory destruction and repair which just kept dragging on and on (more about that below).

I found another half dozen small items to fix in Production Planning. Simply going through the phase myself I found some small (mostly cosmetic) things to improve. While I was also able to whittled down the number of Production Planning bugs from 19 to something smaller, the beta testers quickly identified new bugs in that phase to bring the count back up to 19 - rats. In the middle of July I worked on eliminating all the remaining bugs in Production. That phase was working cleanly in almost all cases but there were a few odd elements that needed specialized code:
• Lend Lease air units mistakenly appearing in the build ahead pool
• Missing a separate row of possible units to build for SubHunters
• Repairing damaged oil resources (e.g., in Ploesti)
• Repairing damaged factories.

Saved Games
Only small changes to support SubHunters and damaged factories.

Map, Units, and Scenarios
For the start of Decline and Fall I changed control of New Caledonia and some other islands in the Pacific from Germany to France.

Optional Rules
In the Production form I added a new line for SubHunters to the list of items on which a player can spend build points. There is still more code to be written for SubHunters (e.g., for performing their missions) but at least now they can be built and arrive as reinforcements.

I spent over a week at the end of the month working on getting the code for damaging and repairing factories to work correctly (I still have a few small items to fix). CWIF had only completed about a third of this code. To start with I needed to determine what the rules were, which took me several passes and a lot of help from Orm. There is more on this at the end of this report. The optional rules for Construction Engineers and Factory Construction & Destruction necessitated a lot of branching logic.

Game Engine
Nothing new.

Player Interface
Nothing new.

Internet - NetPlay
Probably the biggest difficulty with NetPlay is getting the decision maker(s) for each phase, subphase, sub-subphase, and digression correctly identified on all computers, then having their decisions communicated to all players, and ultimately having the ‘phase’ end and transition to whatever comes next. Towards that goal, I modified the following to support NetPlay:
• Carpet bombing phase
• Strategic bombing phase
• Undoing land moves (reverting hex control to what it was previously on all computers)
• Weather phase
• Ground support phase
• Paradrop phase
• Land combat resolution phase
• Air transport phase
• Setup (combining multiple oil point counters in a hex into a single counter)
• DOW on minors, choosing the controlling major power, and setting up units for the attacked minor
• Displayed available Activity Counts (e.g., land moves, land attacks, etc.)
• Processing of a half dozen Naval Combat subphases - there are more to do, including the use of surprise points.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new: both the Players Manual and Rules as Coded are in the hands of the Matrix Games graphics person, who is doing the final layouts for how those will appear as PDFs and in print.

Tutorials and Training Videos
I still have one bug to fix for the tutorial on Production (so production can be performed for multiple countries within the tutorial). Otherwise the tutorials are done.

I need to re-record the 6th and create the last three Training Videos: 10th, 11th, and 12th. The 6th (main form and drop down menus) needs redoing because I have seriously modified some forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics.

Historical Video, Music, and Sound Effects
I now have all the files I need as WAV files. What’s needed is for me to insert calls into the sequence of play to activate these glitz elements.

Marketing
Nothing new.

=======================================================

Here are my in-line code comments on factories. The first section describes the MWIF internal Class TFactoryHex, supplemented by my understanding of the rules. The second section presents a more detailed explanation of how the rules are implemented by MWIF (e.g., what routines get called when). I almost always start coding a complex set of rules with this sort of writeup. The nitty-gritty implementation details are added as I code. What I find so useful about this approach is that by reading through what is suppose to happen I can often anticipate problems in advance of actually writing code. In addition, if I need to make changes later, I have this clear and concise description of what the code is doing as a quick reference.

// ****************************************************************************
// Class TFactoryHex.
//
// A TFactoryHex can contain up to 3 factories. The factories in the hex are
// differentiated using an index (0-2). Red factories are always listed first
// followed by Blue and then Green. Printed factories are designated Permanent
// internally.
//
// Green factories are those that were newly built (i.e., they are not
// Permanent).
//
// There is only one difference between Blue and Green factories:
// (1) Blue factories that are 'destroyed' are merely Damaged, and moved to the
// Repair Pool, while 'destroyed' Green factories are removed from the game.
//
// Factories can only be 'destroyed' if playing with the optional rule
// FactoryConstruction (which includes the rules for factory destruction). Note
// well that the following paragraphs about destroying, damaging, and repairing
// factories only apply if the optional rule FactoryConstruction is being used.
//
// There are 2 ways in which a factory can be 'destroyed':
// (1) By strategic bombing,
// (2) During the Factory Destruction phase when a major power chooses to
// destroy a Blue or Green factory using one of its land units that occupies
// the hex.
//
// If a Red or Blue factory is 'destroyed', by any means, then it becomes
// damaged and a unit representing the damaged factory is placed in the Repair
// Pool. If a Green factory is 'destroyed', it is removed from the game.
//
// Repair of a damaged factory in the Repair Pool is initiated during the
// Production phase by spending build points to repair the factory. The factory
// then arrives as a future 'reinforcement'. In actuality, upon arrival the
// factory simply changes from damaged to usable.
//
// If using the optional rule ConstructionEngineers, then an engineer unit must
// be in the factory's hex during the Production phase in order to spend build
// points to repair the factory.
//
// Both Captured and Recaptured (see below for definitions) Red factories are
// not usable if using the optional rule ConstructionEngineers until an engineer
// unit is in the factory's hex during the Production phase. There is no build
// point cost to make these factories usable.
//
// ++++++++++++++++++++++++++++++++++
// Code Implementation for factories.
// ++++++++++++++++++++++++++++++++++
// A factory typically has no associated unit counter. Instead, the factory is
// displayed as an icon in the hex. For example, this is true for all Permanent
// (Printed) factories. Temporary factory units are created under four
// circumstances, when:
// (1) a new factory is built [FactoryCreate -> RLID_UCrF -> PickFactory],
// (2) a factory is moved [FactoryCreate -> RLID_UCrF -> PickFactory],
// (3) a factory is damaged [DamageAFactory -> RLID_FacD ->
// FactoryDamagedOnMap -> FactoryDamage ->
// PickFactory, and
// (4) an undamaged Blue or Green factory is controlled by the enemy
// [SetHexControl -> TFactoryHex.SetOwner -> PrepareMoveReservePool /
// PrepareMoveRepairPool /
//
// In all these cases the temporary factory units are placed in off-map pools so
// players can see the status of factories that are not currently usable but
// which may become usable in the future.
//
// Building a new factory causes a New Factory unit to be created and placed in
// a Production Pool. Once the factory arrives as a 'reinforcement', the New
// Factory unit is removed from the game and the factory icon in its arrival hex
// is modified to display a new Green factory.
//
// Moving a Blue or Green factory by rail causes a Moving Factory unit to be
// created and placed in a Production Pool. Once the factory arrives as a
// 'reinforcement', the Moving Factory unit is removed from the game and the
// factory icon in its arrival hex is modified to display a new Blue factory.
// Some scenarios start with the USSR having Moving Factory units in the Setup
// tray and/or a Production Pool. The USSR player can placed these factories in
// any valid city hex in the USSR. However, all factories that are moved during
// a game have their destinations specified by the player when they are first
// moved. Those destinations cannot be changed and the factory must arrive in
// the city hex originally chosen by the player.
//
// 'Destroying' a Red or Blue factory during strategic bombing causes a Damaged
// Factory unit to be created and placed in the Repair Pool. Destroyed Green
// factories are simply removed from the game.
//
// When control of a factory hex changes sides, there are 2 possibilities:
// (1) the factories are 'Captured' by the enemy, or
// (2) the factories are 'Recaptured' by the side that originally controlled it.
// For instance, Germany occupying Lille 'Captures' the factories in the hex;
// while if the Allies later occupy Lille, then they 'Recapture' the factories.
//
// Capturing or Recapturing a factory hex containing damaged factories does not
// affect the damaged factories, unless they are in the process of being
// repaired. If they are being repaired, then that process is aborted and the
// damaged factory units are returned to the Repair Pool.
//
// Undamaged Blue and Green factories are never usable when Captured, but are
// immediately usable when Recaptured.
//
// Undamaged Red Factories are immediately usable by the new owner when they are
// Captured or Recaptured, unless the optional rule ConstructionEngineers is
// being used. If the optional rule ConstructionEngineers is being used, then
// for each undamaged Red factory in a Captured or Recaptured factory hex, a
// TFactory unit is created and placed in the Repair Pool.
//
// When a factory hex is Recaptured, for each undamaged Blue and Green factory,
// there should be a TFactory unit in the Reserve Pool. That unit is removed
// from the game and the corresponding Blue/Green factory immediately becomes
// usable by the original owner.
//
// If during the Factory Destruction phase a Blue factory is destroyed, its
// TFactory unit in the Reserve Pool is converted to a Damaged Factory unit and
// moved into the Repair Pool. Destroying a Green factory causes its Factory
// unit in the Reserve Pool to be removed from the game.
//
// During the Production phase, a check is made to see if there are any TFactory
// units for Red factories in the Repair Pool. If one is found, a check is made
// for an engineer unit in the corresponding factory hex. When an engineer unit
// is found in the hex, the TFactory units is destroyed and the Red factory becomes
// usable.
//
// During the Production phase, a player may repair damaged factories using
// build points. If using the optional rule ConstructionEngineers, then an
// engineer unit must be in the factory's hex. When a factory is repaired, the
// Damaged Factory unit for the repaired factory is moved from the Repair Pool
// to a Production Pool to arrive as a reinforcement. Upon arrival, the Damaged
// Factory unit is removed from the game [ProcessReinforcement -> RLID_FcRp ->
// FactoryRepair] and the factory is shown as usable on the map (and in the
// Production Planning form).
// ****************************************************************************




_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 29
RE: MWIF Monthly Reports - 9/3/2012 8:36:19 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline 		September 1, 2012 Status Report for Matrix Games’ MWIF Forum

Accomplishments of August 2012

Project Management
I monitored all the threads in the MWIF World in Flames forum daily. Regrettably, I was only able to work effectively 3+ hours a day in August. More about my health in the next 2 paragraphs, but feel free to skip that.

I had a final visit with my cardiac surgeon, who says I’m doing fine. My cardiologist wants to see me again in October, mainly because I was only using 95% of my full lung capacity - I think that has been rectified in the two weeks since I saw him. Likewise my internist wants to see me again in October, when he’ll draw blood and do an analysis of its chemical composition. When they did that 2 weeks ago, my blood sugars were back to normal so I am no longer taking insulin. I’ve also cut my dosage of one med in half to 12.5 mg twice a day. That med was making me sleepy and impairing my ability to focus (i.e., work on code). After reducing that med a couple of days ago, I’ve increased my work hours to 4 a day. I would like to get back to 5-6 hours productive hours. Right now I am taking low dosages of 4 meds daily, which I guess will continue for the foreseeable future.

This coming week, as a scheduled 6 month followup, I’ll have sonography done on my kidneys, looking for kidney stones. That should be a non-event since I routinely drink 60-80 ounces of water/milk per day, which aggressively flushes my kidneys. The following week I’ll be in Philadelphia for 5 days for a scheduled annual followup on my eye surgery (on my left eye). I hope I can persuade them to let me have the cataract in my left eye removed and replaced with an artificial lens. The radiation treatment appears to have accelerated the formation of that cataract. In May I was able to read text with my left eye, but now it is so bad I can’t use it to count my toes.

Hardware and Software
Matrix/Slitherine Games programmers made more revisions to the code at the NetPlay server end. I haven’t tested those changes yet. The goal is to cut the login time from 10 seconds to under 5 - perhaps that has been achieved.

The open items for Theme Engine remain unchanged: (1) scroll bars for the detailed map, and (2) its inability to display detailed listings of file directories (i.e., the dates and stuff when opening or saving a file).

Beta Testing
In August I released new versions 9.08.04 (12 fixes), 9.08.05 (13 fixes), and 9.08.06 (14 fixes) to the beta testers. That’s only 3 new versions and 39 fixes. I’ve made 8 more fixes for version 9.08.07, but I won’t release that until I’ve gotten my rewrite of the supply determination code done (there is a long discussion of that in Game Design below).

I whittled away at the air/naval/land movement and combat bugs. I now have these down to 17 total, some of which are important, some of which are not, and some of which are so old I am not even sure they still exist. 17 is a small enough number that if I just bear down on them for a week, I should be able to eliminate them all.

Saved Games
I added a couple of AutoSave calls so they happen whenever a new major power has something to do in the Reinforcement phase. I also added the subphase to the name of the saved game file for that phase.

Map, Units, and Scenarios
I received some more naval unit writeups from Warspite.

Optional Rules
I fixed a couple more bugs in the optional rule Off-city Reinforcements where it had interactions with the optional rules for Territorials and Divisions.

I improved the display of information in the Universal Unit Data Panel on lost production points and damaged factories. The UUDP is part of the omnipresent Main form, so when the player moves the cursor over a hex, the UUDP updates with information on how many production points have been lost to strategic bombing and the status of factories in the hex. Also included is info on damaged oil resources (e.g., in Ploesti). During game play it’s important to know these things when planning strategic bombing missions.

Game Engine
The beta testers have been nagging me for a long time to fix the bugs in (mostly overseas) supply. My solution for the various supply bugs was to rewrite the CWIF code from scratch. I completed most of that last year:
1. identifying valid primary supply sources for major powers and minor countries,
2. identifying possible secondary supply sources for same,
3. identifying valid secondary supply sources by finding a railway path to a primary supply source,
4. using overseas supply links for secondary supply sources only when no pure land link exists,
5. identifying which valid supply sources can be used by cooperating major powers and aligned minor countries,
6. determining which units are in supply by tracing a link composed of basic path hexes overland and/or overseas to a valid supply source.

I devoted the last half of August to working on supply. There were some bugs in the last item listed above that I just spent the last 6 days tracking down and correcting (hence this report being late). What was completely uncoded was identifying tertiary supply sources: those are potential secondary supply sources which could not trace a railway path to a primary, but can trace to either a valid secondary or tertiary.

As of today I’ve fixed all the bugs in the supply code I’ve written, and I have tertiary supply working for major powers. Still left to do is:
7. writing code to differentiate between tertiary supply sources which are ‘pure’ for a major power and those which rely on supply sources from cooperating major powers; the latter cannot be used by minor countries,
8. taking the code for determining tertiary supply for major powers and cloning it for minor countries,
9. writing a routine to determine if a supply path, that was previously valid, is still valid; this will drastically reduce the time required to recalculate supply,
10. check and evaluate when supply is calculated/recalculated during game play (the beta testers have reported instances when it hasn’t been recalculated when it should have),
11. reduce the time required to calculate supply the first time (i.e., from scratch).

All except the last item are straightforward. Getting the time down to under 3 seconds for the original supply determination is going to be difficult. For small scenarios, like Barbarossa and Guadalcanal, calculating supply is always instantaneous. That’s also true for scenarios where there aren’t many units on the map (e.g., at the start of the Global War scenario). But for the later scenarios, like Brute Force and Decline and Fall, where there are hundreds of units spread out all over the map, the original supply calculation is taking 1-2 minutes, which is totally unacceptable. I need to do some more timing studies to see where the program is spending/wasting all that time. One place is when it tries to find a railway supply path for the Commonwealth from Baghdad to India, going through the USSR, China, and Burma. For instance, it is conceivable that a railway path could be found from Baghdad through the USSR and China to the rail hexes in Burma and overland to the rail hexes in India and then to a primary supply source; or from Baghdad to Murmansk and from there overseas to England. I’ve timed that [failed] search at ~15 seconds. I have a plan for how to reduce it drastically, but that will require some new code.

I should be able to finish up supply in the first couple of weeks of September. While I am working on this, I set virtually everything else aside. It takes my full involvement in the supply code (11,000+ lines) to keep it straight in my head. Side jaunts into naval combat and production planning have to be delayed for later.

Here are 4 screenshots of supply determination in MWIF. The units’ supply status indicators, some of which are incorrect, were calculated using the old CWIF code.

In the upper left von Bock is supplying units in the Crimea, during rain, via the Black Sea. Because von Bock is in the port Nikolayev, the basic path hex (BPH) cost from the Black Sea is only 1. That’s shown in the path for the 5th Mtn. Division. It also lets the Alpine mountain corp trace 1 BPH to the port Evpatoria (which the Italian units are occupying) and 1 BPH to von Bock for a total of 2 BPH (in rain the maximum BPH for a path is 2). I think many over-the-board WIF players are likely to not see this path - I was surprised and thought it was a bug at first. In the upper right screenshot, von Bock has moved 1 hex east of Nikolayev but the 5th Mtn. Division is still in supply by going through Nikolayev to reach von Bock.

The screenshot in the middle of the figure shows Rommel as a tertiary supply source tracing to Graziani (who is in an adjacent hex). Graziani then traces through Benghazi to the Eastern Med and from there to Greece and ultimately to a primary supply city in Italy (Graziani’s supply path is not shown). Note that as a tertiary supply source Rommel is able to provide supply to 3 other German units in North Africa. The Commonwealth units are out of supply (yellow status indicators in the upper right of the unit counter) because they do not have a convoy or transport in the Eastern Med.

The fourth screenshot, at the bottom of the figure, shows Balbo as a tertiary supply source in Iraq, tracing to Graziani in Syria. Graziani is a secondary supply source and his supply path back to Genoa is shown above the screenshot on the right. Guderian is also a tertiary supply source - he traces to Balbo.

Appended at the end of this report is an overview of the MWIF process for determining supply, with some of the variables involved.

Player Interface
Nothing new.

Internet - NetPlay
I went through half of the 28 Naval Combat subphases revising them to support NetPlay (I still need to do the other half). This entails making sure that the players controlling the major powers that need to make decisions are given the opportunity to make those decisions, and that the other players are informed about which major powers need to decide. As decisions are made everyone is kept informed, and once all necessary decisions have been made, the program advances to the next subphase. What is especially tricky about this is making sure the opportunity to spend surprise points is offered to the player who has surprise points to spend - those decisions intrude on the normal sequence of play in several places.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new: both the Players Manual and Rules as Coded are in the hands of the Matrix Games graphics person, who is doing the final layouts for how those will appear as PDFs and in print.

Tutorials and Training Videos
I still have one bug to fix for the tutorial on Production (so production can be performed for multiple countries within the tutorial). Otherwise the tutorials are done.

I need to re-record the 6th and create the last three Training Videos: 10th, 11th, and 12th. The 6th (main form and drop down menus) needs redoing because I have seriously modified some forms since I recorded that video in December of 2009. The last 3 training videos are for naval movement, naval combat, and production/politics.

Historical Video, Music, and Sound Effects
I now have all the files I need as WAV files. What’s needed is for me to insert calls into the sequence of play to activate these glitz elements.

Marketing
Nothing new.


// ****************************************************************************
// For determining supply, the following sequence of tasks is performed:
//
// Primary Supply Sources.
//
// 1 - Identify fixed primary supply sources for each major power and all minor
// countries that are at war. Primary supply sources are cities in the home
// country. The country cannot be conquered and the city has to have been
// controlled for the entire turn. All Commonwealth member nations are
// equivalent in providing primary supply sources for the Commonwealth.
// 2 - Add to the list of fixed primary supply sources identified in #1, the
// primary supply sources from major powers with which a country cooperates.
// 3 - Identify mobile primary supply sources for each major power and all minor
// countries at war. These are either: (1) an HQ on which a Supply Point
// has been expended this turn, or (2) an HQ which has been used to provide
// Emergency Supply this impulse. An HQ providing Emergeny Supply has slots
// which identify the units being so supplied. The number of slots equals
// the HQ's reorganization number (maximum of 5). For an HQ to serve as a
// primary supply source for a country, the HQ has to cooperate with the
// given country.
//
// Secondary Supply Sources.
//
// 4 - Identify fixed secondary supply sources for each major power and minor
// country. For a major power these are either:
// (1) the capital of a controlled/aligned minor country or
// (2) the capital of a conquered country (major or minor).
// For a minor country, only cities in (2) are secondary supply sources.
// Since both (1) and (2) are cities, the city has to have been controlled
// for the entire turn.
// 5 - Identify mobile secondary supply sources for each major power and all
// minor countries that are at war. These are simply HQs that are on land.
// For an HQ to serve as a secondary supply source for a country, the HQ has
// to cooperate with the given country.
//
// Railway Paths from Secondary Supply Sources to Primary Supply Sources.
//
// A - These paths are Railway Paths regardless of whether a rail link is used
// or not.
// B - The shortest path is taken, without using an overseas link if possible.
// This permits the use of the single overseas link to be preserved for use
// by another link.
//
// 6 - Find the shortest path from each fixed secondary supply source to a fixed
// primary supply source. For a primary to supply a secondary, the owner of
// the primary has to be the major power that aligned or conquered the
// secondary.
// 7 - Find the shortest path from each fixed secondary supply source still out
// of supply to a mobile primary supply source. For a primary to supply a
// secondary, the owner of the primary has to be the major power that
// aligned or conquered the secondary.
// 8 - Find a path from each mobile secondary supply source to the closest fixed
// primary supply source. For a primary to supply a secondary, the owner of
// the primary has to be a major power with which the secondary cooperates.
// 9 - Find a path from each mobile secondary supply source still out of supply
// to the closest mobile primary supply source. For a primary to supply a
// secondary, the owner of the primary has to be a major power with which
// the secondary cooperates.
//
// Basic Paths from Tertiary Supply Sources to Secondary or other Tertiary
// Supply Sources.
//
// C - A tertiary supply source is a secondary that cannot establish a Railway
// Path to a primary supply source.
//
// 10 - If there is no secondary supply source for a major power, then there are
// no tertiary sources either. For all tertiary supply sources that are out
// of supply, find a Basic Path to a secondary or tertiary that is in
// supply. Repeat this until all tertiary supply sources are in supply or
// until the previous pass through this routine caused no new additions to
// the list of in-supply tertiary supply sources.
//
// Basic Paths from units to Primary, Secondary, or Tertiary Supply Sources
//
// 11 - Find the shortest path for all non-HQ units on land to a primary,
// secondary or tertiary supply source. To be a valid supply source for a
// unit, the source must be controlled by a country with which the unit
// cooperates. Some units do not need supply: Forts, Partisans, Synthetic
// Oil Plants, Supply Units, and Oil and Build Points. If a path can not
// be found of any length, the unit is isolated. If a path exists but is
// too long, the unit is out of supply.
// ****************************************************************************

The following variables are for each major power and each minor country that has units on the map.

// ****************************************************************************
// Variables for supply links, connections, and paths. Since these are primary
// sources, they are always valid supply sources.
//
// Entries in any Coop list only provide supply for SubC.
// For minor countries these are the supply sources directly controlled by their
// controlling major power. For instance, German primary supply sources, HQs,
// and the capitals of conquered countries can provide supply any minor country
// aligned to Germany. Note that many supply sources that are available to
// Germany are not available to Germany's aligned minor countries. For
// instance, the capitals of aligned minor countries do not provide supply to
// other aligned minor countries. Similarly, secondary suply sources for
// cooperative major powers do not provide supply to any of the minor countries
// aligned to Germany.
//
// For major powers Coop entries can include supply sources from cooperative
// major powers and from aligned minors. Although in the latter case only HQs
// and capital cities provide supply, and then it is secondary supply.
// ****************************************************************************
PriSupCities: TSupplySourcesList;
PriSupHomeCities: TSupplySourcesList; // For conquered territorials.
PriSupHQsTurn: TSupplySourcesList;
PriSupHQsImpulse: TSupplySourcesList;
PriSupAlignHQsTurn: TSupplySourcesList;
PriSupAlignHQsImpulse: TSupplySourcesList;
PriSupCoopCities: TSupplySourcesList;
PriSupCoopHQsTurn: TSupplySourcesList;
PriSupCoopHQsImpulse: TSupplySourcesList;
// ****************************************************************************
// The secondary sources with All at the end are all possible secondary sources.
// ****************************************************************************
SecSupCitiesAll: TSupplySourcesList;
SecSupHQsAll: TSupplySourcesList;
SecSupCitiesAlignAll: TSupplySourcesList;
SecSupHQsAlignAll: TSupplySourcesList;
SecSupCitiesCoopAll: TSupplySourcesList;
SecSupHQsCoopAll: TSupplySourcesList;
// ****************************************************************************
// These secondary and tertiary variables have valid supply connections back to
// a primary supply source. Both secondary and tertiary are subsets of the
// secondary supply sources listed immediately above. The difference between a
// secondary and a tertiary supply source is that only the former can trace a
// rail path to a primary supply source.
// ****************************************************************************
SecSupCities: TSupplySourcesList; // Active lists are subsets.
SecSupHQs: TSupplySourcesList;
SecSupCitiesAlign: TSupplySourcesList;
SecSupHQsAlign: TSupplySourcesList;
SecSupCitiesCoop: TSupplySourcesList;
SecSupHQsCoop: TSupplySourcesList;

TerSupCities: TSupplySourcesList;
TerSupHQs: TSupplySourcesList;
TerSupCitiesAlign: TSupplySourcesList;
TerSupHQsAlign: TSupplySourcesList;
TerSupCitiesCoop: TSupplySourcesList;
TerSupHQsCoop: TSupplySourcesList;

OOSUnits: TUnitStack;




Attachment (1)

_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 30
Page:   [1] 2 3 4 5   next >   >>
All Forums >> [New Releases from Matrix Games] >> World in Flames >> MWIF Monthly Reports Page: [1] 2 3 4 5   next >   >>
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

3.281