MWIF Monthly Reports

[Shannon V. OKeets]

August 2, 2019 Status Report for Matrix Games’ MWIF Forum

Product Releases
The beta testers received a few new versions in July, but there were no new versions released to customers. I’m working on getting a Hot Patch out early in August for customers with the same changes that the beta testers have already had for the last few weeks.

Program Development: Delphi Rio (version 10.3)
My new computer system is fully functional except for a couple of rarely used applications still on my old machine.

The Delphi Rio Interactive Development Environment remains a little flaky. It compiles all the code cleanly and then builds a new correct executable (MWIF.exe) but ends the process by crashing the IDE. On the old system it did the same thing and I thought it was because I was running both Delphi EX8 and Delphi Rio on the same machine. But the new machine was a virgin when I installed Delphi Rio. None of the files from Delphi XE8 is on the new computer system, I’ll have to go back to Embarcadero and get them to look into this some more. After all, I’m paying them $800 a year to provide customer support for Delphi.

I‘m still maintaining two copies of the MWIF source code. One for the old version of the Delphi Interactive Development Environment (IDE) called XE8. That is on the old computer. I run it when I need to make a version for release to customers. The beta testers are working with the version created using Delphi 10.3 Rio.

If I can build up enough confidence in the Delphi Rio executable, I’ll make a MWIF,exe version using it for the next Public Beta. However, that version requires a new set of BPL files be included when it is installed on the customers’ computers. BPLs are the Delphi/Borland equivalent to Microsoft’s DDLs.

Bugs
This past month I have done some work on my task list for emailed bug reports. But every time I catch up, a few more dribble in. Mostly I have been fixing bugs reported by the beta testers over the past couple of months. With that task I have been somewhat successful in cleaning up a variety of weird/unusual problems.

Next up is to go through the bugs reported in the Tech Support forum and correct any of those that are reproducible. With NetPlay bugs I have found converting the GAM files from NetPlay mode to Head-2-head play works more than half the time. That lets me debug the problems without having to set up and run a second computer to recreate the problem.

As of today, Slitherine has partially fixed the problem with creating New Posts (for the Seeking Opponents data base) in the NetPlay Private Forum. We almost have that fully functional again.

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

AI Opponent (AIO)
Nothing new in July.

[Shannon V. OKeets]

September 6, 2019 Status Report for Matrix Games’ MWIF Forum

Product Releases
One Hot Patch (version 3.0.3.0) was released in early August for customers. Meanwhile, the beta testers received a lot of new versions. We are now up to version 4.0.0.29 for them testing MWIF compiled using Delphi Rio (version 10.3). I am presently working on creating another Hot Patch for customers using the old version of Delphi (XE8). That will be version 3.0.4.0. A comparable version (4.0.0.30) will be available to the beta testers compiled with Delphi Rio.

If those two versions run cleanly for a week or so, I’ll send off version 4.0.1.0 (created using Delphi Rio) to Matrix Games for release as a Public Beta for customers. My expectation is that will appear for all players in mid September. It will require players to install a set of BPLs besides the usual MWIF.exe. But because it will be a public beta, the installation of the additional files will be handled automatically as part of the install.

In addition to fixing a bunch of bugs in the game, I added the 2 Die 10 Land Combat Results Table to the Help menu. See the screenshots below.

Program Development: Delphi Rio (version 10.3)
My new computer system remains fully functional except for a couple of rarely used applications still on my old machine.

The Delphi Rio Interactive Development Environment is still a little flaky. I have learned that if I merely do a full compile - and NOT a full build - the IDE creates an accurate MWIF.exe without trouble. The difference between the two ways of creating the MWIF.exe, is that a build also creates all the BPLs for the MWIF specific libraries. BPLS, are Borland’s file extension for what Microsoft labels DDLs. Basically, they are binary library files that the primary program (i.e., the executable - MWIF.exe) accesses when it executes. I only have to make changes to the MWIF specific libraries once every couple of years, so leaving the BPLs unchanged is perfectly fine.

I am hoping that the public beta version 4.0.1.0 runs cleanly and I can put Delphi version XE8 firmly in my rear view mirror, never to be used again.

Bugs
For the first two weeks of August, I focused on fixing bugs reported in Tech Support and by the beta testers. I was able to clear more than 20 of those, which was roughly 2/3rds of those reported in the past 4 months What remains are either obscure bugs or quite difficult to reproduce. For the following 3 weeks I spent all my time on NetPlay bugs. Some of those were way more difficult to resolve than I would have preferred. Here is one fix:

Substantially modified the routines for naval air combat, specifically for the air-to-air combat dice rolls. By splitting some routines into their component parts, I was able to better control when messages (i.e., Game Record Logs - GRLs) about dice rolls and other events are sent from one player to the other. The main problem these changes corrected was that at times the computer wasn’t rolling the dice for the attacking player (the defending player rolls first) - or rolling twice for a player. Other fixes include: (1) correcting the program halting after the first player decides whether to Abort or Stay in an air-to-air combat, (2) eliminating a spurious second prompt for a player to decide whether to Fight or Abort after a round of naval combat, and (3) getting rid of an occasional extra display of the Anti-Aircraft Fire form (the player owning the attacking bombers should always decide which bombers suffer the damage of the AA fire - and only once).

For a short period of time in August, the Seeking Opponents data base in the NetPlay Private Forum was working correctly again. But when Slitherine modified the overall appearance of their web site, it again became inaccessible. I need to send them some information so they can get that back in working order. For now, everyone can continue to able to play NetPlay games normally. It merely requires ignoring a single message when starting about being ‘Disconnected’, which only applies to the Seeking Opponents database.

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

AI Opponent (AIO)
Nothing new in August.

[Shannon V. OKeets]

October 4, 2019 Status Report for Matrix Games’ MWIF Forum

Product Releases
As of today, the Seeking Opponents data base in the NetPlay Private Forum is accessible again. They just had to restore the data from backup.

One Hot Patch (version 3.0.4.0) was released in early September for customers. Meanwhile, the beta testers received a few new versions. We are now up to version 4.0.0.32 for them testing MWIF compiled using Delphi Rio (version 10.3).

There were some problems with 3.0.4.0 which I have fixed. Similarly, further testing of NetPlay revealed a couple of obscure bugs that I corrected. My plan is to review the recently emailed bug reports (Mad Excepts) for versions 3.0.x.x and see if I can figure out what caused those problems. It is difficult without saved games accompanied by a description of what the player was doing prior to the Mad Except error. But sometimes a clear vision of the situation arises out of the fog.

Once I have done my best with the emailed bug reports, I’ll post a new Hot Patch and let players run it for a week or so. If all looks well, I’ll send off version 4.0.1.0 (created using Delphi Rio) to Matrix Games for release as a Public Beta for customers. That version will require players to install a small set of BPLs besides the usual MWIF.exe. Because it will be a public beta, the installation of the additional files will be handled automatically as part of the install.

Program Development: Delphi Rio (version 10.3)
My new computer system remains fully functional except for a couple of rarely used applications still on my old machine. Having run it for 3 months I am now appreciating its increased performance for even routine tasks. At about the same time my internet provider changed the layout for their email server. That was very annoying at the time, since nothing was where I expected it to be and even some of the icons had been changed. But after adapting to the new stuff, I now see that it is an improvement and I can get work done faster and with less mouse moves/clicks.

I am 8 months into using the Delphi Rio Interactive Development Environment and have gotten used to where its quirks are (“Don’t do this!”). I like it better that the old one. Using white text on a black background really helps my eyes. The moral of all this is that changes are a pain - but usually they are for the better.

Bugs
I am up-to-date on all emailed bug reports as of the end of September. Likewise for the Tech Support posts. I need to look at the beta tester bug reports again - it’s been a few weeks since I examined those fully.

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

AI Opponent (AIO)
Nothing new in September.

[Shannon V. OKeets]

November 9, 2019 Status Report for Matrix Games’ MWIF Forum

I’m really late with this month’s report - sorry about that. I was in California with my chorus for a competition in October and pretty much lost a week of work. Luckily we missed all the fires, though a few chorus members were stuck in Los Angeles over night because of all the power outages.

Product Releases
As of yesterday, the Seeking Opponents data base in the NetPlay Private Forum is accessible again. This problem has been on again, off again over the last couple of months. The latest fix was to remove a Redirect pointer in the Slitherine/Matrix NetPlay server that was referencing a non-existent source for the database. After removing the spurious Redirect pointer, the server was able to ‘find’ the Seeking Opponents database - and all is well. The most recent post I saw was from October 30th.

No Hot Patch was released in October for customers. Meanwhile, the beta testers received a few new versions. We are now up to version 4.0.0.38 for testing MWIF compiled using Delphi Rio (version 10.3). I will try to post a Hot Patch this coming week (version 3.0.5.0) generated using the old Delphi XE8 - which will have source code identical to that used to create the impending version 4.0.0.39.

Program Development: Delphi Rio (version 10.3)
My new computer system is fully functional, although eventually I should transfer over a couple rarely used applications from on my old machine (e.g., CorelDraw).

Because the versions of MWIF created using Delphi Rio require replacement BPL (a.k.a. DDL) files, I am holding off on generating a Delphi Rio MWIF - version 4.1.0.0 - as a Public Beta until I see a version generated under the old Delphi (XE8) running with no issues. Presently, that would be version 3.0.5.0.

Bugs
I made a serious pass through all the remaining emailed bug reports in 2019, without finding anything of note to change. Mostly I inserted a few checks to avoid non-fatal errors (these pop up when quitting the game when the program is expecting a form to be completed (e.g., Choose Action).

After spending a lot of time looking into Supply calculations taking too long, I came up with only a couple of small changes. The program had been trying to find paths between supply sources belonging to cooperating major powers and aligned minors. For example, Germany typically has Italy as a cooperating major power and Rumania as an aligned minor country. All that code was useless. Cooperating major power supply sources and aligned minor country supply sources can never be on the same supply path. That’s because they do not cooperate (e.g., Italy does not cooperate with Rumania). So I trashed about 1500 lines of code (commented it out actually). That should speed things up a little.

Another bug I explored for supply calculations taking too long was from an old game. 10 days of effort later I figured out that the game was damaged. An old bug having to do with France being completely conquered and then rising from the dead when one of its old minor countries is liberated, left the Relationships data between major powers and minor countries all screwed up. [That bug has long since been fixed.] France was recorded as being at war with a slew of still-neutral minor countries (e.g., Switzerland and Turkey). The program was treating hexes in those minors as possible supply routes for both sides (Axis and Allied). A ton of time was spent searching uselessly for supply paths.

All in all, my time spent looking into speeding up supply calculations wasn’t fruitful. I have an internal time monitor for supply calculations, breaking it down into a dozen or so pieces. The amount of time spent on each piece is reported so I can tell where the program is expending the most effort. But that depends on the individual game. In some games, a lot of time is spent determining whether Secondary supply sources can trace a path to Primary sources. In other games, it is the search for Overseas supply paths that burns the time. In yet third instances, searching for Tertiary supply paths back to Secondary is where the program takes excessive time. Very frustrating to not be able to identify one place that misbehaves in every case.

So, I have put working on speeding up supply calculations in abeyance for the nonce. That means that working on the optional rule Isolated Supply has also been set aside.

I’ll now select another missing Optional Rule to implement.

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

AI Opponent (AIO)
Nothing new in October.

[Shannon V. OKeets]

December 2, 2019 Status Report for Matrix Games’ MWIF Forum

Product Releases
No Hot Patch was released in November for customers. Meanwhile, the beta testers received a few new versions. We are now up to version 4.0.0.43 for testing MWIF compiled using Delphi Rio (version 10.3).

I have a new Hot Patch ready to compile (version 3.0.5.0), but I need to write the Release Notes. Also, because it needs to be generated using the old Delphi XE8, I have to copy the modified source code over to my old computer and compile it there. Version 3.0.5.0 will use source code identical to that used to create version 4.0.0.43.

Program Development
I made some improvements to the Pools form and the View Units form. For the Pools form, I added a small table that shows the number of convoys and pilots lost by each major power during the turn. Those counts are reset to zero at the beginning of each turn. The table appears when viewing the Destroyed Pool.

In addition, I changed the layout for the Pools form, so instead of seeing 4 by 13 units (52) on a small screen size (1024 by 768), it now shows 6 by 9 units (54). That is a minuscule increase but there is a larger payoff when the form is resized horizontally. That can be done if you have a wider monitor. For each new column you now see 6 more units instead of 4. In Barbarossa, 15 columns shows all the units in the USSR force pool. 21 columns shows all the German units.

As my third little side project, I modified the View Units form (Ctrl - U). It can now be resized vertically. With a monitor that has 768 pixels vertically, the form shows 14 units in a single column. My monitors have a vertical resolution of 2160. When the form is expanded to fill that monitor vertically, 27 units are visible.

Because the versions of MWIF created using Delphi Rio require replacement BPL (a.k.a. DDL) files, I am still holding off on generating a Delphi Rio MWIF - version 4.1.0.0 - as a Public Beta until I see a version generated under the old Delphi (XE8) running with no issues. Presently, that would be version 3.0.5.0.

Bugs
I am up-to-date with bugs reported via email and in the Tech Support forum for World in Flames. For bugs reported by beta testers, I am up-to-date except for three that I need to understand a little better before I can add them to my task list.

Missing Optional Rules & Half Map Scenarios
Added the code for Kamikaze pilots for the Japanese. Began work on the Rough Seas optional rule.

AI Opponent (AIO)
Nothing new in November.

[Shannon V. OKeets]

January 6, 2020 Status Report for Matrix Games’ MWIF Forum

Product Releases
Hot Patch 3.0.5.0 was released in December for customers. Later in the month that was superceded by a Public Beta version 3.1.0.0 and, just before Christmas, Hot Patch version 3.1.0.1. Also during December, the beta testers received 5 new versions, the latest being 4.0.1.3. As before, the versions for the customers were compiled using Delphi XE8 and the beta tester versions using Delphi Rio (Delphi version 10.3).

Program Development
Because the versions of MWIF created using Delphi Rio require replacement BPL (a.k.a. DDL) files, I am still holding off on generating a Delphi Rio MWIF - version 4.1.0.0 - as a Public Beta until I see a version generated under the old Delphi (XE8) running with no issues. Presently, that is version 3.1.0.1.

Bugs
I am up-to-date with all bugs reported in December: via email, in the Tech Support forum for World in Flames, and those reported by beta testers, There are always a few more dribbling in. Lately I have been more successful in staying current in reviewing new bug reports. I’ve even been able to go back and tackle some of the older bug reports.

In December, the older ones I have been looking at are for NetPlay. In my game with Gerry, and other NetPlay games played by beta testers, naval operations have been getting rather intense. The US is fully in the war, and Italy has just been conquered. What all that means in game terms is that naval movement and combat in the Pacific has been constant every turn, almost every impulse. Not to be neglected, the Commonwealth and Axis have continued to fight it out for control of the Mediterranean. Virtually every aspect of naval movement and combat has been getting a rather thorough testing. Odd problems have popped up, which I have been hammering down, sort of like ‘whack-a-mole’ at times. Whenever I go after fixing one of these, I check to see if anything similar has been reported previously. Many times I can fix the old and the new with a single set of changes to the code.

Missing Optional Rules & Half Map Scenarios
Nothing new in December. I’ll get back to working on these in January.

AI Opponent (AIO)
Nothing new in December.

[Shannon V. OKeets]

February 9, 2020 Status Report for Matrix Games’ MWIF Forum

Rats, I am late again with the status report. My chorus responsibilities are heating up. I’m scheduler and dispatcher for the Singing Valentines this coming week: which quartets go where when to sing to whom - spread out all over the island of Oahu.

Product Releases
Not much progress in January. The beta testers received 4 new versions, the latest being 4.0.1.7.

Bugs
The new players that purchased World in Flames during the Christmas sale are generating some discussions.
And, once again I am lagging with bugs reported in January: via email, in the Tech Support forum for World in Flames, and those reported by beta testers. I catch up and them fall behind. There seems to be a pattern here.

I continue to work on the Naval stuff for NetPlay. Those bugs are difficult to nail down and fix; sort of like trying to nail jell-O to the wall. Over time I was able to prove that several of them no longer exist, and to fix a couple of them, but I still have 3 that refuse to go away.

Missing Optional Rules & Half Map Scenarios
Nothing new in January. Hopefully I’ll be able to get back to working on these in February.

AI Opponent (AIO)
Nothing new in January.

[Shannon V. OKeets]

March 6, 2020 Status Report for Matrix Games’ MWIF Forum

Product Releases
Small progress in February. The beta testers received 3 new versions, the latest being 4.0.1.10.

I expect to post a new Hot Patch (version 03.01.00.02) to the World in Flames forum today (March 6th). If that doesn’t generate any new bug reports, we’ll make it a Public Beta late in the following week

Bugs
I’ve caught up with all the various bug report streams: via email, in the Tech Support forum for World in Flames, and reported by beta testers. Nothing real exciting is being reported, other than some trouble with starting a new Guadalcanal scenario (which is fixed in today’s upcoming Hot Patch version).

I got some things correct in unusual Naval Interception Combats for NetPlay. Most of those involved nested digressions, outside of the standard sequence of play. For example, there was a problem with an advance after combat overrunning multiple naval units, which were then forced to rebase (first digression), were successfully intercepted (second digression), took losses from the resulting naval combat, and forced to abort (third digression). The program now correctly processes those digressions in reverse order of occurence: (1) continuing the naval interception combat (Yes/No asked of both sides), (2) aborts from the naval combat (both sides), (3) continuing to move the overrun naval units, and finally (4) continuing the advance after combat. In the last step, there were two major powers capable of advancing units into the combat hex. Once the advance after combat is completed, the program checks to see if there are any more land combats to resolve, and if not, it advances the sequence of play to Air Rebase. Tricky stuff to code, especially when considering that the game states on the two computers have to be identical throughout the entire process and the deciding major powers switch back and forth between the two sides depending on the die rolls, etc.

The last item on NetPlay Naval Combat bugs I want to fix (completely) is when the result of a naval combat (during a normal Naval Combat phase) causes units to abort through a sea area where they are successfully intercepted and forced to fight (a second naval combat), with the naval units eventually forced to continue aborting to a friendly port. There are several different points in those two naval combats (the original one and the naval interception combat) where units are placed in the Naval Abort Queue. Getting the program to process through the Queue in correct order when playing over the internet (i.e., NetPlay) fails at times. Both sides can have naval units to abort from both combats. I have 3 saved games where this problem has arisen (all different in some particulars) that I need to run through step by step, monitoring the Naval Abort Queue number for each aborting unit, to make sure the queue is processed correctly, and completely - until it is empty.

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

AI Opponent (AIO)
Nothing new in February.

[Shannon V. OKeets]

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

Product Releases
I posted two new Hot Patches (versions 03.01.00.02 and 03.01.00.03) to the World in Flames forum in March. There were a couple of problems with the first of those versions, hence the second. If the latest doesn’t generate any new bug reports, we’ll make it a Public Beta in roughly a week. The beta testers received 3 new versions, the most recent being 4.0.1.13, which is comparable to Hot Patch 03.01.00.03

I really want to switch over completely to using the latest version of Delphi to compile and build the MWIF executable (MWIF.exe). It has been about 9 months that the beta testers have been running versions created using Delphi Rio (10.3), so it definitely generates a stable MWIF.exe. Up until now, all the versions released to customers have been created using the older Delphi XE8. Indeed, the glitch with my first attempt at uploading Hot Patch version 03.01.00.03 (internally it displayed the version number as 03.01.00.02) was caused by my updating the code on two separate computers. Turning off the old computer once and for all would be quite pleasant.

Hopefully in April, I will be comfortable enough with the code to switch all World in Flames customers over to version 04.01.00.00, created using Delphi Rio. That will have to be as a Public Beta, since the MWIF.exe will be accompanied by a new set of BPL files (a.k.a., DLLs). Installing the new BPLs deserves to be handled automatically by the Matrix/Slitherine installer, which is what the Public Beta versions use. Asking each individual customer to deal with the niceties of installing BPLs, would not be wise. Letting the installer do them all is best.

Bugs
I remain up-to-date with the 3 bug report streams: via email, in the Tech Support forum for World in Flames, and reported by beta testers. Aside from a couple of bugs in version 03.01.00.02, nothing in particular stood out as serious this past month.

During March I looked back on all the bug reports from Tech Support since July 2019. I reduced the open bug reports from that list down to 6 - just counting those with saved games that can be used to reproduce the bugs. I want to merge my 3 spreadsheets/Word Perfect files into my Master Task List, which hasn’t been fully updated since the fall of 2019. Then I can prune redundancies therein and delete items for bugs that have since been fixed. A common occurrence is that I get the same bug report from different people and/or from different sources. There is nothing wrong with that. I prefer to have duplicate reports rather than not know about a bug. But it does mean that I need to spend some time reducing my master task list to just the “good stuff”. Or is that just the “bad stuff”?

Annoyingly, I didn’t get time to work on the last item on NetPlay Naval Combat bugs. What I want to fix (completely) is when the result of a naval combat (during a normal Naval Combat phase) causes units to abort through a sea area where they are successfully intercepted and forced to fight (a second naval combat), with the naval units eventually forced to continue aborting to a friendly port.

There are several different points in those two naval combats (the original one and the naval interception combat) where units are placed in the Naval Abort Queue. Getting the program to process through the Queue in correct order when playing over the internet (i.e., NetPlay) fails at times. Both sides can have naval units to abort from both combats. I have 3 saved games where this problem has arisen (all different in some particulars) that I need to run through step by step, monitoring the Naval Abort Queue number for each aborting unit, to make sure the queue is processed correctly, and completely - until it is empty.

Last week I did fix an Abort Queue Processing bug from solitaire play. That correction applies to all modes of play, so at least I won’t have to deal with it as a NetPlay specific bug.

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

AI Opponent (AIO)
We should have a new sub-forum (AI Opponent) added to the World in Flames main forum in the next week. What I want to do is gather all the AI Opponent threads scattered throughout the main forum and move them into the AI Opponent sub-forum. Then everyone can put in their opinions and advice on developing the AIO.

A ton of work has already been done by Peter (Pesk-Pesk) and myself on the AIO. Our next goal is have the AIO play either side of the Barbarossa scenario, using a fixed rule set. What rules, you may ask? Well, that is one topic for discussion in the AIO sub-forum.

[Shannon V. OKeets]

May 7, 2020 Status Report for Matrix Games’ MWIF Forum

Product Releases
I gave the beta testers a lot of new versions in April. That was mostly due to me introducing new bugs with changes to fix old bugs: “Hello! I am here to replace a bug which no longer exists. My specialty is to prevent you from loading saved games!” In the end, the count of new beta test versions in April and the first week of May was eleven: 4..0.1.14 - 4.0.1.18, plus 4.0.2.0 - 4.0.2.5. My appreciation of the beta testers is ever increasing.

At this point I’ll finalize the next hot patch for release later today: version 3.1.0.4. In keeping with my previous plans, if the new hot patch doesn’t generate new bug reports, we’ll make it a Public Beta in roughly a week.

Then there is my desire to switch over completely to using the latest version of Delphi to compile and build the MWIF executables (MWIF.exe). For today, I’ll still use the older version of Delphi: XE8. You can look forward to seeing possibly two new Public Betas in May. The first will be compiled with Delphi XE8 and a later one compiled using Delphi Rio (10.3). The latter MWIF.exe will be accompanied by a new set of BPL files (a.k.a., DLLs). Installing the new BPLs for the second public beta will be handled automatically by the Matrix/Slitherine installer.

Bugs
I remain up-to-date with my 3 bug report streams: Mad Excepts reported via email, posts in the Tech Support forum for World in Flames, and reports from beta testers. Most of the new bugs were piddling little ones from typos and transitory logic failures by me.

Continuing my assault on old bug reports, I reduced my master task list bugs concerning Land Operations to two: for one I do not have a saved game, but it looks significant, and the other is not being able to switch units freely between stacks of land units that are full.

The first Land Operations problem is from a recent NetPlay game involving invasions plus other land combats, with the program halting during the Advance After Combat phase. It isn’t possible for me to recreate this without a saved game. If anyone runs across this and is able to recreate it, I would dearly love to have a saved game and instructions on how to reproduce.

The problem with not being able to switch units freely between adjacent hexes is #276 on my task list. Now I started numbering bug reports back in 2005 or so and started my numbering system at #100. So this bug is older than some of the people playing MWIF. After I got up to #9999, I renumbered all the bugs with numbers less than 1000, so I would have a fresh 900 numbers available. This means that this bug appears as #O276 on my list, the O indicating it is from the original 100 - 999 bugs

The only other two bugs that old on my master task list are O409 (incomplete implementation of the Search and Seizure rules) and O769 (the Detailed Map not refreshing correctly from time to time).

While I did fix some NetPlay bugs in April, I didn’t get time to work on the NetPlay Naval Combat bugs. What I want to fix (completely) is when the result of a naval combat (during a normal Naval Combat phase) causes units to abort through a sea area where they are successfully intercepted and forced to fight (a second naval combat), with the aborted naval units eventually forced to continue aborting to a friendly port.

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

AI Opponent (AIO)
I added a new sub-forum (AI Opponent) to the World in Flames main forum in April. With the help of Peter, I was able to gather all the AI Opponent threads scattered throughout the main forum and move them into the AI Opponent sub-forum. Everyone is encouraged to add their opinions and advice on developing the AIO to that forum

[Shannon V. OKeets]

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

Product Releases
I released the Hot Patch version 3.1.0.4 early in May, which was followed quickly by Hot Patch version 3.1.0.5 to fix a significant problem in the previous version. At the end of May, I released version 3.1.0.6, which had several important corrections. In addition, I gave the beta testers 4 new versions 4.0.2.6 - 4.0.2.9 in the past month.

Next up is to send a Public Beta (version 4.1.0.0) to Matrix Games/Slitherine to make available for everyone to try. The code for that version should be very similar, if not identical, to version 3.1.0.6. The major difference is that the 4.1.0.0 will be compiled, and the executable built, using Delphi 10.3.

Version 4.1.0.0 will fulfill my desire to switch over to using the 10.3 version of Delphi to compile and build all MWIF executables (MWIF.exe). That MWIF.exe will be accompanied by a new set of BPL files (a.k.a., DLLs). Installing the new BPLs for the public beta will be handled automatically by the Matrix/Slitherine installer.

As a side note, Embarcadero announced this week that version 10.4 of Delphi is now available. To quote Lewis Carroll: “The hurrier I go, the behinder I get.”

Bugs
I remain up-to-date with my 2 bug report streams: posts in the Tech Support forum for World in Flames, and reports from beta testers. Almost all of those bug reports are accompanied by saved games, which makes it much easier for me to make sure the bugs are bugs, and to fix them when they are.

Mad Excepts reported via email are vastly more ambiguous as to their cause. Which is why I tend to lag behind on investing my time to figure out what they are all about.

Important recent corrections are:

1. Added extensive in-line documentation to the code for air-to-air combat and fixed a bug with applying surprise points.

2. Fixed a problem with the Anti-aircraft Fire form reappearing during the return to base digression for a land based bomber that was just aborted due to anti-aircraft fire. Now the form only reappears after the aborted bomber has been returned to base and the digression has ended.

3. Fixed a problem with the program sometimes generating a fatal error after applying several results from Anti-aircraft fire.

4. Added a new section of code to check if major powers have sent enough Build Points to fulfill their trade agreements. If they have not, then additional build points are marked as Lost - No Path, and the number of available build points for the sending major powers is comparably reduced.

5. For NetPlay, added code at the start of the transition to a new air phase (e.g., port attack, ground strike) to set the air subphase to CAP prior to the call to AutoSave. This is so both players save the game as being in the CAP subphase. Previously, one player’s saved game would have the erroneous setting of Done. When the game was restored, the phase would then immediately advance to the next phase, instead of restoring to the CAP phase of the given air mission phase. This also applies to saved games using the Solitaire and Head-to-head modes of play.

6. For NetPlay, fixed a problem with applying anti-aircraft fire damage points to air units during port attacks. Previously, the reduction in naval air combat factors was only applied on one of the two computers. The other computer had the AA fire as having No Effect. That sometimes resulted in different outcomes on the two computers.

7. Fixed a problem with using oil to reorganize units where a major pwoer had no oil of its own available but could use oil belonging to a cooperating major power. Before this change, the major power without oil was not given the opportunity to use oil from a cooperating major power.

8. Corrected a problem where HQs were unable to find supply to primary supply sources of cooperating major powers (e.g., Italian HQ to German primary supply source).

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

AI Opponent (AIO)
Nothing new in May.

[Shannon V. OKeets]

July 8, 2020 Status Report for Matrix Games’ MWIF Forum

Product Releases
I released Hot Patch version 3.1.0.7 in mid-June. The beta testers received 5 new versions 4.0.2.10 - 4.0.2.14 in the past month.

Rather than go ahead with a new Public Beta, I have been focusing on investigating and fixing bugs reported in the Tech Support sub-forum and received from beta testers. I also spent several weeks working on improving Production Planning, especially how build points (which fulfill trade agreements) are created and routed. Until those changes are verified as being fully functional, I’ll hold off on creating the Public Beta.

In order to release a new Hot Patch, I need to set up a Drop Box which will be accessible to all customers. Because the attachments to posst in the World in Flames forum are limited to 9,999 KB, I will no longer be able to simply post the zipped MWIF.exe as an attachment - since it exceeds that size.

Bugs
I remain up-to-date with my 2 bug report streams: posts in the Tech Support forum for World in Flames, and reports from beta testers. Almost all of those bug reports are accompanied by saved games, which makes it much easier for me to make sure the bugs are bugs, and to fix them when they are.

Mad Excepts reported via email are vastly more ambiguous as to their cause. Which is why I am still lagging in getting them all recorded and examined.

Production Planning is far too complicated. Of course the cause is the myriad of rules concerning what can go where when using what convoys. Below are my in-line summary comments for how they are determined. Note that there are many nested loops: all trade agreements, separate loops for override/default/etc. Cycles through oil, non-oil. For loops for all the possible resources to fulfill a trade agreement. Search for overland and overseas paths, and lastly all the Build Point specific code. US Entry options play a role in what can occur, as well as the states of war between countries (including alignments). Then there are the limits imposed by the rules on how many resources/build ponts can go through ports, be stored in cities and ports. The list of exceptions to the basic rules are numerous too. There are over 18,000 lines of code for making this work, not counting all the various support modules (e.g., sorting and filtering resources, referencing country data).

// ****************************************************************************
// ProductionCompute.
// AssignTradeResources
// Fulfill_USJapanTradeAgreement
// FindBestResource(trtOil, True); // Major powers only.
// trsOverride, trsDefault, trsUnscheduled, trsLastTurn, trsAny, trsAnySub
//
// repeat
// for TradIndx := 0 to Count - 1 do
// FindResource(TradeTyp, Search_Type, Majors)
// FindResToFulfill
// for F1stGResIndx := 0 to Map.ResourceList.Count - 1 do
// TryResToFulfill
// trsOverride, trsDefault, trsUnscheduled, trsLastTurn, ...
// FindAnyRoute
// FindRoute(Land or Sea)
// until not FoundAnotherResource;
//
// FindBestResource(trtNonOil, True); // Major powers only.
// FindBestResource(trtOil, False); // All countries.
// FindBestResource(trtNonOil, False); // All countries.
//
// DecideOnResources
// FullSearch(1); // Overland only.
// for Search_Type := tresOverride to tresAny do
// EvalResource
// tresOverride, tresDefault, tresMostRecent, tresLastTurn, tresAny
// FindRoute(Land or Sea is parameter in FullSearch)
// FullSearch(2); // Overseas also explored.
//
// AssignTradeBuildPoints
// CreateDummyFactoryHex; // Add cities & major ports as possilbe BP dest.
// BuildLimits; // Set maximum BPs that a major power can produce.
// Set_BP_Source_Destination; // Set source and destination for a build point.
// FindBestResource(trtBuildPoints, True); // Major powers only.
// trsOverride, trsDefault, trsUnscheduled, trsLastTurn, trsAny, trsAnySub
//
// repeat
// for TradIndx := 0 to Count - 1 do
// FindResource(TradeTyp, Search_Type, Majors)
// FindResToFulfill
// for F1stGResIndx := 0 to Map.ResourceList.Count - 1 do
// TryResToFulfill
// trsOverride, trsDefault, trsUnscheduled, trsLastTurn, ...
// FindAnyRoute
// FindRoute(Land or Sea)
// until not FoundAnotherResource;
//
// ****************************************************************************

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

AI Opponent (AIO)
Nothing new in June.

[Shannon V. OKeets]

August 3, 2020 Status Report for Matrix Games’ MWIF Forum

Product Releases
I released Hot Patch version 3.2.0.0 on August 2, 2020. It was compiled and linked using the older verison of Delphi: XE8. In July, the beta testers received 8 new versions: 4.0.3.0 - 4.0.3.7, all compiled and linked using Delphi Rio (10.3).

I had to set up a Drop Box accessible to all customers to download the last Hot Patch. Because attachments in the World in Flames forum are limited to 9,999 KB, I could no longer simply post the zipped MWIF.exe as an attachment - since it exceeds that size. So far, accessing the new Hot Patch via the Drop Box link appears to be going smoothly. That’s a relief.

Next up is to take that same code, compile and link it using Delphi Rio, and then release it as a Public Beta. There has been one recent hiccup with a new beta tester trying to use the Delphi Rio version. I would like to get that cleared up before sending all the files to Slitherine/Matrix so they can create the Public Beta version.

Bugs
I continued to spend weeks working on improving Production Planning. That code is complex primarily because of all the special rules concerning sending resources and build points to other countries. Most of the US Entry Options affect what is and is not permitted. Every special rule requires separate branching logic to processes the deviations from the rules that normally apply. Piled on top of those are all the possible relationships between countries, their aligned minors, neutral minors. As the states of war change between countries in the game, the code has to deal with the “may/may not” consequences for routing resources.

Giving players the ability to control what goes where in this changing simulated world, while still adhering to the Australian Design Group’s rules for World in Flames, was, is, and always will be a challenge.

I remain up-to-date with my 2 main bug report streams: posts in the Tech Support forum for World in Flames, and reports from beta testers. Bug reports accompanied by saved games are much easier for me to solve and then make sure they are fixed.

Sadly, I remain woefully behind in processing the third data stream, Mad Excepts reported via email.

Missing Optional Rules & Half Map Scenarios
Corrected a couple of problems with Kamikazes in July.

AI Opponent (AIO)
Nothing new in July.

[Shannon V. OKeets]

September 10, 2020 Status Report for Matrix Games’ MWIF Forum

Product Releases
In August and early September the beta testers received 8 new versions: 4.0.3.8. 4.1.0.1 - 4.1.0.8, 4.1.1.0, and 4.1.1.1, all compiled and linked using Delphi Rio (10.3).

It took me 10 days to figure out and correct the problem a new beta tester had using the Delphi Rio versions. Turns out that Delphi ships with both 32 bit and 64 bit versions of the Windows supplied Visual Component Libraries (DLLs). Originally I sent the correct (32 bit) versions to the beta testers but somehow sent the 64 bit versions to the new guy. All those files have the same names and creation dates so the only way to determine which is which is to try using one set and see if it works or not. That was pretty easy to do, ... once I figured out what was going wrong [super unhelpful error messages].

After I cleared that up, I ran into another problem creating a Release version of the same source code for distribution as a Public Beta version. Delphi provides two ways to compile, link, and build an application: Debug and Release. The former contains a lot of extra code (inserted by the compiler) so the developer (me) can check what happens internally as the program runs. The Release version omits all that stuff and also generates an ‘optimized’ executable. In essence, the Release version of MWIF.exe is smaller and runs faster. This all worked great with the old Delphi XE8.

But when I created the Release version using Delphi 10.3 some of the graphics were messed up. In trying to fix that, 3 weeks disappeared in a blur of confusion and profanity. This morning I worked out a way to generate a Public Beta version. It is a Debug version (as Delphi defines it) but it excludes some code I created exclusively for use by the beta testers. From the player’s point of view, it seems the same as the version created using the old Delphi XE8. On the disk, the new MWIF.exe takes up more space. The difference in processing speed should be negligible, or possibly even zero.

So, expect version 04.02.00.00 to be available as a public beta in the next week or so.

Bugs
I started the month working on processing Mad Excepts reported via email. Although I was able to download, name, number, and enter them all into my spreadsheet, I only got about halfway through actually looking at them and pruning the duplicate and opaque reports. The latter are bug reports that contain virtually no information other than: “something went wrong”.

After I began to focus on getting a public beta created using Delphi 10.3, I more or less ignored the other two data streams: from the Tech Support forum and the beta testers. I’ll get back to working on that now that the public beta has been turned over to Matrix for release.

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

AI Opponent (AIO)
Nothing new in August.

[Shannon V. OKeets]

October 2, 2020 Status Report for Matrix Games’ MWIF Forum

Product Releases
At the end of September the public beta version 04.02.00.00 was made available to customers. This version was compiled, linked, and built using Delphi Rio (10.3). Embarcadero, which owns Delphi, created the Delphi 10.xx series to support Windows 10. Because Windows 10 is substantially different from previous versions of Windows, the Windows Visual Component Libraries (VCLs) in previous versions of World in Flames needed to be replaced with the comparable VCLs for Windows 10. If you explore the new files added to the World in Flames folder for version 04.02.00.00, you will find new VCL...BPL files.

All future versions of World in Flames (e.g., hot patches) will require that the player has installed version 04.02.00.00.

In September, the beta testers received 6 new versions: 4.2.0.1 though 4.2.0.6, all compiled and linked using Delphi Rio (10.3). Note that these versions had changes made after 04.02.00.00 was created. There is a lag time between when I send a version off to Matrix/Slitherine to have them release it as a public beta, and it is made available to customers.

In the interim, they create a public beta executable which contains more than just the MWIF.exe and release notes. It also contains all the supporting files for MWIF, including the BPL files, the training videos, and the numerous MWIF data files. Once they have the auto-run EXE in hand, they put it through a series of tests and then send it to me so I can also run tests to make sure everything is working correctly. All in all, that results in a delay of a few weeks.

Bugs
After getting version 04.02.00.00 off to Matrix, I went back to bringing my task list up-to-date. I accomplished that for both the bug reports in the Tech Support forum and those the beta testers reported in a separate Development forum. Besides recording everything and downloading the accompanying saved games, I was able to methodically compare those two lists with my master task list, so all 3 match, with no redundancies and with all ‘fixed’ bugs removed from the three spreadsheets/lists.

However, I still have bug reports received via email since mid-August (i.e., Mad Excepts) to download, name, number, and enter into my third spreadsheet, Then I need to work on processing them to see what they are all about.

Working on bug reports should consume about half my time in October.

Missing Optional Rules & Half Map Scenarios
Nothing new in September. I’ll get back to adding more optional rules to the game in October. That should consume the other half of my time. My current goal it to complete adding all the misssing optional rules and the half map scenarios to the game by the end of this year.

AI Opponent (AIO)
Nothing new in September. If all goes well, I hope to be working on the AIO 80% of the time beginning 1/1/21.

[Shannon V. OKeets]

November 8, 2020 Status Report for Matrix Games’ MWIF Forum

Product Releases
At the beginning of November, Matrix/Slitherine changed the server for the NetPlay Private forum. This transition caused the server to be unavailable for a day or so. However, all is now well and the new server is both faster and better balances the load placed upon it.

In October, the beta testers received many new versions: 4.2.0.7 though 4.2.0.14, all compiled and linked using Delphi Rio (10.3). I didn’t generate any new versions (Hot Patches) for customers in October. Primarily that is because I want to fix an unusual problem with sending build points from the Commonwealth to the USSR when there is no path - see below.

All future versions of World in Flames (e.g., hot patches) will require that the player has installed version 04.02.00.00.

Bugs
Working on bug reports consumed most (but not all) of my time in October.

By the end of October I had all three of my sources of bug reports (emailed, posted in the Tech Support forum, and from beta testers) completely up-to-date and the different streams merged into one Master Task List. In November I’ll start working on the ones that many players are reporting and/or seem most deleterious to game play.

There is one bug that I’ve been working on for the past week: in a saved game from a beta tester, there is no path for sending a build point from the Commonwealth to the USSR. The program was taking 15 minutes to report that fact. I’ve cut the time by 20%, down to 12 minutes. But that is still crazy too long. Wading into the nested search loops is both painful and time consuming. Once I figure out and fix that bug, I’ll upload a new Hot Patch.

Missing Optional Rules & Half Map Scenarios
In October I reviewed the code that I had already written for three of the missing/optional rules: Isolated Units, City Based Volunteers, and Search & Seizure. Roughly 80% of the code had been written years ago for these, and I needed to refresh my memory as to how I envisioned finishing the work on each of them. None of them should be especially difficult. I would like to complete them in the next week or so and then let the beta testers put the new code through its paces.

I had not finished Isolated Units because the calculations for determining supply (Out of Supply units) had been taking a lot of CPU cycles. These days that code seems to be running reasonably fast. Therefore I’ll now extend the supply checking task to include isolated units. Instead of checking for isolated units using an infinite path to reach a supply source, I will limit each path to 50 hexes. In most cases, units are isolated by blocking enemy zones of control (and all sea hexsides, alpine hexsides, etc.) with a close encirclement. That is, usually a search distance/path of 5 hexes will confirm that the unit is isolated.

For City Based Volunteers, I had come very close to finishing that code many years ago. The beta testers found some problems with how the code behaved and I was busy with other stuff at the time. So I simply set it aside (disabled the optional rule) until I could spend some dedicated time on it. Basically, I need to debug the code that already exists.

The third item is completing the code for Search and Seizure. The conditions for when this can occur depends on routing traded resources overseas. Since there had been a lot of problems with the code that implements that function in the game, I did not want to add more code onto the tail end of the process until both Preliminary and Final Production Planning were behaving in an acceptable manner. All that is left to do is to finish the form players will use to have one of their major powers initiate search and seizure of resources being sent to an enemy major power by a third (neutral) major power.

AI Opponent (AIO)
Nothing new in October. I still hope to be working on the AIO 80% of the time beginning 1/1/21.

[Shannon V. OKeets]

December 2, 2020 Status Report for Matrix Games’ MWIF Forum

Product Releases
In November I posted a Drop Box link to a new Hot Patch (version 04.02.01.02). The beta testers received one new version: 04.02.01.03.

Bugs
Working on missing optional rules consumed most of my time in November, although I did fix a few recently reported bugs. My three sources of bug reports (emailed, posted in the Tech Support forum, and from beta testers) were up-to-date as of last week. This coming month I’ll spend a little more time on them.

Missing Optional Rules & Half Map Scenarios
In November I finished the code for the optional rules Isolated Units and City Based Volunteers. Towards the end of the month I completed the code for Search and Seizure, which not an optional rule but was a section of the rules that had never been implemented for MWIF.

Of the 80 optional rules, 60 have been implemented. I have 11 more lined up to be done next, in order:
1. V Weapons Rules as Coded 11.7.1
2. Atomic Bombs Rules as Coded 11.7.1
3. Flying Bombs Rules as Coded 14.7
4. Hitler’s War Rules as Coded 13.3.2
5. Guards Banner Armies Rules as Coded 22.4.14
6. Recruitment Limits Rules as Coded 4.2
7. Rough Seas Rules as Coded 22.4.6
8. USSR Japan Compulsory Peace Rules as Coded 13.7.3
9. Naval Supply Units Rules as Coded 22.4.13
10. Partisan HQs Rules as Coded 22.4.16
11. Limited Aircraft Interception Rules as Coded 14.2.1

Then there are the last 9, some of which I do not intend to attempt to code, for the reasons given below.
• Japanese Command Conflict (Rules as Coded 22.3). Maybe - makes Japanese production more difficult.
• Convoys In Flames (Rules as Coded 22.4.6). Maybe - numerous details to code.

• Surprised ZOCs (Rules as Coded 2.2)
No - too big an effect on game play. Minor countries become trivial to conquer.
• Ukraine (Rules as Coded 19.12). No - would it ever be used? The cost of 1 offensive chit is high and the benefits are dubious at best.
• Bounce Combat (Rules as Coded 14.3.3)
No - too difficult to code. Air-to-air combat was extremely difficult to code. Having a second air-to-air combat nested within an initial air-to-air combat would be insanely complex to code.
• Frogmen (Rules as Coded 22.4.3)
No - too small an effect on game play. There are only 3 of these units in the game, which cost 2 build points to build and take 1 year to arrive. Then they merely conduct a weak port attack.
• Enroute Interception (Rules as Coded 14.2.1)
No - too difficult to implement. This would affect all air missions and create additional decision points for the enemy player to decide whether to intercept or not. The players could end up fighting multiple air-to-air combats instead of a maximum of one for each air mission.
• Oil Tankers (Rules as Coded 22.4.6). No - makes routing resources very, very difficult.
• Intelligence (Rules as Coded 22.1).
No - too difficult to implement. The players could be prompted repeatedly to make decisions throughout the sequence of play.

As of this writing, I have V Weapons mostly complete. The remaining problem is getting stacking to work correctly. These units are treated as land divisions for moving by rail and overland. Moving by sea, they can be transported, but are considered corps sized. But for launching attacks, they perform air missions. So, internally, they are stored as air units, but do not count as such for stacking purposes in land hexes. Basically, to make them work in MWIF, they need to be treated as exceptions to a whole passel of existing code.

AI Opponent (AIO)
Nothing new in November . It now looks like I won’t get to working on the AIO until February 1st, 2021.

[Shannon V. OKeets]

January 8, 2021 Status Report for Matrix Games’ MWIF Forum

Product Releases
No new Hot Patches last month. The most recent was in November: version 04.02.01.02. The beta testers received 5 new versions: 04.02.01.04 through 04.02.01.08. I should have a new Hot Patch out next week.

Bugs
Working on missing optional rules consumed about half my time in December. I also fixed a few recently reported bugs. My three sources of bug reports (emailed, posted in the Tech Support forum, and from beta testers) were up-to-date as of the end of the year.

What I have done to reduce the time required to determine Isolated units is to reduce the maximum path for finding supply from 50 hexes to 10 hexes. 10 hexes is equivalent to about 550 miles. So that seems reasonable to me. Mostly what I would like this rule to do is to identify units (and groups of units) that are surrounded. A secondary concern is to prevent units that have wandered far away from their sources of supply from being reorganized automatically at the end of the turn.

Missing Optional Rules & Half Map Scenarios
In December I fixed some problems in the code for the optional rules Isolated Units and City Based Volunteers.

I have V Weapons all done except for the special rule that after moving a V Weapon in an impulse it cannot fire during that impulse. Meanwhile I have looked at the code for A Bombs, which is mostly complete, but requires new code for the unusual capability of air units transporting other air units. Flying Bombs also require that capability. The code for them is complete except for that ability. The next Hot Patch should have code for all 3 of these optional rules.

Hopefully I can make more progress on the other missing optional rules this month:
1. Hitler’s War Rules as Coded 13.3.2
2. Guards Banner Armies Rules as Coded 22.4.14
3. Recruitment Limits Rules as Coded 4.2
4. Rough Seas Rules as Coded 22.4.6
5. USSR Japan Compulsory Peace Rules as Coded 13.7.3
6. Naval Supply Units Rules as Coded 22.4.13
7. Partisan HQs Rules as Coded 22.4.16
8. Limited Aircraft Interception Rules as Coded 14.2.1

AI Opponent (AIO)
Nothing new in December.

EDIT: Fixed some typos.

[Shannon V. OKeets]

February 4, 2021 Status Report for Matrix Games’ MWIF Forum

Product Releases
No new Hot Patches last month. The most recent was in November: version 04.02.01.02. No new versions for the beta testers either. The numerous changes that I was making to the code for the AI Opponent generated compile errors. That meant that there were no decent executables for either customers or beta testers to use. Compile errors have calmed down recently, so I should be able to get something new out to everyone in the next couple of days.

Bugs
Two of my three sources of bug reports (posted in the Tech Support forum and from beta testers) were up-to-date as of the end of January. As for the third data stream (emailed bug reports), I have fallen behind once again.

I only made a few fixes for bugs during January.

Missing Optional Rules & Half Map Scenarios
I’ve been using the optional rule Isolated Units in my ~30 hours a week NetPlay game this year. The code change reducing the maximum path for finding supply from 50 hexes to 10 hexes is working without any noticeable delay in response time. With this rule in effect, having units wander far and wide behind enemy lines (especially in China) is a less effective tactic. They get isolated easily and if they then move, they become: disorganized, are immobile, weaker defensively, and easily destroyed.

I finished the code for V-Weapons. The code for A Bombs is mostly complete, except for actually dropping the A-Bomb. The program is still using the combat factors of the transporting air unit, instead of the 25 factors from the A-Bomb. Finishing that last step won’t take long. Before making the next hot patch available, I would like to get the optional rule Flying Bombs working as well.

My list for the remaining missing optional rules is unchanged - but I want to review it again based on feedback I have gotten from customers and beta testers:

1. Hitler’s War Rules as Coded 13.3.2
2. Guards Banner Armies Rules as Coded 22.4.14
3. Recruitment Limits Rules as Coded 4.2
4. Rough Seas Rules as Coded 22.4.6
5. USSR Japan Compulsory Peace Rules as Coded 13.7.3
6. Naval Supply Units Rules as Coded 22.4.13
7. Partisan HQs Rules as Coded 22.4.16
8. Limited Aircraft Interception Rules as Coded 14.2.1

AI Opponent (AIO)
I spent more than half my time in January working on the code for the AI Opponent. To start, I want to have the AIO, playing the USSR, capable of beginning the Barbarossa scenario. That entails scrapping units, deciding which air units receive pilots (or are NOT returned to the Force Pool when not using pilots), placing the units on the map, and calling out and placing the reserves on the map.

I finished the task of scrapping units. Basically the AIO will always scrap the same units. Because the scenario is only 5 turns long, building new units is not that important. This is especially true for units that take more than 2 turns to arrive. Those with a long production time will have to be built in the first or second turn, and even then they won’t arrive until the last turn. It is much simpler to just make hard and fast decisions for the AIO to scrap weaker units, with the benefit of knowing precisely (or nearly so) which units are available at the beginning of the scenario to be placed on the map. Spending USSR build points on militia units and land units that Germany destroys in the first few turns is a reasonable plan. To have the AIO actually scrap units was rather simple, since the code existed for reading in a list of units to be scrapped.

Even easier was deciding on a “saved setup” for the USSR in Barbarossa. Saved setups only address non-random units, such as named units (ships) and saved oil points. HQs also qualify for this category, but I did not want to commit the AIO to always placing the USSR HQs in the same hexes. Therefore, deciding on where the HQs set up will be part of the script for deciding where the randomly selected units are placed (e.g., infantry and cavalry). Here again, the code for reading in a saved setup already existed, so I just had the AIO read in a saved setup (that I created manually) and had MWIF apply it the same way it does other saved setups.

Having finished those code changes, which required new branching logic based on the decision maker being the AIO, I moved on to the script for setting up the USSR in Barbarossa. Back in 2009, Peter S. and I had worked on a script for setting up France at the beginning of the Global War scenario. Using that as a framework, I had a head start on the USSR setup script. Separately, we had also looked into how the USSR should defend against a Barbarossa attack. Towards that end, we broken the terrain over which the Barbarossa battle takes place into Theaters, Areas, and Land Regions. The latter two hex sets are subsets of the previous hex set. Peter had gone even farther into the analysis in 2015, identifying critical hexes within each land region that should be occupied by the AIO to achieve a decent defensive position. See the screenshot below, where orange tinged hexes are the most important and yellow tinged hexes slightly less important. White hexes are third in importance and hexes without any color are of lowest importance.

We have a pretty good idea of where the reserves should go, but the script will have several different sets of positions for them, and randomly choose which one to use. That is the same principle that we’ll use for setting up other units: random numbers will determine which of several equally good setups will be used. Except for the reserves, all the other units have to be placed on the map before the USSR/AIO knows where the German units will set up. Without knowing where the German units will be, the AIO can’t take “the enemy position” into consideration.

Lastly, I have returned to writing code for the parser. I never wanted to hard code how the AIO makes decisions, instead I wanted to enable an ‘author’ to write scripts for how the AIO decides stuff. To achieve that I needed to define a language in which the scripts would be written: LAIO (Language for the Artificial Intelligence Opponent). I had some experience creating programming languages back in the early 1980s, when I created a language for doctors to write how a patient responds to disease and treatment over time. That was for the American Board of Internal Medicine. They wanted a program that would simulate the changes in a patient’s condition over time starting from “the patient presents ...” with a certain illness, and then responding to a doctor’s decisions to run tests and administer treatments.

Around 2008 I had LAIO defined for MWIF. Like other programming languages it has variables, branching logic, loops, functions, and procedures. Writing the language definition was accomplished while I was vacationing in Europe and at other times when I was unable to write MWIF code. However, it was only a paper document. The real work is in writing the parser, which reads in a LAIO script and transforms it into variables, branching logic, etc. for use by the MWIF Pascal code.

As for so much of the AIO code, I had already written about half of the parser. This past month I went back over what I had already done (many mental cobwebs needed dusting). Not only do I now understand what I had previously written, I have also added code that completes some of the tasks I had “up next” on my AIO task list way back in 2010.

I expect to spend at least half of my time next month on the AIO parser.

[Shannon V. OKeets]

March 6, 2021 Status Report for Matrix Games’ MWIF Forum

Product Releases
One new Hot Patch last month: version 4.2.2.0. Two new versions for the beta testers: 4.2.1.9 and 4.2.2.1. The latter is comparable to 4.2.2.0, but with Debug features enabled.

Bugs
My task list is up-to-date with bug reports from Tech Support (and other threads in the MWIF forum). Likewise, my list of problems reported by the beta testers is up-to-date. However, each list has grown by 10 or so items while I have been working on Optional Rules and the AI Opponent code. I need to spend some time investigating newly reported difficulties.

In general, new bug reports keep getting more and more obscure. Sometimes they engender discussions in the forum about rule interpretations. I’ve been playing WiF since 1985 and writing the code for MWIF since 2004. Can you take a wild guess as to how I feel about rule interpretation arguments? Typically my immediate reaction is to let the code remain as it is. Only a very convincing case for why the code is wrong - and that it makes a hill of beans of difference in game play - has to be made. If not, I just move on to more important stuff.

Annoyingly, for my third source of bug reports, (emailed) I am roughly two months behind. Eventually I’ll catch up, but those bug reports lack details and saved games. Working on them doesn’t usually yield much benefit, other than making me feel that I have an improved understanding of what players are running into.

Missing Optional Rules & Half Map Scenarios
I finished the code for A Bombs. I want to get the optional rule Flying Bombs working next.

My list for the remaining missing optional rules has changed, mostly based on feedback I received from customers and beta testers:

1. USSR Japan Compulsory Peace Rules as Coded 13.7.3
2. Guards Banner Armies Rules as Coded 22.4.14
3. Naval Supply Units Rules as Coded 22.4.13
4. Limited Aircraft Interception Rules as Coded 14.2.1
5. Hitler’s War Rules as Coded 13.3.2
6. Partisan HQs Rules as Coded 22.4.16
7. Recruitment Limits Rules as Coded 4.2
8. Rough Seas Rules as Coded 22.4.6

AI Opponent (AIO)
I spent more than half my time in February working on the code for the AI Opponent.

Having the AIO playing the USSR in the Barbarossa scenario means being able to assign a combat value (CV) to each unit. My design for the AIO has CVs at its heart. They determine which air units should be assigned pilots. When a combat loss has to be taken, they determine which unit lives and which dies. Then they are also an integral part of the logic for deciding which units to build. The list of where a unit’s CV is referenced is very long.

One of the first ‘calls’ in an AIO script is to calculate the CV for every unit in the game. I need to have the parser decode the line in the script that makes that call. But first I need to write the MWIF/Delphi/Pascal function that makes those calculations, which is what I worked on a lot in February. There are 70 unique unit types in MWIF. Hence the logic for calculating CVs is a “case statement” with 60+ blocks of code.

Peter S. made an excellent first pass on the values for fighters and he is working on the same for bombers. To his draft, I have added some tweaks. One of the complexities for doing this is the number of optional rules involved. The first block of code shown below is what I presently have for the fighters. The value of a fighter is primarily due to its air-to-air combat value and range. Fighter-bombers get additional points for their ability to fly missions other than as pure fighters.

Peter has also finished the script for setting up the USSR air and reserve units for Barbarossa. Both of those have several variations with the variation chosen decided by a random number.

The second block of code below is my current thinking on the value of different land unit types. There are 38 land unit types, so the code below is only a fragment of what the whole will look like.

--------------------------------
utFighter: // FTR2 or FTR3.
begin
AU := TAirUnit(U);

Result := (AU.AirAir * 2) +
AU.Tactical +
(AU.Strategic * 0.5) +
(AU.AirSea * 0.5) +
AU.Range;
// ****************************************************************************
// Range bonus for flying a naval air mission.
// ****************************************************************************
if AU.Range > 10 then Result := Result + 3
else if AU.Range > 6 then Result := Result + 2
else if AU.Range > 3 then Result := Result + 1;
// ****************************************************************************
// Range bonus for flying an interception mission.
// ****************************************************************************
InterceptRange := (AU.Range + 1) div 2; // Fractional part truncated by div.
Result := Result + InterceptRange;
// ****************************************************************************
// Range bonus for flying a naval air support mission.
// ****************************************************************************
NavalAirSupportRange := InterceptRange;

if NavalAirSupportRange > 10 then Result := Result + 3
else if NavalAirSupportRange > 6 then Result := Result + 2
else if NavalAirSupportRange > 3 then Result := Result + 1;
// ****************************************************************************
// Additional effects when using optional rules.
// ****************************************************************************
if OptRules.TwinEnginedFighters and AU.TwinEngine then
Result := Result - 1;

if OptRules.NightMissions and AU.Night then
Result := Result + 0.5;

if OptRules.TankBusters and AU.TankBuster then
Result := Result + (AU.Tactical * 0.5); // Half again.
end;

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

// To the straight forward combat factor of a land unit, adjustments are made
// that take into consideration its mobility. Working from a base of 4
// movements points, the combat value is incremented or decremented by 0.5
// points for every difference in movement points. For example, a 7-5 infantry
// is worth 7.5 CVs and a 6-3 is worth 5.5 CVs. Divisional units are reduced by
// a full point for their lack of zones of control. Similarly, territorial
// units have their CV reduced by 1 for the penalty they suffer in combat when
// not stacked with a non-territorial land unit.
//
// There is a minimum combat value of 1 CV for a unit after adjustments, which
// keeps a 2-1 garrison and 1-4 divisional unit from becoming worthless.
// ****************************************************************************
utInfantry, utMilitia, utGarrison:
begin
LU := TLandUnit(U);
Result := LU.Combat + ((LU.Move - 4.0) * 0.5);

if LU.Small then Result := Result - 1.0
// ****************************************************************************
// Corps sized German SS units have a garrison value of 2.
// ****************************************************************************
else if LU.Country = GermanSS.ID then Result := Result + 1.0;
// ****************************************************************************
// Add bonus for elite units.
// ****************************************************************************
if LU.Elite then Result := Result + 2;
// ****************************************************************************
// Add bonus for winterized units.
// ****************************************************************************
if LU.SnowUnit then Result := Result + 2;

if Result < 1.0 then Result := 1.0;
end;

utWarlord:
begin
LU := TLandUnit(U);
// ****************************************************************************
// Warlords can only move 6 hexes from their home city, so their value is
// reduced by 1.
// ****************************************************************************
Result := LU.Combat + ((LU.Move - 4.0) * 0.5) - 1;

if Result < 1.0 then Result := 1.0;
end;

utTerritorial:
begin
LU := TLandUnit(U);
// ****************************************************************************
// While territorial units suffer penalties when attacking and defending without
// the help of non-territorial units, they are capable of getting supply from
// cities in their home country and can move more freely in their home country.
// ****************************************************************************
Result := LU.Combat+ ((LU.Move - 4.0) * 0.5) - 1.0 ;

if Result < 1.0 then Result := 1.0;
end;

utMountain:
begin
LU := TLandUnit(U);
// ****************************************************************************
// Besides being tripled in mountain terrain, mountain units can also be air
// transported by ATR units and are 'SnowSet' units.
// ****************************************************************************
Result := LU.Combat + ((LU.Move - 4.0) * 0.5) + 3.0; // Mountain + 3.

if LU.Small then Result := Result - 1.0
// ****************************************************************************
// Add bonus for elite units.
// ****************************************************************************
else if LU.Elite then Result := Result + 2;

if Result < 1.0 then Result := 1.0;
end;

utMotorized:
begin
LU := TLandUnit(U);
Result := LU.Combat + ((LU.Move - 4.0) * 0.5) + 1; // Motorized + 1.

if LU.Small then Result := Result - 1.0
// ****************************************************************************
// Corps sized German SS units have a garrison value of 2.
// ****************************************************************************
else if LU.Country = GermanSS.ID then Result := Result + 1.0;
// ****************************************************************************
// Add bonus for elite units.
// ****************************************************************************
if LU.Elite then Result := Result + 2;
// ****************************************************************************
// Add bonus for winterized units (e.g., Finnish, Swedish, Norwegian, Russian).
// ****************************************************************************
if LU.SnowUnit then Result := Result + 2;
end;

utMechanized:
begin
LU := TLandUnit(U);
Result := LU.Combat + ((LU.Move - 4.0) * 0.5) + 2.0 ; // Mechanized + 2.

if LU.Small then Result := Result - 1.0
// ****************************************************************************
// Add bonus for elite units.
// ****************************************************************************
else if LU.Elite then Result := Result + 2;
// ****************************************************************************
// Add bonus for winterized units.
// ****************************************************************************
if LU.SnowUnit then Result := Result + 2;
end;

utArmor:
begin
LU := TLandUnit(U);
Result := LU.Combat + ((LU.Move - 4.0) * 0.5) + 3.0; // Armor + 3.

if LU.Small then Result := Result - 1.0
// ****************************************************************************
// Add bonus for elite units.
// ****************************************************************************
else if LU.Elite then Result := Result + 2;
// ****************************************************************************
// Add bonus for winterized units.
// ****************************************************************************
if LU.SnowUnit then Result := Result + 2;
end;

utCavalry:
begin
LU := TLandUnit(U);
Result := LU.Combat;
// ****************************************************************************
// Cavalry units have movement values of either 4 or 5. Being able to move 5
// means that they can enter adjacent swamp hexes without becoming disorganized.
// ****************************************************************************
if LU.Move = 5 then Result := Result + 2.0;

if LU.Small then Result := Result - 1.0
// ****************************************************************************
// Corps sized German SS units have a garrison value of 2.
// ****************************************************************************
else if LU.Country = GermanSS.ID then Result := Result + 1.0;
// ****************************************************************************
// Add bonus for elite units.
// ****************************************************************************
if LU.Elite then Result := Result + 2;
// ****************************************************************************
// Add bonus for winterized units.
// ****************************************************************************
if LU.SnowUnit then Result := Result + 2;

if Result < 1.0 then Result := 1.0;
end;

utMarine:
begin
LU := TLandUnit(U);
Result := (LU.Combat * 2) + ((LU.Move - 4.0) * 0.5); // Marine doubled.

if LU.Small then Result := Result - 1.0
// ****************************************************************************
// Add bonus for elite units.
// ****************************************************************************
else if LU.Elite then Result := Result + 2;
end;

utParatroop:
begin
LU := TLandUnit(U);
Result := (LU.Combat * 1.5) + ((LU.Move - 4.0) * 0.5); // Para * 1.5.

if LU.Small then Result := Result - 1.0
// ****************************************************************************
// Add bonus for elite units.
// ****************************************************************************
else if LU.Elite then Result := Result + 2;
end;

utInfantryHQ:
begin
LU := TLandUnit(U);
Result := LU.Combat + ((LU.Move - 4.0) * 0.5);
// ****************************************************************************
// Add bonus for winterized units.
// ****************************************************************************
if LU.SnowUnit then Result := Result + 2;
// ****************************************************************************
// Add bonus for elite units.
// ****************************************************************************
if LU.Elite then Result := Result + 2;
// ****************************************************************************
// HQs belonging to major powers can act as secondary supply sources for aligned
// minor countries and cooperating major powers. That makes them superior to
// HQs belonging to minor countries, including Nationalist and Communist Chinese
// HQs.
// ****************************************************************************
if UnitHomeCountryCommonwealth(LU).ClassType = TMajorCountry then
begin
Result := Result + (LU.Reorg * 2) + 10;
end
else
begin // Minor country HQs can trace supply to their home country cities.
Result := Result + (LU.Reorg * 2) + 6;
end;
end;

utArmorHQ:
begin
LU := TLandUnit(U);
Result := LU.Combat + ((LU.Move - 4.0) * 0.5);
// ****************************************************************************
// Add bonus for winterized units.
// ****************************************************************************
if LU.SnowUnit then Result := Result + 2;
// ****************************************************************************
// Add bonus for elite units.
// ****************************************************************************
if LU.Elite then Result := Result + 2;
// ****************************************************************************
// HQs belonging to major powers can act as secondary supply sources for aligned
// minor countries and cooperating major powers. That makes them superior to
// HQs belonging to minor countries, including Nationalist and Communist Chinese
// HQs. All armor HQs belong to major powers.
// ****************************************************************************
Result := Result + (LU.Reorg * 3) + 10;
end;

utPartisanHQ:
begin
LU := TLandUnit(U);
Result := LU.Combat + ((LU.Move - 4.0) * 0.5);
// ****************************************************************************
// Partisan HQs belong to the USSR and Yugoslavia. The former is a major power
// and the latter is a minor country. Partisan HQs are especially nice since
// they are always in supply and do not need oil to be reorganized.
// ****************************************************************************
if UnitHomeCountryCommonwealth(LU).ClassType = TMajorCountry then
begin
Result := Result + (LU.Reorg * 2) + 12;
end
else
begin
Result := Result + (LU.Reorg * 2) + 8;
end;
// ****************************************************************************
// Add bonus for winterized units.
// ****************************************************************************
if LU.SnowUnit then Result := Result + 2;
// ****************************************************************************
// Add bonus for elite units.
// ****************************************************************************
if LU.Elite then Result := Result + 2;
end;