ZebraDesigner Essentials 3 barcode label design software offers basic design features and allows you to design labels quickly and easily. Learn more at Zebra.com.
![]() label matrix, 17 records found:
Posts: 21615Joined: 5/19/2005From: Honolulu, HawaiiStatus: offlineApril 2, 2010 Status Report for Matrix Games’ MWIF ForumAccomplishments of March 2010Project ManagementI monitored all the threads in the MWIF World in Flames forum daily.Hardware and SoftwareI completed replacing all the assembler routines with equivalent Pascal routines. Doing so also eliminated any code that modified the call stack.
![]()
I still have glitches when Delphi 2010 IDE (Interactive Development Environment) executes MWIF in debug mode, but it continues to improve (or at least I have that impression). Once the Assembler mysteries were gone I was able to focus on Theme Engine bugs.Theme Engine 9.10 caused me some new grief. One of its new features is the ability to animate buttons (TTeButton) so they can be programmed to blink and do other stuff. However, the cost of this change is 5 more bitmaps for each TTeButton. MWIF can not afford that - and I have zero interest in animating buttons.
The program is already close to tapping out the available bitmaps under Windows XP and given that MWIF has 750+ TTeButtons (i.e., 3750+ new bitmaps), this change in Theme Engine caused the program to fail do to insufficient “Windows resources”. So, I replaced all the TTeButtons with TTeSpeedButtons (which do not have the sexy animation feature).Although that global change was done with one command and executed in 2-3 seconds, there were other code changes required. The compiler caught most of those and I was able to get a clean compile and execution within a half hour. Annoyingly, the differences were more extensive. A TTeButton has embedded defaults which were used extensively within MWIF.
A TTeSpeedButton has no defaults so I had to explicitly code stuff that had been done automatically previously. For example, when you click on an OK button (and it is a TTeButton), Windows automatically closes the form, and records that you pressed ‘OK’. It does something similar for Cancel, Yes, and No buttons.
Basically, I spent 3-4 days making the full conversion to TTeSpeedButtons.After all these attempts to remove suspects, I was still getting weird errors. Therefore I disabled the execution of the Theme Engine themes. At that point I was able to debug in a more normal manner, and I have cleaned up what I hope to be all the newly created bugs do to the conversion from Delphi 2007 running under Windows XP to Delphi 2010 running under Windows 7.
I even fixed some older bugs I encountered along the way.Beta TestingI released version 4.01.00 to the beta testers last week. I expect to release 4.01.01 later today and return to meeting my goal of releasing a new version every 5 days or so. I would like to do 6 new versions/month. Once things settle down and I have restored my shattered confidence in the MWIF code, I’ll reenable Theme Engine themes and see how that goes. By the way, I did spend a little over a week this month looking into modifying the Theme Engine source code (i.e., the definition of TTeButton). I had mixed success with that and decided to just go back to the original TE source code.
TE consists of 100,000+ lines of undocumented code, with multiple levels of abstraction, so messing around with it is very unpleasant.Saved GamesFixed a bug with recording the movement of factories. Posts: 21615Joined: 5/19/2005From: Honolulu, HawaiiStatus: offlineMay 2, 2010 Status Report for Matrix Games’ MWIF ForumAccomplishments of April 2010Project ManagementI monitored all the threads in the MWIF World in Flames forum daily.Hardware and SoftwareTheme Engine is still disabled but I expect to restore it to active duty in the next couple of weeks. Running the Delphi 2010 IDE/debugger is still very annoying. For example, as I type this I am waiting for the debugger to reach a ‘Break’ point so I can analyze variable values to see why it is having trouble returning Yes to the question of whether an Egyptian unit cooperates with Wavell.
I’ll probably have to kill the IDE and restart Delphi 1020 soon. The IDE is continuously requesting more memory (from 4K to 80K) every second or so. It starts out with 130 MB and increases that up to 282 MB (currently - I monitor this all the time, and I always debug with a stopwatch near at hand so I can track how long it takes inspecting its navel).
My system has 12 GB of RAM and 9GB of that is unused, so I don’t care about it requesting more memory, I just wish it wouldn’t take forever before letting me examine variables. At one point this month I resorted to progamming methods I used in the late 1960's: inserting print statements to track variable values, sigh.Beta TestingI released versions 4.01.01, 4.01.02, 4.01.03, 4.01.04 and 4.01.05 to the beta testers this month. They got a new version about every 4 days at the beginning of the month but that paced slacked off once I started working on the rewrite of the supply routines. I’ll upload version 4.01.06 to them today (either before or after I finish writing this).Almost all of the changes this month related to correcting new bugs that I introduced when making thousands of edits since the first of the year - to accommodate Delphi 2010, Theme Engine 9.10, and other libraries upgraded to support Windows 7. Those are down to only a few bugs presently, but the beta testers will undoubtedly find more as they work their way through the 152 phases/subphases/sub-subphases.Saved GamesNothing new.Map and UnitsAdded some more naval unit writeups from Rob/Warspite.Scenarios and Optional RulesNothing new.MWIF Game Engine and CWIF ConversionRewrote the supply routines.
I am now in the process of debugging them. So far the program correctly identifies all primary and potential secondary supply sources for all countries (major powers and minor countries). It also finds the shortest overland rail path from each secondary to a primary correctly. I am very happy with its ability to perform a directed search, wherein it makes the right choice as to which hex to explore next; one of my main concerns here was to improve the efficiency of tracing a supply path so the AIO could conduct hundreds of what-if moves and determine the effects those moves have on supply.I haven’t tested the oversea path search algorithm yet, though that code is mostly written. I also have written the code for tracing a Basic supply path from a unit to a supply source. Actually I wrote the code for unit = supply source Basic path first. And then I cloned and modified that to create the secondary = primary using a Rail path.
I’ll reuse the code for searching for a Basic path to link ports to supply sources and units, and to link tertiary supply sources to secondary and other tertiary sources. I already have written the code to propagate supply from one sea area outwards.Perhaps I should explain the logic here. Every coutnry which has units maintains the following variables://.// Variables for supply links, connections, and paths. Posts: 21615Joined: 5/19/2005From: Honolulu, HawaiiStatus: offlineJune 5, 2010 Status Report for Matrix Games’ MWIF ForumAccomplishments of May 2010Project ManagementI monitored all the threads in the MWIF World in Flames forum daily.Hardware and SoftwareTheme Engine is still disabled. Running the Delphi 2010 IDE/debugger has dropped down to merely annoying, because I am now using work-arounds, which are actually better than the debugger in a few instances. Although I would still prefer to have the debugger’s functionality available, obviously.Beta TestingI released versions 4.01.06 and 4.01.07, to the beta testers last month.
Posts: 21615Joined: 5/19/2005From: Honolulu, HawaiiStatus: offlineJuly 1, 2010 Status Report for Matrix Games’ MWIF ForumAccomplishments of June 2010Project ManagementI monitored all the threads in the MWIF World in Flames forum daily.Hardware and SoftwareTheme Engine is still disabled. I rarely use the Delphi 2010 IDE/debugger any more, but I’ve become quite efficient using work-arounds.
My work-arounds are inline diagnostic messages that let me track call sequences and variable values. I comment out the messages once I have fixed the problem (unless I forget).Beta TestingI released versions 4.02.00 (24 bug fixes), 4.02.01 (20 fixed), 4.02.02 (20 fixes), 4.02.03 (14 fixes), 4.02.04 (3 fixes), and 4.02.05 (19 fixes) to the beta testers last month. I had left diagnostic messages active in version 4.02.03 which drove the beta testers crazy (every time they moved a unit the program reported its destination hex); hence the quick upload of a new version the next morning. The beta testers send me saved games for many of the bugs they discover so it is easy for me to reproduce them and for me to validate that I have corrected them after making changes.The mods this month were to correct bugs in a variety of places in the sequence of play. Over the past 2 weeks I have been gathering some momentum, usually correcting all new bugs the beta testers have posted during the night by noon my time (Hawaii).
Then I spend the afternoon and evening working on the backlog or writing new code.Saved GamesI have these fully functional again. There had been sporadic glitches which seem to have been cleared up.Map and UnitsAdded some small map changes from Patrice.
I also renamed the Verz Cruz (sp) militia to Veracruz so it matches the city name on the map, enabling the program to know where to place it when it arrives. Rob sent me an update of the naval unit writeups.Scenarios and Optional RulesAdded new code which finalizes the optional rule for changing when the game is over. The players can do this whenever they like, setting the last game turn anywhere from the current turn to Nov/Dec 1952.With the help of the beta testers, I have finished the specifications for how the Unlimited Divisions optional rule works. Based on that discussion, Paul has volunteered to write up the rule for inclusion in Rules as Coded and the Players Manual. I’ll post more on that once I modify the form for reforming the divisions back into corps/armies.MWIF Game Engine and CWIF ConversionI completely rewrote the code for determining valid naval moves. The CWIF code had used recursion that was dependent on assembler routines.
![]()
Since I had removed all assembler routines, I needed to create a new solution to the problem of determining which ports and sea areas were valid destinations for a naval unit. Until structure served that purpose. This rewrite took me a week but it enabled me to correct some logic deficiencies and to fix some bugs reported last year in November and December.
I had been in the midst of fixing those when I decided to upgrade to Windows 7, Delphi 2010, et al.The new search routines look for a path that can not be intercepted by enemy units. This is very handy when returning to port, since you will rarely want to encounter enemy units at that time.
CWIF always searched for the shortest path, even if it took the units through sea areas controlled by the enemy. Now don’t get me wrong, you can still take a shorter path through enemy controlled sea areas. For instance, that can happen if you want to reach a higher sea box section in a destination sea area. To do so, you specify the path for the naval units one sea area/port at a time using Ctrl Left Click.
The new code is working well now. From a programming perspective, it is both simpler to understand and fully documented.I added another piece of code to my rewrite of the supply routines: enabling HQs in a coastal hex to trace supply overseas without having to first find a land path to a port. I’ve gotten the code for tracing from tertiary to secondary supply sources mostly written but I haven’t activated it for testing yet (I like to reread code several times after I have written it to reassure myself that the logic is sound). Once I can get far enough ahead of the beta testers, who quickly report bugs when I upload a new version, I’ll finish the rest of my new supply routines and trash the old ones from CWIF (which are still in place and still execute all supply determination).Player InterfaceCreated a new form for changing when the game ends. It is accessible when a new game is being started and also during play. In both cases it is accessed using a button on the Optional Rules Help form for Extended Game Play.For the Unlimited Divisions optional rule I began work on modifications to the Pools form so it shows which divisions were created when a corps/army was broken down.
As part of that, the location of each division is shown.Internet - NetPlayRemoved the last of the CWIF code for Internet Play. That had been based on using Windows utility routines, while MWIF’s is based on a Delphi library for Internet communications. Because the old routines were interfering when playing Head-to-head, I went to the effort of cleaning up this loose end.PBEMNothing new.Artificial Intelligence (AI)Nothing new.Player’s ManualA few small changes to reflect changes in rules interpretations.
Nothing important, but I want both Rules as Coded and the Players Manual to be as precise as possible.Tutorials, Training Videos, and Context Sensitive HelpNothing new.Historical Video, Music, and Sound EffectsNothing new.MarketingAndy Johnson has the MWIF fan site looking good. My involvement in the fan site remains close to nil.CommunicationsHarry Rowland answered a question posed by Patrice (on behalf of MWIF) about the use of fractional odds on the 1D10 Assault table. The question arose because there are gaps in the odds columns: 5:1, 7:1, and 10:1.
So, what happens if the odds are 8.5:1? Harry’s answer was that there was a 50% chance of rounding up to 9:1, which is then reduced back to 7:1. This becomes important if there are other factors causing odds shifts - weather and snow units for example. Posts: 21615Joined: 5/19/2005From: Honolulu, HawaiiStatus: offlineAugust 1, 2010 Status Report for Matrix Games’ MWIF ForumAccomplishments of July 2010Project ManagementI monitored all the threads in the MWIF World in Flames forum daily.Hardware and SoftwareTheme 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 TestingI 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 GamesI 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 UnitsRob 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 RulesAdded 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 ConversionI 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 InterfaceI 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 - NetPlayNothing new.PBEMNothing new.Artificial Intelligence (AI)Nothing new.Player’s ManualNothing 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 HelpNothing new.Historical Video, Music, and Sound EffectsNothing new.MarketingThe 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. Posts: 21615Joined: 5/19/2005From: Honolulu, HawaiiStatus: offlineSeptember 1, 2010 Status Report for Matrix Games’ MWIF ForumAccomplishments of August 2010Project ManagementI monitored all the threads in the MWIF World in Flames forum daily.I put in 8-10 hours a day on this, every day. That works out to 250+ hours a month. This past month has been rather stressful because they started resurfacing a parking garage across the street. It has two levels and in late July they started working on the top deck, attacking it with jackhammers for about 6 hours a day 4 days a week.
They hammer on the concrete until they have broken through completely and only the lattice of exposed steel rebar remains. The crew is 6 guys with jackhammers plus a guy sweeping up. The lower parking area serves as a sounding board for the 6 jackhammers so the noise level is deafening. Even with all my windows closed and cotton in my ears, the noise was insanely loud. After a couple of weeks I bought ear protection muffs comparable to what the workmen are using.
That reduced the sound at the higher and middle frequencies to negligible but the lower levels still make my teeth vibrate. On several occasions I have simply fled my house and home for 2 or 3 hours to quiet my nerves. I estimate that they are about 2/3rds done after 5 weeks of work. Today is a ‘quiet’ day for the workmen (they are cutting rebar with acetylene torches) and I feel quasi-euphoric at how quiet things are - there’s just the normal traffic noises from the two main streets, 5 lanes wide, outside my condominium and the 8 lane dual highway a block away.Hardware and SoftwareTheme Engine is still disabled. I never use the Delphi 2010 IDE debugger.Beta TestingI released versions 5.01.04 (36 fixes - 7 done in July), 5.01.05 (22 fixes), 5.01.06 (14 fixes), 5.02.00 (30 fixes), and 5.02.01 (20 fixes) to the beta testers last month.
This totals 5 new versions and 115 fixes which is less than the 8 new versions and 122 fixes last month. The main reason for the decrease in both is that I spent a lot of time revising the Land Combat Resolution and Production Planning forms. More on that below. For those keeping track of this stuff, there was no version 5.01.03 because I ‘used’ that version number during alpha testing by revising the saved game format twice.Fatal errors still occur, but most of the ones I receive from the beta testers are duplicates and (net) there are only 1 or 2 new ones per release. Typically, I fix those in less than 10 minutes.
Most of the bug reports concern fine details of the game, for instance, the land combat calculations dominated the bug reports this month. More on that below.Saved GamesThe changes I made to how the trade agreement commitments are enforced required changing the saved game format several times. This was the main reason I released the new full version 5.02.00. Each executable version is now 300 MB and that is without any saved games.
Since saved games are essential for the interactive tutorials and providing the players with a “quick start” for each scenario, the released product should be close to 350 MB (compressed), plus the training videos (1.3 GB).Map and UnitsRob sent me updates of the naval unit writeups. Patrice sent me some minor changes to the map data.Scenarios and Optional RulesNothing new.MWIF Game Engine and CWIF ConversionImproved the activity limits display for the Communist Chinese. Recent rules changes/clarifications by ADG mean that the Communist Chinese activity limits are a function of the Chinese and USSR action choices and activity limits. In particular, the use of a Chinese Offensive chit on Mao is a special case in the rules. When making action choices, the Allied player can now see what effect that has on the Communist Chinese units.
There were over 50 places in the code where modifications were necessary to get this to work according to the rules changes.Reviewed and cleaned up the code for building supply units. This type of unit has to be built using only oil points so it is a little tricky, what with having to convert oil/production points to built points and maintaining a running count of how many supply units have been built during the current turn. The CWIF code was about 80% unnecessary, so I removed that portion.All the work on the Production Planning form (see below) caused me to find and fix some small bugs in the Use Oil (to reorganize units) form. These two forms are tightly interconnected since they concern the two choices for using oil points.Player InterfaceRevised the status indicators for the units to better explain their involvement in land and naval combat. For instance, when an engineer is providing his benefits to an attack, his attack indicator is now bright green, instead of the normal red for an attacking land unit.I made substantial changes to the Land Combat resolution form. The beta testers have been after me for years to provide more information on the die roll modifiers and the column shifts.
Doing so was non-trivial. There are dozens of die roll modifiers and a dozen column shifts possible. Because this form was already crowded with information, fitting in the additional details required spending time counting pixels. Posts: 21615Joined: 5/19/2005From: Honolulu, HawaiiStatus: offlineOctober 1, 2010 Status Report for Matrix Games’ MWIF ForumAccomplishments of September 2010Project ManagementI monitored all the threads in the MWIF World in Flames forum daily.Hardware and SoftwareTheme Engine is still disabled, but I have hopes of reinstalling it this month.Beta TestingI released versions 5.02.02 (12 fixes), 5.02.03 (7 fixes), 5.02.04 (14 fixes), 5.02.05 (20 fixes), 5.02.06 (17 fixes), 5.03.00 (23 fixes), and 5.03.01 (9 fixes) to the beta testers last month. This totals 7 new versions and 102 fixes which is under my previous 2 month averages for fixes (116).Fatal errors continue to decrease in frequency and I can usually fix them in a few minutes.
Most of the bug reports this month concerned Production Planning which I had completely revised and whose player interface details needed both debugging and refinement.Saved GamesSaving and restoring games is stable although I continue to make revisions to the format from time to time. With a little care, I keep old save games playable.
But I am not anal about that. Sometimes there were bugs which caused GAM files to be fatally flawed. I do not spend time trying to make old GAM files playable - just as long as the newly created GAM files restore perfectly.Map and UnitsRob sent me updates of the naval unit writeups.
Patrice sent me some minor changes to the map data.I enabled moving from Colon (at one end of the Panama Canal) through the Panama Canal and into the Gulf of Panama. This works the same as for Panama City at the other end of the Panama Canal.Units can now set up in Eritrea. The WIF FE setup booklet didn’t specify that, but Patrice checked with Harry Rowland, and MWIF conforms to Harry’s clarification.Scenarios and Optional RulesAdded code to restrict how many saved build points in each hex can be used. CWIF didn’t worry about this but I want MWIF to follow WIF FE as closely as possible.I wrote the code for Food in Flames. It remains to be tested, but was fairly straightforward.I made some changes in how the specialized subs in Convoys in Flames are handled. In particular, Milchcow subs are now restricted to the zero section box. I have occasionally done bits and pieces of the rules for Convoys in Flames, when I see something that is wrong and easy to fix.
There is still a bunch of work to do (e.g., add another subphase to naval submarine combat), so I have not yet reached the point where I can sit down and finish it in a couple of days.I linked the use of the optional rules Synthetic Oil Plants and Factory Construction & Destruction. WIF FE, as written, requires both of these to be in effect before oil resources can be destroyed by strategic bombing. This is another case of bringing MWIF into line with WIF FE, where CWIF deviated slightly.I finalized the design for Unlimited Breakdown, with the help of the beta testers (especially Paul). At the end of this report is the section from the Players Manual describing this new optional rule.MWIF Game Engine and CWIF ConversionNothing new on the game engine.
As for CWIF conversion I have now converted all the forms except Overstacking. I’ve made a tentative pass at that but I want to see more bugs resolved before messing around with something that pops up at odd places in the sequence of play. MWIF handles resolving overstacking as a digression.Player InterfaceI created a new form for debugging naval moves.
It lists all the sea areas and ports to which a selected group of naval units can move, showing how many movement points each move uses. If is astonishing how many ports are available. For instance, a Japanese unit could only move to 8 sea areas, but has over 50 possible ports available! This will not be part of the released product because it is rather crude.I made more massive changes to the Production Planning form. For the summary panel, I added hints and filters for each of the 35 statistics. The hints help to explain what the numbers mean. Then when you actually click on a number in the summary panel, the list of resources and factories is filtered to show the resources that make up that number.
For instance, if you click on non-oil trade received, just the non-oil resources that are being sent to the current major power are listed. This works for Idle Factories, Convoyed Oil, and all the other statistics too. The code uses the same filter for calculating the numbers and for modifying the list of resources and factories displayed.
That was very useful for development/debugging and has the added benefit of being useful to the players. I also added entries to the summary panel for production points received through Food in Flames and for convoys on map and idle. When convoys idle are zero, it is a good idea to build more convoys.I reduced the number of layouts for the Production Planning form from 4 to 3: Summary, Expanded, and Route. The 4th layout, for Default and Override values, is now incorporated as a standard part of the form and is visible in all 3 of the layouts.I added the ability to display the overseas route for a single resource on the global map. This lets you go through each of your resources that are using convoys and see the route it is using. Conversely, you can click on a sea area and have the resource list filtered to show the resources that are routed through the sea area.
Sometimes major powers use convoys belonging to their allies. To identify those situations, when clicking on a sea area is used to filter the resources, whose convoy the resource is using is also shown. The general thrust of the design for production planning is to let you see both summary and detailed information on resources, factories, and convoys. The filters let you focus on subsets of them. These changes enabled me to delete the old CWIF Convoy Info form.I streamlined the process of modifying routes for resources shipped overseas. The way it works is you select a resource, select its destination, and click on the series of sea areas in the route you want the resource to use.
When necessary, the program finds a departure port and a rail link from the resource to the port. Likewise, when you reach the last sea area in the pipeline, you just click on it a second time (to indicate it is the terminus) and the program finds an arrival port and a rail link to the destination. This is very fast to do and I can reroute all the Commonwealth resources from scratch in less than 5 minutes.The program stores player specified routes as either Default or Override.
Defaults are what you use most of the time; they are saved from turn to turn for automatic reuse. Override routes are for when you want to make a change for just the current turn. They take precedence over the default settings. After the turn is over, override routes are deleted, while the default routes remain available for the next turn. All routes are shown both as table entries and also on the global map, which makes reviewing them easy to do.Internet - NetPlayMy redesign of the SOP in 2007 added a Game Record Log where all the transformations of the game state are recorded as a series of encoded entries.
These are used by both PBEM and NetPlay to keep all computers up-to-date with changes to the game state. They are currently used for Solitaire and Head-to-head play, but 110 record types still need to be converted from CWIF Windows messaging code to MWIF Game Record Log code. By the way, the total number of unique record types is 550.PBEMI reviewed the 20 forms needed for entering the 22 PBEM Standing Orders. Forms for 4 of the standing orders are done, 6 have been started and 12 have only dummy stub ends in place. I remain focused on fixing bugs, but PBEM is next on my task list once I get the bugs beaten into submission.Artificial Intelligence (AI)The AIO decisions are primarily made using scripts written in LAIO (Language for Artificial Intelligence Opponent). This is a rule based language which I created for MWIF. LAIO is fully defined and dozens of test scripts have been written by Peter Skoglund, with help from me.The test scripts are for setting up units for each of the minor countries in the game, from a single unit for Persia to the more complex setups for Poland, Spain, and Turkey.
Peter has also created a script for setting up France in the Global War scenario. These scripts are quite sophisticated, taking into consideration which major power declared war on the minor country, the type and location of enemy units, and possible support from allies. For instance, the script for setting up the single Persian unit has logic for threats from land, air (e.g., paradrops), and sea (e.g., amphibious assaults) from all directions.To convert the LAIO scripts into actions to be taken by MWIF, (on behalf of the AIO), requires a parser. The parser reads a script and generates a set of commands comparable to what a human player enters using the mouse and keyboard. I’ve written about 80% of the parser code, and debugged that much using the scripts created by Peter. I need to finish the last 20%, but more importantly, I need to have the parser ‘recognize’ 300 function calls. For example, when a script references a unit’s type, the parser has to ‘fetch’ the unit type datum which is stored internally.
There are numerous characteristics of units, unit stacks, hexes, and countries which the program already stores internally. For each of them, LAIO needs a symbol/string defined and the parser needs to translate the symbol, when it occurs in a script, into a function that returns the internal value.There are 143 decision points in the sequence of play where the AIO needs to decide what to do. 122 of these use universal logic, in that they do not depend on which major power is making the decision (e.g., rail moves, strategic bombing, naval interceptions, placing partisans). For the other 21, the logic does depend on which major power is making the decision. Examples of those are: strategic plans, declarations of war, production plans, and trade agreements.
I have 200 pages of text describing strategic plans. Each major power has their own section and the plans are well organized.
For the French, I’ve started encoding their strategic plan as data.The AIO makes decisions using either LAIO scripts (preferred) or by using a routine hard coded in Pascal, but data driven. Which is used depends on the expediency of writing the code. For example, there are a lot of unique decisions that do not deserve spending the time to write a LAIO script. USSR territorial claims, US entry option choices, and routing resources to factories can be handled better by Pascal code than by LAIO code.
On the other hand, moving units and deciding about attacks are best done using a LAIO script. That way we can add and remove portions of a script while MWIF is executing and immediately test the effect of the changes. MWIF can parse a revised script “on the fly”, which isn’t possible for Pascal code.For the 122 ‘universal’ decision points, I start by writing plain text that describes how the decision is to be made. I’ve done 73 of them as plain text so far.
The second step is to translate the plain text into a LAIO script. All of that work remains to be done.Once all 143 decision points have either Pascal code or a LAIO script, the AIO can execute autonomously. In practice, we will introduce the AIO decisions one at a time, evaluating how good each decision is and modifying the script/code until we are happy with it.Player’s ManualI finished the text for the Production Planning form. It runs to 12 pages.
Here is the opening paragraph:The Production Planning form enables you to:.review resources, factories, and convoy pipelines,.review the build points available for production,.choose resource destinations.modify convoy pipelines,.decide whether oil resources/points are to be used in production or saved, and.choose which resources fulfill trade agreements.To accomplish this the form has 3 layouts and dozens of filters. Key elements of the form are:.A list of resources and factories belonging to a selected major power.Major power flags to change the selected major power.A Summary layout which shows statistics on resources, factories, and production and build points.An Expanded layout which doubles the viewing area for the list of resources and factories.A Route layout, which shows the hex by hex route for a resource from its hex of origination to its destination.An insert map, detailed or global. Both maps display the location of resources and factories.
The global map can be used to review and modify convoy routes.Filters for displaying a subset of the resources and factories (e.g., those that are idle, traded, or use convoys).A default/override table for reviewing the current default/override destinations and actions (i.e., production or saved) for a resource. Posts: 21615Joined: 5/19/2005From: Honolulu, HawaiiStatus: offlineNovember 1, 2010 Status Report for Matrix Games’ MWIF ForumAccomplishments of October 2010Project ManagementI monitored all the threads in the MWIF World in Flames forum daily.I have attached a JPG of the current version of the spreadsheet I created to visually track what has been done and what needs to be done. When I get all (or most of) the pale blue items transformed into dark green, I will return to working on more interesting things: new code for optional rules, PBEM, NetPlay, and AIO. If you want to know why MWIF has taken so long, count the number of dark green cells.Hardware and SoftwareI reinstalled Theme Engine, which appears to be functioning correctly. When I first upgraded Theme Engine for Win7, it was a disaster.
It added bitmap graphics to every button so they could be animated. Because MWIF is close to tapping out Windows graphics resources, the addition of thousands of new bitmaps for buttons caused out-of-memory errors at random places in the code. That was when I was lucky enough to get an out-of-memory error instead of some other mysterious program crash. The reason it works n.
![]() Comments are closed.
|
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |