When?

[Skanvak]

Good,

This is something that upset me in HOI and EiA. You cannot control the allied AI and this is just frustrating.

[nanorider426]

ORIGINAL: Skanvak

Good,

This is something that upset me in HOI and EiA. You cannot control the allied AI and this is just frustrating.

You got that right! In those games the allied AI (especially in EiA) sometimes make huge blunders that human a player would never ever do (except maybe a first time player). You are left to pick up the pieces and such a thing can ruin your whole campaign and make the game unplayable. That's one of the reasons why I'm looking forward to playing MWIF.

[Skanvak]

Especially in WWII were the command was quite unified for the Ally and Axis. May be an option to have Russian / Allied or Axis / Japan not on same side for the AI,anything beyond that is quite irrelevant.

[koontz]

Seems like an release on the horizion

Wikileaks have annouced that an report that something is 7 times bigger than the Iraq report,
Whatelse could it be? [:D]

[ezzler]

Another year rolls around. The calendar clicks over to 2011.

18 months ago this baby was 'imminent'.

What's the status now? 12- 18 months away?
Or something better than that?

[Shannon V. OKeets]

December 1, 2010 Status Report for Matrix Games’ MWIF Forum

Accomplishments of November 2010
Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

Programmer Dreams
I had a dream this past month which you may find amusing. Since the dream is all about programming MWIF, you can take it as my subconscious’ report for the year-to-date. Skip to the section on Hardware and Software if this holds zero interest for you. As background, I used to play golf 3 days a week before starting work on MWIF, but over the past 4 years I have only played twice. I had a 6 handicap so I usually shot in the 70's. Because I played on public golf courses, it was very important to not dawdle and always keep up with the group playing in front of us. This short story is as accurate a remembrance of my dream as I can recall.

The dream started with me arriving at the golf course early in the morning, and being in the first foursome to tee off that day. I didn’t know anyone else in my group, but that was common even when I was playing 3 days a week. The other guys hit their drives and then I was on the tee. I knew I would be rusty and that was confirmed when I hit a couple of drives off into the trees on the left. After giving myself two Mulligans (pretending my first two swings never happened), I decided to go with my 7 iron off the tee - the club with which I am most comfortable and therefore the most reliable. I hit a very good 7 iron shot down the middle of the fairway. Once the other guys had hit their second shots, I needed to choose a club for my second shot. The hole was a short par 4 and I had a good chance of reaching the green, although the fairway was very narrow with trees lining both sides. But I wasn’t sure of the distance to the green so I went looking for a yardage marker. That took a while since I had never played the course before and the other guys couldn’t locate a yardage marker either. I finally found a sprinkler head with 200 yards printed on it and by pacing off the distance from there to my ball I figured I had 190 yards to the hole. That’s usually a 4 iron for me, but being rusty I decided on a 3 iron.

However, when I looked in my bag there were all these extra clubs. It seemed I had put in both my old and new sets of irons, so I had two of everything. Even worse, one of the other guys in my foursome had put most of his clubs in my bag, so I was carrying about 30 clubs instead of 14. I asked the other guy what he thought he was doing, and he said that since I had such a nice new bag with extra room, I could carry his clubs, since his golf bag was old and worn. I argued with him for a while but eventually took out my new 3 iron and walked ahead of my ball to see exactly in which direction I wanted to hit it. The green was slightly off to the right so I planned for my shot to go down the right side of the fairway. Of course when I went back to my ball, I couldn’t find it.

My father showed up then. He was playing in the following foursome and we let his group “play through” since we couldn’t find my golf ball (my father always thought I did things too slowly). Then a foursome of ladies came up and they helped us look for my ball. They belonged to the Sweet Adelines (women’s barbershop quartets) and at some point they were singing. One of them asked if I was playing a Napoleon golf ball and I said, maybe (my ball had NAP printed on it). But what she had found was a rather small cardboard box and when I opened it, inside was a shoe with the brand name Napoleon on it. I then decided to look for the yardage marker again, but couldn’t find that either. Mumbling and grumbling, I decided to just hit another golf ball about where I guessed my original one had been. As I settled over the ball, calming my nerves and breathing, and running through in my head my litany of things to remember about making a good golf shot, a large RV roared onto the fairway pulling a trailer.

The RV came in from the right, crossed the fairway about 50 yards in front of us, and crashed into the trees on the left. It then proceeded to tilt towards us and rolled over twice, with the trailer becoming unhitched and rolling off to the right. A man and his wife got out of the RV with 3 kids and they were all scrambling around the two vehicles. I yelled at the guy that he was completely blocking the fairway but he just ignored me. Then a big backhoe with forklift prongs showed up and started lifting up a large fallen tree to clear the fairway. But somehow the tree got tangled up in overhead power cables which fell on top of the two vehicles, shooting sparks everywhere.

After a while all of that got cleared up but before I could hit my second shot the police showed up. They said the area was a crime scene and we wouldn’t be able to play golf on that fairway today. Not being stopped that easily, I went through the woods on the left until I came to a small clearing that looked out over a nice green valley - which was part of the first hole’s fairway. The green was on the far side of the valley and elevated. I was at the same elevation as the green and had a clear shot across the little valley. It was an odd shaped green, with a small portion on the right front which angled off to the larger portion in the back left. The whole left side of the green was protected by a string of sand traps, with another sand trap behind the green on the right side. I had a clear shot across the valley to the pin, which was in the right front.

Going back to my bag for a 4 iron, I found that instead of removing his clubs from my bag, the other guy had put in a whole lot more - there were now like 50 clubs in the bag. To hide what he had done, he had turned all the clubs upside down so only their grips were visible. It took me a long time to take out all of his clubs so I could find my own. Again I settled over the ball, calming my nerves and breathing, and running through in my head my litany of things to remember about making a good golf shot. At which point a troop of boy scouts charged into the valley and began setting up camp. There were 30 to 40 of them and I yelled at them that they had to move since I was going to hit my shot right over their heads. They grudgingly left but were immediately followed by a dozen college fraternity guys who were more difficult to get to leave. As the frat guys left, I got the distinct impression that they would be back later, to play college pranks on me.

My second shot was good and landed on the green but it was to the left and on the back side. I would have a long putt for a theoretical birdie, but most likely would make par. All of this had taken 2 hours. Given that a group is scheduled to tee off every 6 minutes, and that some groups are six-somes instead of foursomes, there were now about 100 guys backed up waiting to play the first hole. Even worse, everyone else who would play that day would also have a 2 hour delay, all due to my troubles on the first hole. Speaking of which, I still needed to finish the first hole and there were 17 more to play. The day was still bright and sunny. I then woke up and since it was 5:00 am I decided to work on the code for MWIF.

Explanation
In case you haven’t figured it out, here is some of the symbolism. Hitting golf shots = writing code. Finding the ball and figuring out the distance = defining the rules/program specifications. Golf clubs = software routines/modules. The other golfer in my group who keeps putting his clubs in my bag is Chris, who wrote the CWIF code. The RV = the upgrade to Delphi 2010 to support Win7, and the trailer = the Theme Engine upgrade. The cops = my conclusion that the Delphi 2010 debugger was unusable. The boy scouts = the beta testers finding bugs and things in the player interface that need improvement. The college guys = the WIF FE rules grognards. The golfers experiencing an intolerable delay = the players who want to buy a finished MWIF. You might want to read through the dream again and interpret some of the other images and events.

Hardware and Software
I have one problem with Theme Engine for Win7: it is taking too long to switch between major powers. For example, when choosing an action for each major power on the Allied side, the Choose Action form appears 5 times, once for each major power. When the deciding major power changes, the form refreshes to show the background colors et al for the new major power’s theme. That takes about 4 seconds, when it should be instantaneous. That’s too long given the number of times the deciding major power changes during a turn. I’ve got some ideas about why this happens and a couple of possible solutions.

I converted the Unit menu from standard Windows style to Theme Engine, but I still need to perform that task for the Main menu.

Beta Testing
I released versions 6.00.02 (20 fixes), 6.00.03 (2 fixes), 6.00.04 (21 fixes), 6.00.05 (12 fixes), and 7.00.00 (9 fixes), to the beta testers last month. This totals 5 new versions and 64 fixes, which is way under over my previous 4 month average for fixes (112). I changed the numbering to 7.00.00 because I added 3 new phases to the sequence of play - more on that below. The drop off in the number of bugs fixed was caused by my rewriting/restructuring ~6000 lines of code in addition to creating 3 new phases.

I cleaned up all known bugs related to partisans, air rebase, expending oil points, and US entry options. I tend to fix bugs in groups like this so I can work on a single section of code - it always takes a few minutes to refresh my memory about how things work for a rule. For rebasing carrier air units that are aboard carriers, I needed rule clarifications from the rules grognards and (eventually) Harry Rowland.

Version 6.00.03 only fixed 2 items because I had removed a bunch of code that should have been left in place. I needed to quickly upload a new version with the old code restored to keep the beta testers productive. This error on my part was due to the failure of my normal practice of inserting comments so I will understand what the code is doing 1 year in the future. My newly revised practice is to insert comments so I will understand what the code is doing 5 years in the future. The comments I had made in 2006 were so vague that I had misunderstood them.

I rewrote all the code for determining and finding valid rebase hexes. There were two bug reports which prompted me to do this: the search time was taking too long (minutes for a single air unit), and some valid hexes were being missed when triple the range was possible. The CWIF algorithm avoided the first problem by using Assembler code to speed up execution (I had replaced all Assembler code with Pascal code to achieve compatibility with operating system upgrades). The second bug was simply because the CWIF algorithm was wrong. I also revised the code to support clarifications from Harry on where carrier air units can rebase given where they start.

The new algorithm is far superior in that it preforms two searches simultaneously (testing against double the range when flying over enemy hexes and triple the range if enemy hexes can be avoided). It also maintains a list of hexes already examined and a list of sea areas already explored. The latter list is only for carrier air units that started on land and could rebase to a carrier at sea. Both of these lists are stored as arrays so a fast check can be made for whether a hex has already been evaluated. The CWIF algorithm made repeated searches through long lists - which is why it took so long when the range of the air units was large (e.g., > 12). I tested a naval air with a range of 22 using the new algorithm and the response time was less than a second. For most air units the response time is instantaneous. Another test I made for using triple/double range was from southern England to Gibraltar for an air unit with a range of 10. It was able to find the all-sea (no enemy) loop around an Axis controlled Iberia traversing 28 hexes.

By the way, the formula for counting the number of possible rebase hexes is 3X(X +1) + 1, where X is the range. So a unit with a printed range of 22 flying at triple its range is 3*66(66 + 1) + 1 = 13267 possible hexes, or about 1/5th of the global map. The search is much harder than simply checking each hex as a viable destination, since hexes controlled by neutral countries have to be avoided in finding a path to each hex.

Fatal errors during program execution now appear to be solely related to my recent changes to the code, so I fix them quickly.

Saved Games
Saving and restoring games remains stable. I did fix one strange bug with creating AutoSave directories that one of the new beta testers encountered.

Map and Units
Rob continues to send me updates of the naval unit writeups. I renamed the Teheran militia unit so it matches the city name on the map.

Scenarios and Optional Rules
Nothing new here.

MWIF Game Engine and CWIF Conversion
The three new phases to the sequence of play I added are: Production Planning Final, Search and Seizure, and Scrap Destroyed Units. The new sequence of play is:
.
.
• Preliminary Production Planning
• Stay At Sea A
• Stay At Sea D
• Return To Base A
• Return To Base D
• Use Oil
• Final Reorganization
• Break Down
• Final Production Planning (new)
• Search and Seizure (new)
• Scrap Destroyed Units
• Naval Repair
• Production
.
.

The Search and Seizure (S&S) phase was fairly complicated to code because there are a lot of conditions that need to be satisfied before a player can execute a search and seizure. Other annoying elements are that a resource could pass through two or more sea areas that were S&Sed, but obviously the resource would only be ‘lost’ once. More difficult to code was when a non-oil resource, an oil resource, and a build point are going through a sea area and of the 3 convoys being used, only one can be S&Sed. I arbitrarily decided that the lowest value item (non-oil resource) would be lost first to S&S. I placed the highest value on build points. This could be handled using random numbers but that seemed like more effort than the rule deserved. If you are interested, a couple of the Pascal routines for search and seizure are appended to the end of this report.

I added the Scrap Destroyed Units phase because the beta testers have been complaining for over a year about having to make a decision about scrapping every time a unit gets destroyed. That digression could occur in a couple of dozen places in the sequence of play and it was a distraction from what was immediately occurring (e.g., during an air-to-air combat). By simply placing all destroyed units in a big pile and letting the players decide which to scrap once at the end of the turn, the speed of play improves significantly.

There are still two more subphases that need to be add to Land Combat Resolution. Patrice, and others, pointed out that the decision on destroying units must be made by the defender before the attacker chooses whether to convert shattered results into retreats. And disorganizing attacking units needs to occur after the advance after combat. Currently all those decisions/events occur in one subphase and are not done in the order dictated by the WIF rules. I’ll try to get that fixed new month - at which time I will have the full sequence of play finalized and coded.

I rewrote all the code for moving units from the moving stack to a hex on the map. The CWIF code had been driving me crazy for years and I was having a very difficult time debugging land and naval moves (yeah, I know, the land moves should be easy to code). However, the CWIF code was a very long series of if statements. I restructured it using a case statement based on the current phase & subphase of the game. I did the same for Undoing unit moves. Together those routines had been roughly 3500 lines of code.

As an example of why the naval moves are so hard to code, consider a CW naval transport and the Queens located in London. During the naval movement phase the transport loads a division in the port and then both ships move into the North Sea. The transport stops in the North Sea and pick up a second division from Portsmouth. Then the Queens enters Plymouth, where it picks up an infantry HQ, goes out to the Bay of Biscay, enters Bordeaux where it drops off the infantry HQ and picks up an elite infantry corps, reenters the Bay of Biscay and thence into Cape St. Vincent. Ok, now the player wants to Undo all those moves, so it is up to the program to have maintained a record of what got loaded & unloaded where. Throw in the possibility that the Germans attempted an unsuccessful interception in the North Sea and only some of the moves can be undone. There are also rules regarding foreign troop commitments for the BEF in France, so if the HQ and infantry corps are switched, some of those moves by the Queens might be illegal. There is also the possibility that it is late in the war and some of the units are US or Free French, so compatibility between the units has to be considered. This is just for naval movement. There are more rules that apply during the return to base phases and yet more if the naval units are rebasing because they were overrun. Very complex stuff to code.

Player Interface
I changed about a dozen places in the code where a Yes/No question was asked and the player had to answer without having access to information (e.g., the map). Most of the time, these decisions are easy to make, but there are cases where the player might want to review some stuff before deciding (e.g., denying the USSR claim on the Finnish Borderlands). The changes I made enable him to now do so for the more complex situations. Basically, the detailed and global maps and all the informational forms are now available.

I created a new form for Search and Seizure. That whole phase is brand new and needs alpha testing by me before the beta testers take a crack at it. It’s hard to test since there have to be very precise conditions in place before search and seizure can be executed by a major power.

I revamped the Victory form so more room is available for showing the victory points. At times there are little messages included to explain the victory points, and more room was needed. As often happens, because I was forced to make changes, I ended up with a better looking form in the end - I’ll try to remember to post the revised one in the next couple of days.

I rewrote all the code for generating text messages as the cursor scrolls over the map with a unit (or units) in hand. These messages inform the player whether the unit(s) can move to the hex under the cursor and if not, why not. The beta testers had complained about some of the messages being wrong, or at best confusing. But the code was equally confusing - being 2500 lines in a series of if statements. I restructured it using a case statement based on the current phase & subphase of the game. In reality, my motivation for fixing these messages was that I was having trouble debugging naval moves and the erroneous messages were really not helping.

Internet - NetPlay
Nothing new.

PBEM
Nothing new.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
Nothing new. I need to go through the section on the sequence of play and bring it up-to-date so it includes the 3 new phases mentioned above. I also have to add a screen shot and text for the new Search and Seizure form.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Andy Johnson (who did the work to develop the MWIF fan site from nothing) has found a new administrator for the fan site. As I write this we are still getting Paul established as a beta tester.

Communications
Nothing new.

===========================

Code: Select all

 // ****************************************************************************
 function UFilterSearchAndSeizure(const U: TUnit): Boolean;
 // ****************************************************************************
 // •	you must have an SCS, CV, or SUB in the sea area;
 // ****************************************************************************
 begin
   Result := (MajPower(U) = UFMajorCountry) and
             (U.UnitType in [utCarrier, utLightCarrier, utBattleship, utCruiser,
                             utLightCruiser, utAuxiliaryCruiser, utASWEscort,
                             utASWCarrier, utSubmarine]);
 end;
 // ****************************************************************************
 function UFilterSearchAndSeizurePrevention(const U: TUnit): Boolean;
 // ****************************************************************************
 // •	there must not be an SCS, CV, or aircraft unit with an air-to-sea factor,
 //    controlled by a major power with which you are at war in the sea area (nor
 //    a US unit that can escort there because of US entry options 11, 20, 29,
 //    38, or 50 ~ see RAC 13.3.2).
 // ****************************************************************************
 var
   Surface: Boolean;
   NavAir: Boolean;
 begin
   Surface := (U.UnitType in [utCarrier, utLightCarrier, utBattleship, utCruiser,
                              utLightCruiser, utAuxiliaryCruiser, utASWEscort,
                              utASWCarrier]);
   NavAir := (U.UnitType in AirUnitSet) and
             (TAirUnit(U).AirSea > 0) and
             (U.TransportedBy = nil);
   Result := (UFMajorCountry.Relations[U.Country] = crWar) and
             (Surface or NavAir);
 
   if Result then Exit;
 // ****************************************************************************
 // Check for US entry option exceptions.
 // ****************************************************************************
   Result := (UFMajorCountry.Relations[U.Country] <> crWar) and
             (UFMajorCountry.Side = sdAxis) and
             (UFConvoyMajPow = UnitedStates) and
             (MajPower(U) = UnitedStates) and
             (Surface or
              (NavAir and						
               USEntry.OptionChosen(useAirEscort))) and
 // ****************************************************************************
 // If unrestricted naval warfare has been declared, then all US combat units in
 // any section box in all sea areas prevent search and seizure.
 // ****************************************************************************
             (USEntry.OptionChosen(useUnrestricted) or
              ((U.Section = 0) and
 // ****************************************************************************
 // If Arm Merchantmen has been declared, then US combat units in the zero
 // section box of any sea area prevent search and seizure.
 // ****************************************************************************
               (USEntry.OptionChosen(useArmMerchantmen) or
                (USEntry.OptionChosen(useNorthAtlanticEscorts) and
                 (UFSeaArea in [EastCoast, NorthAtlantic, CaribbeanSea])) or
                (USEntry.OptionChosen(useEastCoastEscorts) and
                 (UFSeaArea in [EastCoast, CaribbeanSea])))));
 end;
 

[/color]

[Froonp]

ORIGINAL: Shannon V. OKeets
As an example of why the naval moves are so hard to code, consider a CW naval transport and the Queens located in London. During the naval movement phase the transport loads a division in the port and then both ships move into the North Sea. The transport stops in the North Sea and pick up a second division from Portsmouth. Then the Queens enters Plymouth, where it picks up an infantry HQ, goes out to the Bay of Biscay, enters Bordeaux where it drops off the infantry HQ and picks up an elite infantry corps, reenters the Bay of Biscay and thence into Cape St. Vincent.

I'm sorry, there are errors in there.
What I've underlined in red is not possible.
When the Queens enter Bordeaux and unload the HQ-I, it must stop its move here.
Troops are only unloaded in a port from naval transports when the naval transport stops its movement in a port.

Moreover, when the Queens unloads the HQ-I in Bordeaux, it becomes disorganized, and thus can't load any other unit. His loading ability is used up, as only organized naval transports can load things.

Moreover, the Queens would have needed 6 / 6 in move and range when it "only" have 5 / 6 (move from london in North sea uses 1/1, move from north sea to Plymouth uses 1/1, move from Plymouth to Bay of Biscay uses 1/1, move from Bay of Biscay to Bordeaux uses 1/1, move from Bordeaux to Bay of Biscay uses 1/1, and now the Queens have used up all their range (5) and must stop).

PS : What a dream !!!!

[Ullern]

ORIGINAL: Shannon V. OKeets

The Search and Seizure (S&S) phase was fairly complicated to code because there are a lot of conditions that need to be satisfied before a player can execute a search and seizure. Other annoying elements are that a resource could pass through two or more sea areas that were S&Sed, but obviously the resource would only be ‘lost’ once. More difficult to code was when a non-oil resource, an oil resource, and a build point are going through a sea area and of the 3 convoys being used, only one can be S&Sed. I arbitrarily decided that the lowest value item (non-oil resource) would be lost first to S&S. I placed the highest value on build points. This could be handled using random numbers but that seemed like more effort than the rule deserved. If you are interested, a couple of the Pascal routines for search and seizure are appended to the end of this report.

Good choice.

[Shannon V. OKeets]

ORIGINAL: Froonp

ORIGINAL: Shannon V. OKeets
As an example of why the naval moves are so hard to code, consider a CW naval transport and the Queens located in London. During the naval movement phase the transport loads a division in the port and then both ships move into the North Sea. The transport stops in the North Sea and pick up a second division from Portsmouth. Then the Queens enters Plymouth, where it picks up an infantry HQ, goes out to the Bay of Biscay, enters Bordeaux where it drops off the infantry HQ and picks up an elite infantry corps, reenters the Bay of Biscay and thence into Cape St. Vincent.

I'm sorry, there are errors in there.
What I've underlined in red is not possible.
When the Queens enter Bordeaux and unload the HQ-I, it must stop its move here.
Troops are only unloaded in a port from naval transports when the naval transport stops its movement in a port.

Moreover, when the Queens unloads the HQ-I in Bordeaux, it becomes disorganized, and thus can't load any other unit. His loading ability is used up, as only organized naval transports can load things.

Moreover, the Queens would have needed 6 / 6 in move and range when it "only" have 5 / 6 (move from london in North sea uses 1/1, move from north sea to Plymouth uses 1/1, move from Plymouth to Bay of Biscay uses 1/1, move from Bay of Biscay to Bordeaux uses 1/1, move from Bordeaux to Bay of Biscay uses 1/1, and now the Queens have used up all their range (5) and must stop).

PS : What a dream !!!!

Of course you are right. I should have ended my example with the Queens in Bordeaux.

[nanorider426]

Hi Steve.

Thanks for another good and informative report. This time with the added spice of your interesting (if slightly disturbing) dream. Yipes! When I think about your long, arduous and problemfilled work on MWIF I can't blame your subconsciousness for trying to make sense of it all.

Now hop to it. I want me game!

[;)]

[abb]

Hi all
Newcomer
This neverending story is fascinating
Any chance to become beta tester? Any help would be appreciated I guess, I'd like to jump in

[Shannon V. OKeets]

ORIGINAL: abb

Hi all
Newcomer
This neverending story is fascinating
Any chance to become beta tester? Any help would be appreciated I guess, I'd like to jump in

Welcome to the forum.[:)]

Thank you for offering to help.

We are not taking on new beta testers at this time. I expect the next recruitment period will be in late February or early March of 2011. At that time I will post a request for volunteers and leave the application period open for ~9 days. So check in on the forum once a week to see if applicants are being requested.

[philturco]

Please can someone give me an approximate time of release for this game? Are we talking months? a year? several years? I was very excited a couple yrs ago when I first heard about this game. We wait and wait and wait...and nothing happens. What's the big hold up? Will this game ever be ready?

[rkr1958]

ORIGINAL: Shannon V. OKeets
I used to play golf 3 days a week before starting work on MWIF, but over the past 4 years I have only played twice. I had a 6 handicap so I usually shot in the 70's.

I found that a bit sad. If I had a vote in this, which I don't, and if it mattered, which it doesn't, I would vote for you playing a minimum of 6 times a month. Life's too short to give up something that you obviously enjoyed so much and are good at.

[Shannon V. OKeets]

ORIGINAL: rkr1958

ORIGINAL: Shannon V. OKeets
I used to play golf 3 days a week before starting work on MWIF, but over the past 4 years I have only played twice. I had a 6 handicap so I usually shot in the 70's.

I found that a bit sad. If I had a vote in this, which I don't, and if it mattered, which it doesn't, I would vote for you playing a minimum of 6 times a month. Life's too short to give up something that you obviously enjoyed so much and are good at.

Well, I guess one sign that I am getting close to done is if I start playing golf again.[:D] I would have to go back to the driving range for at least a month though - that and practice putting would be necessary. Otherwise I would be infuriated the whole time I was on the course.[:@]

What is difficult about playing golf while MWIF remains unfinished is waiting. You wait to get to the first tee, for the people in front of you to hit their tee shots, reach the green, putt out, ...[>:] In all those idle moments, I think about what I could be getting done on MWIF.

One of the last times I was on a golf course was as a caddy at a Pro-Am here in Honolulu. By the luck of the draw I was caddying for a woman (amateur) who had won the Women's Canadian Open ~10 years previously. She hit her first shot out-of-bounds for a 2 stroke penalty. But then she proceeded to make par on the first hole (not counting the penalty) and played the rest of the round at even par - very impressive.

[rkr1958]

ORIGINAL: Shannon V. OKeets

ORIGINAL: rkr1958

ORIGINAL: Shannon V. OKeets
I used to play golf 3 days a week before starting work on MWIF, but over the past 4 years I have only played twice. I had a 6 handicap so I usually shot in the 70's.

I found that a bit sad. If I had a vote in this, which I don't, and if it mattered, which it doesn't, I would vote for you playing a minimum of 6 times a month. Life's too short to give up something that you obviously enjoyed so much and are good at.

Well, I guess one sign that I am getting close to done is if I start playing golf again.[:D] I would have to go back to the driving range for at least a month though - that and practice putting would be necessary. Otherwise I would be infuriated the whole time I was on the course.[:@]

What is difficult about playing golf while MWIF remains unfinished is waiting. You wait to get to the first tee, for the people in front of you to hit their tee shots, reach the green, putt out, ...[>:] In all those idle moments, I think about what I could be getting done on MWIF.

One of the last times I was on a golf course was as a caddy at a Pro-Am here in Honolulu. By the luck of the draw I was caddying for a woman (amateur) who had won the Women's Canadian Open ~10 years previously. She hit her first shot out-of-bounds for a 2 stroke penalty. But then she proceeded to make par on the first hole (not counting the penalty) and played the rest of the round at even par - very impressive.

I used to play a bit in my late 20's but haven't played in over 20-years. At the time I was single and we were learning. I did break 90 once (shot at 88) but mostly I would shot around 100. I considered it a good round if I broke 100. We may have scored high but we were fast. We would finish our rounds in 4-hours or less, assuming we didn't have to wait for the foursome in front of us. That's why we tried to always be the first of the tee. I could only dream of what it was like to play with a 6 handicap. Maybe you could get some frustration out at the driving range. You don't have to wait for anyone there to hit. [:)]

[Shannon V. OKeets]

January 1, 2011 Status Report for Matrix Games’ MWIF Forum

Accomplishments of December 2010
Project Management
I monitored all the threads in the MWIF World in Flames forum daily.

I restructured by task list so the items needed to completely debug Solitaire play have highest priority. There are 169 bugs remaining for that and I am driving to fix them all by February 1st. Since there were 460+ at the high water mark this past summer, this is doable if I do not get distracted by other issues. To kill off 6 per day is my goal. Attached is my current spreadsheet on the bugs remaining [the bug counts don’t match because the spreadsheet contains items for the other modes of play].

The other big news is that Mitchell has volunteered to help with the MWIF programming. The MWIF code has a steep learning curve but he has overcome the first hurdles of installing/upgrading Delphi, Theme Engine, and the JEDI library. He can now recompile and link the MWIF source code to generate the MWIF.exe. That is not a minor achievement. You’ll find his summary of progress below in the section on NetPlay.

Hardware and Software
Mitchell is also doing detailed timing studies on why Theme Engine takes so long to switch between major powers. Once we have figured out where the time goes (lyrics from a 1960's song), we’ll be able to make changes. It is fruitless to make changes to Theme Engine and just hope they solve the problem.

I converted the Main menu from standard Windows style to Theme Engine. So, aside from the above problem, Theme Engine now runs cleanly under Win XP, Vista, and Win 7.

Beta Testing
I released versions 7.00.01 (6 fixes), 7.00.02 (20 fixes), 7.00.04 (14 fixes), 7.00.05 (21 fixes), 7.00.06 (6 fixes), 7.00.07 (14 fixes), 7.00.08 (10 fixes), 7.01.00 (11 fixes), and 7.01.01 (10 fixes), to the beta testers last month. This totals 9 new versions and 112 fixes, which is above average for both new versions and fixes. I changed the numbering to 7.01.00 because the patch count was getting pretty high for 7.00.

I removed all the calls to Scrap Unit Digression and added the new phase Scrap Destroyed Units so it precedes the Production phase. This had the unexpected benefit of maintaining a list of destroyed units for the turn that players can review. It only took a couple of minutes to add that list to the Pools form (where you can also view units in production, in construction, repair, scrapped, etc.).

I cleaned up all known bugs related to Stay-at-Sea and Sentry status. The later is a feature of the computer game which has a dual purpose: (1) skipping Sentry units when cycling through all the units that can move in a phase, and (2) during the stay at sea phases, those marked as Sentry automatically stay at sea.

I reduced the land movement bugs from 26 to 10. Some of these dated back to 2006. See the paragraphs on Player Interface below for more details.

Fatal errors are becoming more and more scarce and quickly corrected. I fixed a rather infamous one from CWIF that occurred during Vichy formation.

Saved Games
Saving and restoring games remains stable. I had to add a few more variables to the saved game format to handle changes to the player interface for land movement (see below).

Map and Units
Rob continues to send me updates of the naval unit writeups. Otherwise the data and graphics for the map and units are unchanged.

Scenarios and Optional Rules
I added code to handle specific rules for declarations of war in the Day of Infamy scenario.

MWIF Game Engine and CWIF Conversion
I reworked all the code and internal data related to transported units. Some of this involved renaming variables and functions so that I could read the code more easily. I did find redundant code and I cleaned up a lot of other stuff that was messy. One helpful change, purely cosmetic, concerned the 250+ references to TransportedBy being equal to nil or not. I changed “TransportedBy <> nil” to Aboard Transport and “TransportedBy = nil” to Not Aboard Transport. Removing the reverse negation really helps when reading the code. That is, in the CWIF code “not equal nil” implies the unit is aboard a transport, or more simply, ‘not’ implies ‘is’. It is very easy to misread logic sequences that contain what I am calling “reverse negation expressions”.

Another example of a CWIF reverse negation expression was the Ignore Notional Unit form. The defending player was asked if he wanted to ignore the notional unit in an invasion/paradrop. If you answered No, then the notional unit was added to the defending units: ‘no’ implies ‘add’. This past October (November?) I revised that form so the question now is “do you want to include the notional unit?”, so ‘yes’ implies ‘add’. It’s now named the Include Notional Unit form.

I also built an enumeration list of the possible relationships a unit might have in regard to transporting or being transported by another unit. CWIF used “if ... then ...” logic sequences to make these determinations (in hundreds of places). With the enumerated list, MWIF code replaces those with a single case statement based on TransType. Here are my in-line comments on the enumerated list values:

TransType is used to record the linkages between units that are transporting other units, transported by other units, or have recently unloaded from another unit.
• trtyIng1 - Self is currently transporting 1 unit.
• trtyIng2 - Self is currently transporting 2 units.
• trtyIng1U - Self is currently transporting 1 unit, but it had been transporting a second. Self is a non-carrier naval unit.
• trtyUnloaded1 - Self (a naval unit) unloaded 1 unit after moving.
• trtyUnloaded2 - Self (a naval unit) unloaded 2 units after moving.
• trtyBy1 - Self is currently transported by 1 unit.
• trtyBy2 - Self is currently transported by 2 air transports.
• trtyByR - Self is currently transported by a carrier & rebased from a different carrier in the AirRebase phase.
• trtyNormalUnload - Self unloaded from a naval transport that returned to port or Self unloaded from an air transport that was aborted in the Paradrop or AirTransport phases.
• trtyFromUnload - Self (a land unit) unloaded from a naval transport in the UnloadLandUnits phase.
• trtyFromInv - Self unloaded from a naval transport in the current or immediately previous Invasion phase.
• trtyFromAirRebase - Self (an air unit) unloaded from a naval transport or carrier in the AirRebase phase.
• trtyFromCarrier - Self is a carrier air unit either flying an air mission or engaged in a naval air combat.

&#9633; In all the above cases the other units are stored in TransLink[1] and TransLink[2].
&#9633; In the trtyBy2 case, TransLink[1] and TransLink[2] both have a TransType of trtyIng1, even though they are only carrying half of the transported unit.
&#9633; In the trtyByR case, TransLink[1] is the current carrier and TransLink[2] is the carrier Self was aboard at the start of the phase.
&#9633; In the trtyFrom and trtyNormalUnload cases, the TransLink[1] value is used to undo the move.
&#9633; In the trtyFromInv case, the TransLink[1] value is used to determine from which section box the unit is invading.
&#9633; In the trtyFromCarrier case, the TransLink[1] value is used when the player wants the carrier air unit to return to the carrier from which it started the mission.

What motivated me to spend a week making these changes was the difficulty in debugging the code related to undoing air and naval moves when transported units were involved. Picking units up from coastal hexes during naval movement was particularly complex. For example, in a single move, a transport could start empty in a port, go out to sea, then go through a different port and pick up a division and then go out to sea again, stop, and pick up a carrier air unit from a coastal hex. Then the player decides to cancel/undo the move - so the program logic has to be capable of getting all the units back to their correct starting points. As you can see from the above list, that is only one of the dozens of possible air and naval moves that require special code so the move can be correctly ‘undone’.

Once all the changes to the transported unit code were made, I was able to clean up ~10 bugs related to transported units painlessly, and in the sure knowledge that the changes weren’t going to mess up any of the other cases in the above enumerated list.

I revised the code for placing units in off-city hexes when that optional rule is in effect. This change was to accommodate more than 1 major power placing units during the Reinforcements phase. The CWIF code assumed there would only be 1 major power doing that at a time, but with NetPlay there could be as many as 6 major powers doing so simultaneously. Therefore, there needed to be separate variables for each major power instead of a single variable. This affected a lot of variables, especially in save and restore game. It is also why the version 07.00.03 was never uploaded. I made the new changes to GameSaveRestore for 07.00.04.

Player Interface
I added names to the Unit Data Panel, so transported units identify which unit(s) they are carrying and transported units identify by which unit(s) they are being carried.

I identified a dozen queries where the player may want to examine the map and other forms before answering the question. For example, when Germany is deciding whether to grant the USSR’s claim on the Finnish borderlands, checking the disposition of the USSR forces is a good idea. Instead of these queries being shown on a modal form (which freezes the player interface until the question is answered), they are now shown using a non-modal form, so the player can dilly dally about looking into every unit stack on the map before making these decisions (as he might infuriatingly do in an over-the-board game).

I added double-left-click to select all naval units in the Setup Tray. This is in lieu of Ctrl A for selecting all units. The units selected are those shown using the setup tray’s filter (e.g., just battleships). The purpose here is to enable a player to select a large number of naval units for placement without having to click on individual units. Selecting all air units is difficult to design and code because of the need to decide which units go to the reserve pool. And selecting all land units doesn't make a lot of sense because of stacking limitations. So, this feature is just for naval units.

I added a unit menu item “Return from Whence” for air units that fly missions. Clicking on this menu item returns the air unit to the hex or carrier from which it started the mission. This saves a lot of time if you simply want air units to go back to their original air base/carrier. That’s especially true when you have a lot of carrier air units returning from a naval air combat. In combination with the Selectable Units form, which lists all the air units returning to base, players can complete a return to base subphase quickly, without little effort.

I clarified the anti-aircraft results form by adding some more information. I decided when a person who has been an active beta tester for CWIF and MWIF (over 12 years) gets confused, it is time to change the displayed information.

Lastly, I made final decisions concerning the player interface for land movement and wrote new code for about half of them. These problems were identified early in my work on MWIF, in 2005 and early 2006. But I had a lot of other things that needed to be done first, so I have let them simmer for years. Occasionally the topics would surface again in the beta tester development forum, but they were very thorny issues and intricately interrelated. I am now confident that I have solutions for all of them and I am working on writing the code to implement them. The problems were:
1. Partial movement of a unit such that the unit has movement points remaining. This occurs when a stack overruns enemy units and still has movement points remaining. The stack’s move can be interrupted by a digression to rebase overrun units.
2. Undoing moves.
3. Friendly and enemy units whose supply status changes during the phase.
4. Overstacking.

Our primary goal is to make MWIF play like the board game. While the WIF FE rules impose rigid restrictions on what can and can not be done, in practice over-the-board players use looser rule interpretations. It is common practice to let a player “take back” several moves during the land movement phase, as long as nothing substantial has happened and everyone can agree on where the units started the phase. Likewise, swapping units between hexes that are fully stacked is usually permitted, as long as the overstacking is corrected by the end of the ‘step’. But enabling these abilities lends itself to potential abuse by players of MWIF. Hence the need to define exactly what is and is not permitted for the above 4 items. For details, see section 8.4.5.1 of the Players Manual, which is appended to the end of this report.

Internet - NetPlay
From Mitchell (edited by Steve):

Steve asked me to see what I could do to get NetPlay fleshed out sufficiently to start testing MWIF’s multi-player modes: NetPlay and PBEM. Being new to the project, this meant coming up to speed on the Delphi IDE, the Indy socket library, and the earlier version of NetPlayComTest. After much experimentation, I developed several interim NetPlayComTest versions and tested them in small group sessions, culminating at the end of the month with uploading NetPlayComTest version 1.2.0.0 for all the beta testers to test. Feedback from the beta testers running NetPlayComTest on a variety of network setups will enable me to validate a final version of NetPlayComTest. Then that code can be integrated into MWIF’s NetPlay. [Note that NetPlayComTest will be a stand alone executable for delivery with the released MWIF product, so players can test their internet communications without having to run a MWIF game.]

A key concept for NetPlay is that one or two of the players’ computers act as a server. NetPlay supports from two to six players, with one player on each side acting as Leader for that side. Each Leader’s computer can act as a server (in the network sense) for his side, and one Leader’s computer is the game’s Master server. The Master server keeps the master record of game state, marshals communication between players and sides, makes die rolls, etcetera. Which player’s computer acts as Master and/or Leader depends on the scenario played, the number of players, and possibly the stage the game is in. For example, one server is sufficient unless there are 4 or more players in the game.

Having a player’s computer act as the game server is a different architecture from what many online games employ, where there is usually one or more dedicated servers/machines that each player logs into. While this common approach scales well and so can support massively multi-player games, it lacks the kind of flexibility desired for MWIF. MWIF contains many features that will help make the speed of play comparable to WIF, the board game, but MWIF playing sessions are still likely to be protracted affairs. To maintain maximum flexibility in the event of lost connections, players having to log off and back on for various reasons, and so on, NetPlay is designed so that any player may act as the game Master and/or side Leader as the game progresses and players (or even all players on one side) leave and rejoin a game. This architecture is a challenge to implement programmatically but doable, and it should serve well for the style of play MWIF demands.

The state of NetPlay development as of 31 December 2010 is summed up in the functionality of the latest NetPlayComTest version: up to six computers on a LAN and/or the Internet can establish communication through NetPlay and use the link to send and receive message packets reliably for extended periods.

Steve had already set up a framework in MWIF for building the necessary message packets containing game state and event information, so adding the communication functions from the test utility should bring us very close to testing MWIF multi-player modes. The next steps in NetPlay development are:
1. Add a NetPlay setup dialog to allow entry of IP Addresses associated with each player and to keep track of which players are the game Master and Leaders, and who is playing which Major Power Group. This information will persist in an associated INI file that can also be used by MWIF.
2. Set up and attempt to establish connections automatically based on information read from the INI file.
3. Attempt to reestablish communication links if and/or when they are dropped.
4. Reassign computer roles of game Master and Leaders if players, or a whole side, drops out intentionally or unintentionally, temporarily or for the duration of that gaming session.
5. Add PBEM simulation, replacing TCP message transactions with programmatically generated email messages but using the same logical player framework outlined above.
6. Integrate everything back into the MWIF code base, replacing test messages with the Game Record Log messages, support for game re-synch from the Master, chat between players and among each side, etcetera.

Please let us know what you would like to see in the way of inter-player communication support.

PBEM
Once Mitchell gets the NetPlay communications working, he’ll do the same for the PBEM communications.

Artificial Intelligence (AI)
Nothing new.

Player’s Manual
I added new subsections in the Player Interface section, specifically addressing how to move land, naval, and air units. While the description of the keyboard and mouse commands is accurate and complete, it doesn’t really answer the questions new players are likely to have about how to “get things done”. I’ve appended the new subsection on moving land units to the end of this report. I still need to write similar subsections for moving naval and air units.

Tutorials, Training Videos, and Context Sensitive Help
Nothing new.

Historical Video, Music, and Sound Effects
Nothing new.

Marketing
Paul is now the administrator for the fan site.

Communications
Nothing new.

===========================
8.4.5.1 Land Movement
Left clicking on a selectable land unit during the land movement phase transfers it to the “moving stack”, which, if you are familiar with board war games, you can think of as “picking up a unit”. The cursor then displays the selected unit which is no longer shown in the hex it had been occupying. As you move the cursor over the map, the cursor superimposes a target symbol (circle inside a cross) onto the image of the moving unit to indicate a valid destination hex. For invalid hexes, a large X is superimposed. At the bottom of the Main form, a text message augments the cursor’s information. For example, for a valid destination hex, the number of movement points required to enter the hex is shown. If a destination is invalid, the text message explains why.

Default Path
The easiest way to move a unit is to “pick one up” and left click on a destination hex. The program finds the fastest path to the destination hex. Here fastest means the path that requires the fewest movement points. Although visually the unit appears to ‘jump’ from its original hex to the destination hex, in actuality the program moves the unit along the fastest path, just as if you had moved the unit one hex at a time.

Precise Path
If you do not want to use the program’s chosen path, you can control which hexes the unit enters by holding down the Ctrl key and left clicking on each hex in the path you want the unit to traverse. In fact, you can combine these two methods. For instance you could use the Ctrl key and click on the first hex in the path and then release the Ctrl key and click on a final destination hex several hexes away. Entering a precise path for a unit is often done by the German player when advancing through Russia to make sure that control of every hex changes from the USSR to Germany.

Group Movement
If you want to move several units as a group (e.g., to conduct an overrun) you can either select them using the Flyouts form (see section 8.4.6), the Units in Hex form (see section 8.7.1.24), or using Ctrl-Left-Click in the unit’s start hex (see section 11.8). All the units you select have to have started the impulse in the same hex. Once you have selected a group of units, you move them the same way you move a single unit.

Partial Movement and Overruns
You can move a unit to a preliminary destination hex and then pick it up again and move it to a final destination hex. In fact, this is what happens when you hold down the Ctrl key to enter a precise path. This ability is most important when you conduct an overrun. After the defending units have been destroyed, captured, or forced to rebase in an overrun hex, you can continue to move the overrunning units by picking them up again, provided they have movement points remaining. Because of the zones of control rules, for some overruns you may have to first use the Ctrl key to move your units to the hex adjacent to the hex you want to overrun and then pick them up again and click on the overrun hex.

Once you have completed moving a unit or stack of units and picked up a different unit, you can no longer go back to the first group and move them again. This is true even if the first group still has unused movement points. This is how MWIF implements the Rules As Coded rule: “You must finish moving the unit(s) you are moving before you can start moving another unit”.

Undoing Moves
MWIF is somewhat forgiving in that it usually permits you to undo your moves without regard to the order in which they occurred. For example, you can move unit A, then move unit B, and then go back and undo unit A’s move. Indeed, there is a menu item on the drop down Command menu of the Main form that lets you undo all moves. There are two important exceptions to this leniency.

1. Should you conduct an overrun, then all the moves you made prior to the overrun can no longer be undone. The overrun might even have been made by one of your allies, and occurred thousands of miles away. Regardless of where and what is overrun, as soon as an overrun is performed, all land moves made previously in the impulse become permanent and can not be undone.

2. Should an out-of-supply or isolated unit have its supply status improved (e.g., from out-of-supply to in-supply), then the program marks the unit with the Improved Supply Status as ISS. If an ISS unit moves, then all moves made prior to that action are ‘frozen’. That is, you are unable to Undo any previous moves unless you first Undo the ISS unit that moved. The reason for this rule is to prevent exploitation of the Undo move to circumvent the rules by, say, (1) moving a unit to provide supply to other units, (2) moving the newly in-supply units, and then (3) undoing move #1.

Overstacking
In general, units may not overstack during land movement. However, MWIF enables temporary overstacking, primarily to enable players to rearrange units in hexes that are fully stacked. A typical instance of this is when the French have 2 corps in every hex of the Maginot Line and want to switch which units are in which hexes. To facilitate this, MWIF permits units to be overstacked when a unit, or stack of units, ends its movement. But then the next unit or stack of units that moves has to correct the overstacking. In the case of two French corps, A and B, in Metz, and two more corps, C and D, in Strasbourg (adjacent to Metz), the player is permitted to move unit A to Strasbourg, even though that causes overstacking. But then his next move has to be to move unit A, C, or D out of Strasbourg, to eliminate the overstacking.

Temporary overstacking enables you to move a stack of units from behind your lines up to a hex in your front line (which becomes temporarily overstacked) and then continue moving by overrunning units in the enemy’s front line.

Another subtlety of land movement and overstacking is when an HQ or an engineer has been used to enable air units to overstack in a hex. Moving the HQ or engineer out of the hex would then cause the air units in the hex to be overstacked. MWIF permits this overstacking to occur, and permits it to remain in effect until the end of the land movement phase. So, if you move an HQ out of a hex, causing air units to be overstacked, later in the phase you can move another HQ (or an engineer) into the hex, thereby negating the overstacking. Failure to correct the overstacking by the end of the land movement phase means the owner of the air units has to chose which air unit(s) to destroy.

[warspite1]

Steve / Mitchell

This is a highly encouraging report, and a great way to start 2011 [&o]

[finchen]

I stumbled across this 1 week ago , and can honestly say that had I found it 2, 3 or 5 years ago I would have had suffert extreme stress traumata meanwhile, I used to play WiF for years, but now having moved to another country and beeing married with children I lack a) people in my neighbourhood to play with and b) space to setup and leave the map for a couple of weeks without someone potentially destroying it.
A computer game version would be the answer to all my hopes.
I would like to offer my help to get the game done, besides having some WiF experience, I am quite familliar with WW2 History and am a professional software engeneer, having programmed in Delphi until 2006 (Delphi 7 then).

If there is anything I can do within my free time, pls tell me.

[Shannon V. OKeets]

ORIGINAL: finchen

I stumbled across this 1 week ago , and can honestly say that had I found it 2, 3 or 5 years ago I would have had suffert extreme stress traumata meanwhile, I used to play WiF for years, but now having moved to another country and beeing married with children I lack a) people in my neighbourhood to play with and b) space to setup and leave the map for a couple of weeks without someone potentially destroying it.
A computer game version would be the answer to all my hopes.
I would like to offer my help to get the game done, besides having some WiF experience, I am quite familliar with WW2 History and am a professional software engeneer, having programmed in Delphi until 2006 (Delphi 7 then).

If there is anything I can do within my free time, pls tell me.

Welcome to the forum.[:)]

I'll send you a PM (personal message) about helping program.[&o]