Shannon V. OKeets
Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
|
May 1, 2018 Status Report for Matrix Games’ MWIF Forum
Program Development
In April we released several Hot Patch versions: 02.08.01.00, 02.08.02.00, 02.08.03.00, and 02.08.04.00. Sadly, it took me several tries to make a clean version.
The beta testers received versions 02,08.01.01, 02,08.02.01, 02.08.02.03, 02.08.04.01, 02.08.04.03, 02.08.04.05, 02.08.04.09, 02.08.04.11, and 02.08.04.15. My goal continues to be to get a Public Betas with solid NetPlay code out. As part of my continuing testing of NetPlay (I have 3 games in progress, 4 sessions per week) we keep running into bugs. Obviously that means the code is not yet ‘solid’.
My opponents in my NetPlay games received ‘Release’ versions 02.08.04.06, 02.08.04.08, and 02.08.04.14., The average in April was 4 new versions per week.
Bugs
My task lists are lagging. In lieu of keeping up with posts in Tech Support and via email, I have head my down looking into very complex routines, trying to figure out bugs. The dust on those lists is beginning to bother me, so I’ll get back to spiffing them up this coming week.
After my struggles with air-to-air combat in March I finally broke down and drafted a flow chart for the code’s logic. See below for more details. That enabled me to fix several bugs and I presently am happy with air-to-air combat, for Solitaire, Head-to-head, and NetPLay modes of play.
My most recent quest has been to clean up some Production Planning bugs. In particular I have been able to fix a problem with sending resources from the United Kingdom to the USSR when Moscow has been cut off (or taken by the Axis). They now go to Murmansk and/or Archangel despite there being no factories in either city. However, I still need to work on changing the source factory for resources to China from London so they originate in Calcutta. In the game I am using to test this, London can’t reached Kunming because there are insufficient convoys. Calcutta doesn’t have that problem. This problem only occurs when Chingking has been taken by Japan.
Here are my in-line notes on the Production Compute routine for assigning resources for trade agreements. My hand written version of this shows the 7 nested loops that aren’t apparent in this ‘list’.
// ****************************************************************************
// 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
// AddCapital; // Assign capital as source for each TA BP.
// CreateDummyFactoryHex; // Add cities & major ports as possilbe BP dest.
// BuildLimits; // Set maximum BPs that a major power can send.
// FixBuildPoint; // Set source and destination for all build points.
// 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 April.
AI Opponent (AIO)
Nothing new in April.
======================
The flow chart shown below is for processing Air-to-air Combat. Now this is a skeleton description of the logic flow, and I created it by hand this month, using CorelDraw. All-in-all it contains only a dozen or so of the 8,000+ lines of code that execute air-to-air combats. I also was somewhat cavalier in deciding what to include. For instance, the details of the messages displayed in the form are omitted, with just brief references to them being shown at all. Likewise, the player actions in choosing which units suffer results and returning units to base only get a single line of text - if that.
The light brown boxes are for creating, displaying, closing, and destroying the form itself. Each of the segments of code represented by these boxes perform a lot of housekeeping tasks, mostly initializing variables and the like.
The pale yellow boxes are player actions: deciding about using surprise points to avoid the combat, arranging units prior to combat, selecting which one unit receives the effects of a die roll, and returning air units to base. The large box with a bright yellow outline (Decision Button Click) executes whenever the player makes a decision and clicks on one of the decision buttons in the center of the air-to-air combat form. The five possible button labels are shown with their associated integer values and the branching logic for each.
The large box in the upper left with the blue outline (AirCombatTimerTimer) executes continuously when it is enabled. It uses the case statement for SubSubPhase to do most of its work. In this diagram I show case statements as a series of IF - THEN branches, which is how case statements execute internally. Looking at the code though, they are much easier to read, with each possible value having a single block of associated code. The timer primarily controls what happens during each subsubphase of air-to-air combat. Mostly it cycles through rolling the dice and determining what happens to which unit. Ultimately it gets to the SetDecisionSequence box with a value of 5 and from there either goes to Final Message to look for the next combat or asks each player whether he wants to abort or stay.
The BothDecided box in the bottom center either goes back to SetCombatRound for another round of air-to-air combat, or returns the air units from the current combat to base and sees if there are any more air-to-air combats.
I did the Surprise Query A2A box in red because it short circuits the entire logic flow for a combat, terminating it immediately.
Note that the Final Message box is for the current air-to-air combat. Of course there will be only a singe air-to-air combat processed during a naval combat. Indeed, the next naval combat round might be a surface or submarine combat. But for air missions to land hexes, there can be multiple air-to-air combats to process: one for each targeted air mission hex.
What this flow chart shows is the logic flow after I made several changes to the code. The act of creating the flow chart let me study what was happening using my eyes, instead of having to figure it all out in my head. Doing so revealed several places where the code was redundant, circuitous, or simply wrong. Lastly, I would like to add that the flow chart would be vastly more complex if I included the branching logic for NetPlay. That would have to show separate arrows for the deciding and non-deciding players. I did a bunch of those by hand when I was first modifying code for NetPlay. But they are very ugly, incomplete, out-of-date, and can only be understood (maybe) by their author (me).
 Attachment (1)
_____________________________
Steve
Perfection is an elusive goal.
|
Printable Version
RE: MWIF Monthly Reports - 
Because of the additional testing they do in-house for an official update, and the publicity we want to produce for the NetPlay Ready! version, it will take 3 to 5 weeks before it will be available to customers. Partially that time is necessary to replace the copies of the game in the warehouse with disks containing the new version. 
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