KG Holtmeyer stalled on highway

[PeterD]

I've been seeing problems with stalled movement, which can only be corrected by reissuing orders (and paying the price with order delay of course). The common factors appear to be a formation with subordinate HQs, which deploys to deal with an enemy unit, then fails to "undeploy" (take my hunches with a grain of salt obviously), and never continues moving (maybe eventually after a good night's sleep).

In any case, I've captured a savegame that I think shows the problem (attached):

"Race for Bastogne", D2 1400.
KG Holtmeyer has orders to advance to Bastogne down the main highway (after spending the night on the Clervaux bridge objective). Just after noon the KG encountered a single enemy unit just south of Mageret (5km east of Bastogne). The enemy unit retreated to the SE, then surrendered, just prior to this savegame. So far, so good, but the problem comes now as you run the clock forward: the KG doesn't resume moving (actually, a few units do proceed to Bastogne, where they encounter some moderate resistance, but at least KG Holtmeyer HQ, the rear guard and several line filler units do not move).

If you load and run, you'll see the main body of the KG stays in Mageret. Their status says Moving/Halted and Deployed for at least 8 hours, but they go nowhere. There are no apparent fatigue issues (and they are set to minimum rest). By 10pm or so they are Dug In(!), and by midnight they are resting in the same spots.

Admittedly, a couple of units of the advance guard are in retreat recovery at 1400 and it takes them an hour or so to recover. Perhaps that accounts for the initial delay. It's possible there are other enemy units in the area, but if so, no intel ever appears, and there's no shooting - so why would the KG halt because of an enemy it can't see and that's not shooting?

Hopefully the savegame will be of help in understanding/fixing this strange behaviour.

[simovitch]

We're looking at this - the patch debug is firing off some scheduling asserts when I change settings on Holtz's move order so I'll bring it to Dave's attention.

May I ask what time were the Our River bridges completed for this one? You are way further than I ever got for December 17th afternoon.[X(]

[PeterD]

Yeah, I made good progress, hitting most objectives about as early as you could expect. This was my first attempt, and managed a decisive victory in the end, even without properly securing Bastogne (I mean, I was expecting allied reinforcements, but... wow) or exiting any significant forces. By the way, the settings were Historical Weather (i.e. 0 airstrikes) and Realistic Orders Delay (I consider Realistic delay a bit soft, but it helps to balance out some of the *ahem* insubordinate behaviour of units pre-patch). I left all arty target selection to the AI.

The bridges completed at 1325 (Dasburg) and 1338 respectively (I was paying close attention [;)]. I didn't do anything particularly fancy in that regard I don't think. At each bridge, I gave a single order (at 0530) for 2 engineer units to construct the bridge: fastest, quickest, min aggro, ambush, no rest. The order icon was placed exactly on top of the objective icon. I haven't tried it with any variations on those orders yet.

In the meantime, all KGs were reorged and rested, and Kunkel was marched south to the crossing point in readiness. I've attached a saved game from D1 1415 where the bridges are in place and the KGs have been given their initial exploit orders (is there any way to avoid orders delay for the bridge crossing?). I staggered the orders to try and avoid the formations getting in each other's way on the bridges and roads.

For the initial assault, the battalions of the 77th moved to the 2 Clerf river objectives at Fastest/Quickest, min aggro, ambush, bypass, no rest, the main goal being to get in contact with any defenders on the objectives before daylight if possible. Then they switched to Med aggro/Max ROF and once the armor arrived (around 1500-1600), the resistance collapsed (hoped to dig them out before nightfall). Not much sleep for the KGs the first night, except HOLT, who rests up in Clervaux in preparation for the drive to Bastogne. In particular, Cochenhausen establishes a blocking position at Antoniushaff junction...

Anyway, thanks for reading my mini-AAR [>:], and thanks for the scenario, which I really enjoyed as a study in how to get their firstest with the mostest!

[PeterD]

I just ran another bridge-building exercise... if I bring e.g. the 3.38 pioneers back to help with the Dasburg bridge, it completes at 11:25!

[simovitch]

I tried that same thing last night. using the 2/38 assault Engineers is a bit gamey and I think I'm going to remove the engineer values on those estabs. I also modified the variable PersQty for these bridge building engineers in this scenario so that an average result will be around 16:00-16:30 for completion. So the timing for completion could be more, could be less, depending on chance.

[PeterD]

I think these are good changes. Of course, it does mean I'll have to play the scenario over again...

Any updates on the original problem?

[Arjuna]

PeterD,

CHeck out this screen dump. It shows KG Holtmeyer's force at 1410. Note that the II.3 Pz Bn is the KG's advance guard. It in turn has an advance guard led by 6 Coy and a main guard led by 5 Coy. Note that 6 Coy is moving ahead while 5 Coy and it's subordinate 8 Coy are not. The reason they are not mnoving is that they are retreat recovering - presumably becuase of their prior action to clear the enemy. So this is not a bug but the way it is supposed to work. You could argue that 6 Coy should have waited before heading off and why doesn't it stop tyo wait for the rest to catch up. With the new formation movmeent code we opted to provide the advance guard with a fairly big latitude before pulling it up. This explains why they get so far ahead and the recovering main guard explains why the rest of the force is stalled.

[Arjuna]

6 Coy did stop and wait. 5 Coy did recover around 1520. By 1530 KG Holtmeyer was back on the move. This is as designed and how it should be IMO. When you see a force stopped, change the unit info display to show rout status and check to see if any units are retreating, routing or recovering. Then you can force a replan if you don't want to wait. But remember a replan may in fact cause you to wait even longer. [:)]

[PeterD]

Firstly, Dave, I appreciate you taking the time to look at my problem.

I feel I need to explain that I have played many many hours of COTA, and never had any problems with move orders like I have seen in several games of BftB so far (I have played thru 4 complete scenarios). I understand orders delay, retreat recovery, routing, replans, fatigue, cohesion, etc. all too well, but respectfully, I do not think they can (fully) account for the behaviour I am seeing.

I am still open to a "works as designed" explanation, but first I want to be sure you have a clear understanding of the problem as I see it. If you could reread my OP in this thread, you'll see that I allowed for retreat recovery to explain the first hour of "stall" here. Your analysis ends around 1530 when things appear to get moving again, but this appearance is deceptive. Please indulge me and run the original savegame out for 8 hours. If possible, do this 5-10 times, since the time evolution is a little different each time.

I cannot be sure what you will see, but I attach a screenshot of a typical result when I do this. Note the screenshot is at 2200. Some comments:
1. Virtually the entire KG hasn't moved for at least 4 hours, despite the absence of enemy contact.
2. The Advance Guard has stopped (waiting for the rest to catch up?).
3. The Main Guard leader (2.38) has stopped (waiting for it's sub-elements, or just doesn't want to overtake Advance?).
4. The rest of the Main Guard is back with the KG HQ (why haven't they moved up with 2.38?)
5. The Rear Guard has stopped (waiting for KG Holtmeyer HQ to proceed first?).
6. KG Holtmeyer HQ is Dug In (!) from being stopped so long. Is it waiting for the Main Guard to proceed?

Is everyone waiting for everyone else in a deadlock? If there is something wrong, IMO it's most likely to do with the Main Guard. Perhaps they are following their organic leader (KG Holtmeyer HQ) instead of their Op Plan superior (2.38)?

It would be helpful if others could load the original savegame and simply run it to 2200 without issuing any orders. If possible, do it a few times, and post your observations. The first order of business is to establish that there's something awry (or that I'm hallucinating).

[PeterD]

I attach the savegame from which the screenshot in my last post was taken. It is the result of running the original savegame forward 8 hours, without giving or changing any orders at all (your results may vary).

[Arjuna]

OK will do.

[Arjuna]

Peter,

I can confirm that you were right in that something was wrong here. The beta testers have earn't their pay this week. They were able to get me a saved game where I could get to the bottom of the problem. What was happening is a lockup in the formation movement code where we have a large advance and main guard groups and not much tail behind the hub. The advanceGuard reckons it can't move any further forward and the mainGuard thinks it can't move any closer to the unitAhead. I have freed things up in terms of the distance allowed ahead by the advanceGuard and this has done the trick. I have tested your saved game and KG Holtmeyer now moves fine.

As I said to the beta testers we will need to monitor this to ensure we don't have advanceGuards getting too far forward. I will have to do another build for this. Once again thanks for your reports.

[PeterD]

It sounds like there has been some progress here, but I must reserve judgement until I have had a chance to play with it. Honestly, I foresee a few rounds of adjustment/improvement in the cards here.

For one thing, I am having trouble reconciling your description of the problem with the situation shown in post #9 above. In that picture, the main guard is actually split up; the problem seems to be with the main guard subordinates. May I ask if you considered my suggestion:

Perhaps they are following their organic leader (KG Holtmeyer HQ) instead of their Op Plan superior (2.38)?

Or is that explicable in terms of a "charging HQ"?

Out of curiosity, when you talk about distances b/w the different elements (advanceGuard, mainGuard), are they measured b/w the respective leaders, or via some kind of formula involving all the units? It sort of sounds like, in my example, mainGuard (2.38) has caught up to advanceGuard, but advanceGuard thinks it's way ahead of mainGuard (subs).

Perhaps I will go back to my original idea of waiting until I've had a chance to play with it! Could you please clarify if this will be in the next beta build available via members download, or has to wait for the following one?

[PeterD]

I've had a chance now to test this out with 4.1.235 (the official update), and unfortunately, it does not appear to be fixed.

I tried to run the original savegame out for 8 hours as before. I tried it 5 times, and Holtmeyer HQ (and rear guard and most of the main guard) did not get moving again in any of those attempts.

I'm attaching a new savegame of one of these runs.

[simovitch]

Peter D: I don't think it's wise for us to debug a saved game that was initialted by the pre-patch release. Dave doesn't have time to chase down a possible false negative.

Unfortunately you may need to restart, or give individual orders to some of Holt's subordinates to shake them loose.

[Arjuna]

As Richard indicated you need to start a new game to test it properly. I did run through your saved game and because of the pre-existing data, you often do get the lockup but after a reassessment it corrects itself. However, there is a chance it may not reassess and regenerate its route and formation, in which case it will stay locked up.

[PeterD]

OK, I thought that might be the case. I'll comment further once I've played thru a new scenario or two.