|
Shannon V. OKeets -> RE: When? (8/2/2010 2:43:41 AM)
|
August 1, 2010 Status Report for Matrix Games’ MWIF Forum
Accomplishments of July 2010
Project Management
I monitored all the threads in the MWIF World in Flames forum daily.
Hardware and Software
Theme Engine is still disabled. I never use the Delphi 2010 IDE debugger any more. I find the in-line tracking messages faster for debugging, and I should have been doing it this way since forever. By adding if statements to control when the messages are displayed, I have more control than I had in the debugger. I am also able to leave the debugging messages in as comments, so if a section of code causes any problems later, I can reactivate the debugging information quickly and easily.
Beta Testing
I released versions 4.02.06 (21 bug fixes), 4.02.07 (13 fixed), 5.00.00 (4 fixes), 5.00.01 (4 fixes), 5.00.02 (6 fixes), 5.00.03 (8 fixes), 5.00.04 (9 fixes), 5.00.05 (22 fixes), 5.01.00 (13 fixes), 5.01.01 (5 fixes), and 5.01.02 (10 fixes) to the beta testers last month. I also have 7 more fixes done for version 5.01.03, but I want to finish modifying Production Planning before uploading that version to the beta testers. This totals 11 new versions and 122 fixes which is up from 6 new versions and 100 fixes last month. It also includes some new code, discussed below, so my productivity improvement due to changing debugging methodology has quantitative substantiation.
The major change in bug reports is that fatal errors have dropped off to close to zero. These had been dominating the beta tester bug reports for years, and had been resurgent since the massive changes I made in the first quarter of this year. The MadExcept utility software catches virtually all of the fatal errors and reports them as Access Violations. That translates as trying to use a portion of the computer memory that has not been allocated for use by the program (i.e., MWIF). For most of my programming life, access violations were rare (~5%) but with the advent of object oriented programming (OOP), they now comprise ~95% of fatal errors. Partly this is because the new compilers detect/catch “Index out of Range” errors which had been the primary fatal error when programming in the 60's, 70's, and 80's.
The arrival of OOP means that everything in a program is an object - if that is at all possible to achieve. For example, in MWIF, there are separate objects defined for: units, the map, countries, sea areas, trade agreements, neutrality pacts, declarations of war, and each phase of the game. Indeed, there are specific objects defined for land units, naval units, air units, special units, subcountries, minor countries, major countries, and so on. There are objects for stacks of units (on map and off map) and moving unit stacks. There are over 150 more object types defined for the forms alone. My point is that there are well over 400 object types defined for MWIF.
Each object has associated with it both data and procedures/functions. For example, there is a fixed datum on a land unit object’s combat strength and a function that calculates its current defense strength based on terrain and supply. Which brings me back to the access violations. If the program needs to reference an object and the pointer to that object has a nonsense value, then an access violation occurs. A simple case would be looking up the current defense strength for a unit that is off map. The hex coordinates for an off-map unit are nonsense and trying to figure out the terrain type using those coordinates produces a MadExcept error: Access Violation.
So, since everything in MWIF is an object, and the number of interrelationships between objects is enormous, of course the fatal errors are almost always about a failure to set/clear object pointers. This is why all the rules are so hard to code. It is necessary to understand all the possible situations where one object might have to reference another object and to keep all the pointers accurate. As part of this solution, there are literally thousands of instances in MWIF where a preliminary check is made to see if a pointer to an object is nil (undefined). If the check detects a nil pointer, it typically skips processing the next section of code. This comes up in hundreds of cases where a player might choose to terminate a game in the middle of anywhere in the game. The program has to check for the game terminating rather than trying to process game elements. For example, if the player is choosing whether to commit submarines to an attack and instead decides to terminate the program, MWIF has to close up the forms for committing subs and naval combat that are open without trying to process any implied decisions.
Saved Games
I went through restoring over 150 saved games (GAM files) and found a variety of errors. Some of the very old GAM files were incomplete, the program having failed to write out the GAM file. There was another problem restoring games from before version 00.00.12.00. I decided that figuring out how to fix that wasn’t worth the effort because those games were from before 2009, 18+ months ago.
I did find one major problem with saved games that threw me into a panic, and I uploaded a full new version to fix it (00.05.00.00). After a couple of days my panic waned and I realized that the error affected less than 5% of the saved games. I was able to insert a detection routine which warns the beta testers (and myself) when a saved game is ‘damaged’. I was also able to correct the problem in some instances so the GAM file could still be used.
Map and Units
Rob sent me an update of the naval unit writeups. Once again I am under the illusion that the Unit data is complete. I made one coding change to modify how City Based Volunteers are displayed. I added a ‘V’ in the upper right corner of these units so it is easy to identify that they are CBV. The V does not intrude on the rest of the unit depiction - it occupies the same place as the R for reserve units.
Scenarios and Optional Rules
Added new code for Internment. This optional rule is only used rarely, but its most common occurrence is during the 2nd impulse of the Global War scenario, so the beta testers complained about this a lot. Since this optional rule was not part of CWIF, this was all new code.
I finished the code for Partisans. There had been a few small bugs with the Partisans phase, but the most difficult task was adding another subphase to the setup phase, after all the major powers have set up their units. In some scenarios there are partisan units that need to be set up after all the major powers have put their units on the map. For example, when the USSR sets up before Germany, there has to be a separate setup subphase for the USSR to put its partisan units on the map after the Germans have placed all their units in mother Russia. Particularly tricky was the check to see if there is sufficient room for the partisans to be placed on the map. If the Germans cover all the occupied hexes in Russia with zones of control, well, then the USSR partisans are simply destroyed instead of being placed on the map. Again, CWIF did not contain any code for this because the 3 CWIF scenarios did not include partisans in any of the setups. So, this was all new code.
I made some progress on the City Based Volunteers optional rule. Besides adding the V in the upper right corner of these units, I also separated them out from units in the force pool and future force pool on the Scrap form. There are several unique aspects to City Based Volunteers, which require me to do some considered thinking before coding the rest of that optional rule.
MWIF Game Engine and CWIF Conversion
I completely rewrote the code for determining valid land moves. This is comparable to what I did for naval moves last month. I also did the same for determining legal setup locations for naval units. Altogether, these 3 modules contain 2400 lines of code. They had previously been part of MoveStack (i.e., moving units), which has shrunk by a similar amount. Sadly, MoveStack still has 8300+ lines of code, which is more than I like for any one module. By comparison, the Main module has 8500+ lines of code, and I consider that the Big Ugly in the list of 350+ MWIF modules.
Player Interface
I fixed some problems with using multiple monitors. Depending on how a player’s system is configured and on which monitor the Mainform is placed, the positioning of other forms relative to the Mainform can be difficult to work out. This all seems to run correctly now. Once I find a beta tester willing to test out 3 monitors, I’ll make sure the code is copacetic for that too.
I finished the last remaining task for Lend Leased Air Units. This piece of code enables the source major power to demand back any lend leased air unit that is still in the borrower’s force pool or air reserve pool. Lend leased air units code is finished.
I inserted messages for whenever a unit is destroyed. At times this had been done without informing other players. Now there is not only a message about the unit’s destruction, but also a short explanation of as to why the unit was destroyed. When playing solitaire, head-to-head, or against the AIO, this change isn’t that important. However, for internet and PBEM play, keeping everyone informed about mortalities seems necessary.
I returned to work on the Production Planning form. It now correctly displays all the resources and factories for each major power and correctly transfers resources that are shipped to comply with a trade agreement. For instance, the resources that the USSR ships to Germany as part of the Nazi-Soviet pact show up in Germany’s resource list and not in the USSR’s. Today’s task is to get the automate routing of the resources to their destinations: either a factory or, for oil points, a location where they can be saved. This code no longer works because it uses recursion (assembler code) which I removed in the second quarter of this year.
The longer term goal for the Production Planning form is to enable the player to review and modify the routes resources take to their destinations. My design is to provide a mini-animation for displaying routes. If the resource is moving by rail, the form’s small insert detailed map (zoom level 4) will be centered on each hex in the path, with a half second (or so) delay between centering on each hex. If a route goes overseas, then the insert map will change from the detailed to a global map, and the centering will be on each sea area instead of individual hexes. So much for reviewing routes.
Each resource can be assigned a destination (usually a factory). Choosing those locations is necessary for both the automated routing and as a first step in modifying a route. To modify an overseas route, which was a major complaint about CWIF, I’ll let the player set the departure port, the chain of sea areas, and the arrival port. Movement along rail hexsides is either possible or not possible. The actual hex path is irrelevant except when crossing straits, and crossing straits is done by first come, first served. If you want resource A to use a straits instead of resource B, then specify resource A’s destination first. Obviously, the default route for every resource will be the one it used in the previous turn.
It is likely to take me a couple of weeks to finish coding and debugging the Production Planning form. However, that will be time well spent, since getting Production Planning to work smoothly is crucial in my opinion.
Internet - NetPlay
Nothing new.
PBEM
Nothing new.
Artificial Intelligence (AI)
Nothing new.
Player’s Manual
Nothing new. This is mostly done and just needs to be reviewed and updated once all the forms et al have been finalized.
Tutorials, Training Videos, and Context Sensitive Help
Nothing new.
Historical Video, Music, and Sound Effects
Nothing new.
Marketing
The MWIF fan site still looks good. Patrice and Rob (Warspite) have transferred more of the unit write ups to the fan site. Those include the counters. The way it works is that Andy has set up an animation that cycles through depicting all the units which have writeups in the fan site. Clicking on one of the images brings up the writeup.
Communications
Nothing especially new.
===
Just for chuckles, here are two examples of Changes Since files that I provide to the beta testers with each new release.
===
Changes Since Version 04.02.05
(as of July 4, 2010)
(1) Fixed a bug in the Flyouts form where if there were less than 10 units, clicking on the form header skipped to a blank page.
(2) Changed the GameSaveRestore code so when restoring a game during setup for a scenario that starts without a weather roll, the weather is Blizzard everywhere (Orm, 4.02.05, Post #7).
(3) Fixed a bug with refreshing detailed and global maps that was popping up in different places (Michael, 4.02.05, Post #5). Michael’s reported instance was for HQ reorganization but that had nothing to do with the problem. I couldn’t reproduce the bug but was able to figure out what was wrong from the emailed MadExcept report. Michael sent me two which looked different but the underlying problem was the same.
(4) Fixed the bug with convoy losses being calculated incorrectly (Lars, 4.02.05, Post #1; Michael, 2.00.01, Post #30; Grotius, 2.00.03, Post #40; Grotius, 1.01.01, Post #16).
(5) Fixed the bug with the reinforcement subphase Place Units on Map being skipped (Michael, 4.02.00, Post #30).
(6) Fixed a bug in the Selectable Units form where if you clicked to the right of displayed unit that was no longer on the map, the map centered on Greenland. It now displays an informative message. This can happen if an air unit had been removed from the map during the Air Removal subphase.
(7) Modified the code to make Chinese lend lease aircraft available at the start of the war from countries other than the US (Orm, 4.02.05, Post #6).
(8) Modified the icon for medium resolution naval transports so there is no longer a white triangle on the aft end.
(9) Fixed the colors for the medium resolution naval unit bitmaps (Orm, 4.02.04, Post #19).
(10) Fixed the bug with overrunning units using Ctrl Left Click (Peter, 4.02.04, Post #18). Previous bugs relating to overrunning units no longer exist (Peter, 1.00.09, Post #40; CSharpmao, 1.00.09, Post #103; Peter, 00.12.01, Post #4)
(11) Fixed a bug in the UnitsInHex form, where closing the program while it was active (and other conditions pertained) caused a MadExcept error (Christian, 4.01.07, Emailed MadExcept report).
(12) Checked the problem with Claiming Eastern Poland (German units forced to relocate) results in the game stopping when the USSR ends the phase (Eric, 1.01.07, Post #47). This no longer occurs.
(13) Fixed the problem with breaking down Nationalist and Communist Chinese units (Orm, 1.01.07, Post #3; Lars, 1.01.04, Post #4);
(14) Fixed a bug in Naval Interception Combat where units were shown as selectable even though they could not reach the sea area where the combat was taking place. Similarly, removed air units from the selectable units list that were not fighters and did not have air-to-sea factors.
(15) Removed an extraneous call to UpdateCursor which was causing a MadExcept error when moving naval units that could be intercepted. It also came up elsewhere (Michael, 4.02.04, Post #4).
(16) Fixed a bug which generated a MadExcept error when exiting a game during the Commit Subs subphase of a naval combat.
(17) Fixed the bugs with the naval air interception combat not advancing beyond the naval air support phases (GSB, 4.02.05, Post #13; GSB, 4.02.02, Post #10; GSB, 3.00.00, Post #53).
(18) Corrected the setup for Missed the Bus and the other later scenarios so the Bearn starts in the repair pool (Michael, 4.02.05, Post #14). I decided to have the Bearn come over to the US as a ‘conquered’ unit. This makes no difference in game play but the unit then is depicted on screen better.
(19) Fixed a bug in restoring games from before 4.02.00 (Nils, 4.02.05, Post #20).
(20) Changed the processing of Anti-aircraft fire so a bomber aborts when it has zero factors remaining (Michael, 4.02.05, Post #18). This change needs to be tested.
(21) Changed the SET file for Germany in Missed The Bus (received from Michael).
===
Changes Since Version 05.00.04
(as of July 20, 2010)
(1) Rewrote where the determination of fractional odds benefits occur in the land combat calculations for the CRT column shift (1D10) and die roll modifiers (2D10). I also reviewed the routine that presents those results to the player in the message panel and in the Land Combat Results form. The message presentation code was sloppy and duplicated some of the calculations needlessly, perhaps erroneously. The code is stronger now, in that I integrated the fractional odds calculations into the LandCombatColumn routine instead of having it external to that logic ().
(2) Added more text to RAC to explain how moving land units differs between WIF FE and MWIF (Csharpmao, 5.0.04, Post #2).
(3) Fixed a bug where the Hungarians were being permitted to fly a fighter as an interceptor during Ground Support when the Rumanians attacked an USSR unit and both the Germans and the USSR had flown bombers. Since the Hungarians do not cooperate with the Rumanians, this was illegal.
(4) Fixed a bug where a ground support bomber on the attacking side was considered capable of flying to an attacked hex if it cooperated with any of the units in the attack. It should only be permitted to fly to the attacked hex if it cooperates with all the attacking units.
(5) Corrected the determination of the number of major powers in a land attack. If you use an old saved game that restores in the Land Combat Declaration phase (or later), be aware that attacks that were declared before the game was saved are likely to have the number of major powers calculated incorrectly. Cancelling the attack and redeclaring it will fix that problem (Lars, 5.00.04, Post #1).
(6) Fixed the problem with the insert maps being out-of-sync with the main map. This problem would occur in a lot of forms, the land combat resolution form in particular (Nils, 5.00.04, Post #13; Grotius, 2.00.08, Post #31).
(7) Fixed the bug where extra partisans were appearing (Michael, 5.00.04, Post #11).
(8) Added another restraint to which units are selectable in the Retreat subphase, so only those that are being retreated are selectable (Nils, 5.00.04, Post #15).
(9) Made the AdvanceAfterCombat subphase another subphase that uses the Selectable Units form. This makes it easier to identify and locate the units that can advance after combat.
(10) Modified the Place Units debug form so more units are visible. I also added a large image depiction under the cursor.
(11) Added the capability to demand the return of lend leased aircraft (Frederyck, 2.00.04, Post #34; SJH, version 00.00.05.05). To do this you need to first select the leased air unit and an air unit in the same lend lease group that has been lent. Once the two units have been identified, and their group matches, clicking on the Demand Return button immediately returns the unit to the original source country’s force pool.
(12) Added a button to the restore game forms (opening splash screen and restore game from within an executing game) so that you can view the optional rules for a saved game before restoring it. This probably will not be used very often by players but should be a big help for beta testing - at least for me.
(13) Formalized when games can be saved (GSB, 2.01.04, Post #72; Michael Baldur, 1.01.01, Post #89; Orm, 1.01.07, Post #33; Sagji, 2.01.02, Post #54). This is most of the time with the following exceptions:
- when there are “units in hand” (there are units in the moving stack),
- during any digression,
- initiative phase,
- naval combat (A and D),
- ignore notional phase,
- final reorganization phase,
- minor support phase,
- surrender phase,
- conquest phase,
- while selecting units on which to expend reorganization points in the HQ reorganization phase,
- during lend lease of the setup phase (for either side),
- during setup reserves and aligning minors of the DOW phase,
- during air-to-air combat and air attack subphases of any air phase,
- during the subphases: use snow bonus (A and D), choose combat type, and combat resolution of the land combat resolution phase, and
- while saving build points during the production planning phase.
(14) Rewrote the code so the games saved automatically have file names that match the names of the phase and subphase during which they are saved.
(15) Added code to reset CanSave flag when a game is restored during air-to-air combat and the air attack subphases. It shouldn’t be possible to save a game during those subphases, but this change clears the flag just in case (Michael, 4.00.05, Post #18). Did the same thing for when the subphases of Setup, DOW, and LandCombatResolution where saving the game is not permitted. Likewise for saving build points and selecting units for HQ reorganization.
(16) Fixed a bug in scrap units that generated a MadExcept when units were scrapped.
(17) Fixed the bug where trying to save a scrap list, after restoring a saved game, caused a MadExcept (Nils, 5.00.03, Post #26).
(18) Changed ‘Pressto’ to “Press to” in the Setup Tray hint for armor (Eric, 5.00.04, Post #39).
(19) Inserted a check for an attempt to restore a game saved before Scrap Units was completed for a major power during setup. These games can not be restored and a warning message is displayed. The program (MWIF) has to be restarted (Alain, 5.00.03, emailed saved game; Paul, 5.00.02, Post #56).
(20) I gave up on restoring games prior to version 00.00.12.00. There is something wrong with the 11.xx and earlier saved games and while I was able fault isolate it, how to correct the bug would be more trouble that it is worth. All these games are prior to 2009 so they are very old. If you try to restore one of these games you will get a warning message, and MWIF will have to be restarted.
(21) Older games (e.g., version 2.00.03) that were saved during air-to-air combat are fatally flawed. If this holds true in the future, I’ll investigate further and try to fix the problem.
(22) I went through restoring over 150 games from Barbarossa. This spans virtually all versions from 00.12.00 through to the present. There were a couple damaged GAM files (incomplete) that I discarded. And there are 4 which failed to load that I might go back to analyze someday. But for the most part the save and restore games code appears to be working as desired. One problem I found was that after loading in 9 or 10 saved games in a row the program fails to load a game because of bitmap memory problems. If you see a fatal error when restoring a saved game that says it can’t load a bitmap (BMP) then that is what has happened. This means there is a memory leak in the code: bitmaps are being created but they aren’t being released when a game is ended and a new one begun. Eventually the unreleased bitmaps build up and there are insufficient resources to load a game. I tracked down this problem before about a year ago and will go through that process again (someday). For now it is annoying but fixing it is not crucial for beta testing (Nils, 1.01.01, Post #105; ).
_____________________________
|
|
|
|
