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.
|
Printable Version
RE: When? - 
Conversely, it is perfectly acceptable to simply not implement some of the optional rules or desirable but non-essential features. So if either of those have bugs associated with them, then those rules/features can be delayed for a 'post-release' version of the product. 
). That's all there is at the moment...
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