Taking Long Time to Move (Some) Units

[rkr1958]

For the game file, which I'll upload in the next post; (re)loading the game, picking up HQ units, putting down HQ units and changing hex control (by moving units through them) is now taking a maddening long time on my computer.

I'll give five examples:

(1) To load the game (on my computer) took 2-minutes & 50-seconds.

(2) Just picking up the Mongolian cavalry corps took 30-seconds.

(3) Then moving him to hex [50,157] took another 1 minute & 30-seconds (that's 2 minutes to move him!).

(4) In Turkey, picking up Bradley took 1 minute & 18-seconds.

(5) Placing Bradley in hex [68,59] (adjacent to where he is now) took another 1 minute & 30-seconds (that's almost 3-minutes to move 1 HQ unit!).

[rkr1958]

game turn. By the way, I'm running MWiF version 3.0.3

[Centuur]

Known problem. It happens especially when either Germany or the USSR gets conquered in combination with a lot of units on the map, including a lot of HQ's of major and minor countries. The number of supply calculations increases during the game due to the higher number of units on the map.

It's not nice, but I don't think that Steve can fix this. The last time he tried to reduce the number of calculations regarding supply some units where given incorrect supply status...

[rkr1958]

ORIGINAL: Centuur

Known problem. It happens especially when either Germany or the USSR gets conquered in combination with a lot of units on the map, including a lot of HQ's of major and minor countries. The number of supply calculations increases during the game due to the higher number of units on the map.

It's not nice, but I don't think that Steve can fix this. The last time he tried to reduce the number of calculations regarding supply some units where given incorrect supply status...

I know it won't happen but it'd be nice to have an "off/on switch" for the supply calculation. For example, it's frustrating to pick up a unit, see the program take 2 minutes to (re)calculate supply, move the unit and then see the program take another 2 minutes to recalculate all supply. It took me 3-hours last night to move units in a single impulse which should have been able to do in 10 or 15-minutes. Maybe on/off switch for solo only? In the situation I'm in, I'd like to make my the majority of my moves with the switch off and then switch it on when I need to check/verify supply.

I know this wish is pie in the sky but it would definitely be useful for folks like me that play games out to the bitter end. Oh well ... one certainty can wish.

[Numdydar]

It would likely be easier to get a faster computer

[rkr1958]

ORIGINAL: Numdydar

It would likely be easier to get a faster computer

It'd be nice to see what difference a "faster" computer would make before buying one solely for reducing MWiF lag times. If anyone who's an owner of a new, fast computer is so inclined I'd like to see what their lag times are compared to mine for the 5 "benchmarks" in my initial post of this thread using the game turn attached in the second post.

Below are my machine specs. I do feel my machine is no slouch but maybe I'm wrong and a newer machine would be faster?

[paulderynck]

Out of several thousand CPUs on a benchmark site I checked, yours ranked 720 (lower numbers are better) and mine ranked 598. I have 16 gigs of RAM. Our machines are not blindingly fast but neither are they shabby.

I checked the same 5 time tests as in your first post and got these results:
1. 2:45
2. 13 sec
3. 1:10
4. 1:13
5. 1:21

So I'd say CPU upgrades are not going to fix this problem. It's likely due to supply calculations and high unit density, perhaps combined with some lengthy non-conventional supply path permutations.

[GenChaos33]

Looking at OP pics. One thing that stands out to me is that all the higher detail game graphics options are 'on'.

Weather is on, Hex Owner Flag is on, High Detailed Counters is on, Map Name Labels/Texts is on.

Very well could be that I know NOTHING about computers, but I sure would re-run the same 5 examples with those options 'off'.

Are times still the same?

[paulderynck]

Trust me, they really would not make an appreciable difference. I have invested sufficient time in trying this, but you are most welcome to benchmark the possibilities.

[BrianJH]

A question for Steve. Is MWIF multi-threaded? That is, does it utilize more than one CPU if present in your PC?

If the answer is no, perhaps implementing multi-threading might be one way to speed things up, particularly with the supply calculations.

Brian.

[Shannon V. OKeets]

I am familiar with Rkr1958's current game from all the bug reports he has posted.[&o][&o]

While I would like MWIF to have instant response times, that game reflects some of the strange positions players can create.

Just looking at the screen shots he posted, you can see that:

(11) the Polish HQ (controlled by the Commonwealth) is now in Manchuria. Since the USSR and the Commonwealth do not cooperate, that HQ is using a rail line back to someplace in Europe and then getting supply overseas from Great Britain.

(2) The Communist Chinese have also advanced into Manchuria, although their cavalry cannot trace supply back to Mao (or a Communist controlled Chinese city).

(3) The Japanese had invaded the USSR in Siberia and cut the rail line between Vladivostok and Russian cities to the west. The Russian armor HQ is getting supply from Khabarovsk, while the Mongolian cavalry is getting supply from Blagovyesht...

(4) The US and Commonwealth have taken over most of Turkey but isolated pockets of Axis units remain, including some on the coast of the Black Sea.

====

In my opinion this game is over. The Allies are beating a dead horse. I count 15 very nice Commonwealth air units in Turkey, plus at least 8 US air units, all of which are being devoted solely to extinguishing a couple German garrison units 'supported' by some worthless air and naval units. Yeah, supply calculations will take a while.

[Shannon V. OKeets]

ORIGINAL: BrianJH

A question for Steve. Is MWIF multi-threaded? That is, does it utilize more than one CPU if present in your PC?

If the answer is no, perhaps implementing multi-threading might be one way to speed things up, particularly with the supply calculations.

Brian.

Not really an issue.

Setting up multi-threading would only be useful if there were separate tasks to be performed simultaneously. That isn't the case in MWIF. The player can implement decisions more or less continuously, and the program has to respond to each of them completely. Writing code that tries to anticipate what the player is about to do would be a fool's errand (in my opinion).

[rkr1958]

ORIGINAL: paulderynck

Out of several thousand CPUs on a benchmark site I checked, yours ranked 720 (lower numbers are better) and mine ranked 598. I have 16 gigs of RAM. Our machines are not blindingly fast but neither are they shabby.

I checked the same 5 time tests as in your first post and got these results:
1. 2:45
2. 13 sec
3. 1:10
4. 1:13
5. 1:21

So I'd say CPU upgrades are not going to fix this problem. It's likely due to supply calculations and high unit density, perhaps combined with some lengthy non-conventional supply path permutations.

Thanks! By my quick calculation the total time in seconds for my machine for all five tasks was 453-sec and for yours 402-sec. So overall your machine ran those tasks 51-sec, or 11.3% faster. In a way that's comforting knowing that my machine is only 10% or so slower than yours.

ORIGINAL: Shannon V. OKeets

I am familiar with Rkr1958's current game from all the bug reports he has posted.[&o][&o]

Thanks! Just trying to do my duty as a dedicated MWiF player and enthusiast. [8D]

[TeaLeaf]

Is it an option to reduce the recalculation of supply to

- only after an HQ has completely finished its move?
So, do not recalculate when the HQ is picked up. That's unnecessary. It only matters when the HQ is in a hex again.
Also, if an HQ could manually be labeled as 'done moving' by the player, supply recalculation can be limited to only ONCE per moving HQ. That is, immediately after the player labels the HQ as 'done moving', or if the HQ has no movement points left (in which case it is automatically labeled as 'done moving').

As it is now, if I pick up an HQ, supply is recalculated. If I put it in the first hex of its movement, supply is recalculated. If I pick it up again to move it another hex, supply is... etc. Somehow it should be possible to only recalculate supply for each moving HQ just ONCE; after it has reached its destination hex and is completely done moving.

-Similarly, only after each other (non-HQ) unit has completely finished its move.
So not everytime it is picked up plus every hex it is put in on the way to its destination... Only when it is done moving or conducting an overrun.

Or even better, only recalculate each time an HQ has completely finished its move, each time a hex is left with no land units in it (as this could alter the supply status of subsequenty moving units), each time an overrun is made and after all other units have moved. But in this case there has to be a 'recalculate supply' button somewhere, which has to be pressed before the 'end phase/subphase' button can be pressed. Otherwise a player would be forced to arbitrarily move all his/her units in order to end the phase.

I'm thinking solutions like this can seriously reduce supply calculation time by skipping calculation when it is unnecessary.
Not calculating when every unit is just picked up but only when it is put back in a hex again/reaches its destination, would reduce time by 50%.

[Shannon V. OKeets]

Supply has to be recalculated whenever a land unit is selected for movement. That is because there is always the possibility of an overrun, for which the program needs to know which units are in supply and which are not.

[pzgndr]

ORIGINAL: Shannon V. OKeets
Supply has to be recalculated whenever a land unit is selected for movement. That is because there is always the possibility of an overrun, for which the program needs to know which units are in supply and which are not.

Not really, there is not always a possibility of overrun for every selected unit; there may be no eligible enemy units within range of the selected unit for it to reach. So perhaps a simple check to verify the selected unit is in fact eligible to perform an overrun might screen out many unnecessary supply recalculations? If overrun is the only consideration. Just a thought.

[paulderynck]

And/or a check first that the unit is Armor or Mech?

[TeaLeaf]

Plus, why do units have to trigger a recalculation on pickup because it -might- do an overrun?
Instead, can't there be a recalculation only when an overrun is actually being conducted? And if not, if a unit is designated for one or more overruns by the player?

Because waiting time could drastically be shortened if supply recalculation during land movenent is only done
- after an HQ completed its movement (so not at pickup already);
- during an overrun;
- when a hex in an enemy ZOC is left without any land units in it;
- at the completion of the movement phase (possibly triggered by clicking the end phase button).

[Shannon V. OKeets]

Overruns can be done by any land combat unit - against hexes occupied by enemy air and/or naval units.


Adding in even more conditionals to whether supply should be recalculated when a land unit moves would not be a good thing - from the programmer's perspective.

The routine that makes this determination is 2350 lines long. Here is my in-line comment on what it does. Note that towards the end, I got tired of looking up the name of the individual routines that perform the work and just used ??????? as the procedure/function name.

===

// ****************************************************************************
// Variables that control when supply is recalcuated.
// ****************************************************************************
// SupplyExecutedOnce is set to True when supply is calculated from scratch.
// That forces the full execution of UnitMenuSupplySources when creating a new
// game or restoring a saved game.

// Thereafter, the routines LeaveMapHex and EnterMapHex call EvalSup routines
// based on the unit type and whether the hex the unit is leaving/entering is an
// all-sea or a land hex. SetHexControl calls EvalSupHexControlChange to
// process changes in hex control which affects which units can use a given hex
// in a supply path.
//
// The EvalSup routines set Eval Supply flags (e.g., EvalInSupplyAxisLand):
// (1) to validate overland supply paths for in-supply units on a side,
// (2) to validate overseas supply paths for in-supply units on a side,
// (3) to search for overland supply paths for OOS units on a side,
// (4) to search for overseas supply paths for OOS units on a side, and
// (5) to execute FindSupplyPathForStack for the moving units.
//
// The last of the above is executed for the units in the moving stack if their
// destination is a land hex, since a new supply path has to be found for them.
//
// The routines that initiate calls to LeaveMapHex/EnterMapHex, or cause changes
// in hex control (e.g., Conquest), post-process those calls by executing
// UnitMenuSupplySources, part or all of which executes, depending on which
// flags were set to True.
// ****************************************************************************
//
// ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
//
// ****************************************************************************
// FindSupplyPathU(U, False) updates an individual unit's supply.
// FindSupplyPathForStack updates supply for all units in a hex which are OOS.
// ValidateHex determines if a hex is valid/invalid for a major power to use in
// a supply path.
// ValidateSeaArea checks if a sea area has changed between valid/invalid for a
// major power to use in a supply path.
//
// SupplyUpToDateAxis & SupplyUpToDateAllied is set to False when:
// 1 - In the Weather phase, if the weather changes in any weather zone.
// 2 - Units enter or leave a hex.
// 3 - At the end of phases where large blocks of territory change control:
// Declaration of war [TMajorCountry.DeclareWar].
// Claim of minor country territory [TCountryTable.Conquer],
// OccupyBalticStatesEffects, OccupyEasternPolandEffects,
// CheckBorderRectification, [TMinorCountry.Peace]
// Alignment of a minor country [TMajorCountry.AlignCountry].
// US Entry - control of territory may change:
// OccupyGreenlandIcelandEffects, OccupyNorthernIrelandEffects.
// Conquest [TCountryTable.Conquer].
// Surrender [TCountryTable.Conquer].
// Liberation [TMajorCountry.Liberate].
// Declaration of Vichy France [CreateVichyFr].
// Collapse of Vichy France [TCountryTable.CollapseVichyFrance].
// Ukraine.
// Mutual peace.
// 4 - Computing odds ratio for Notional units.
// ****************************************************************************
//
// ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
//
// ****************************************************************************
// When EvalOSSAxisLand or EvalOSSAlliedLand is True, execute
// FindRailwaySupplyPath & FindBasicSupplyPath3rd2nd to check if supply sources
// previously OOS are now in supply. Then execute FindSupplyPathU to check if
// units previously OOS are now in supply.
//
// When EvalInSupplyAxisLand or EvalInSupplyAlliedLand is True, execute
// TrySavedPath2nd1st and TrySavedPath3rd2nd to check if a supply source
// previously in supply can still use its old path, and execute TrySavedPathUnit
// to check if a unit previously in supply can still use its old path. If
// either fails execute FindRailwaySupplyPath & FindBasicSupplyPath3rd2nd to
// check if the supply sources can find new paths, and execute FindSupplyPathU
// to check if units can find new paths.
//
// When EvalOSSAxisSea or EvalOSSAlliedSea is True, execute ????????? to see if
// supply sources and/or units that were previously in supply are now OOS.
//
// When EvalInSupplyAxisSea or EvalInSupplyAlliedSea is True, execute ?????????
// to see if supply sources and/or units that were previously OOS are now in
// supply.





EDIT: Note that changing control of a single land hex could affect supply paths for units needing to go overseas to find supply. For instance, cutting off a path to a port could put an HQ out of supply and that could have a ripple effect on whole swaths of other secondary/tertiary supply sources and/or units.

[paulderynck]

Yes, units can overrun air and naval units, but they don't have to be in supply to do so and the move does not cost extra movement points.