SITREP

[wodin]

yeah he does release a beta patch..but anyone who has followed Panther for awhile has come to realise Dave is a perfectionist..and he wont release a patch even a beta unless he has all known bugs squashed..

[simovitch]

So things are running a bit smoother now with this new build. If you really want to throw the Red Devils into Arnhem you can with a bit of luck and finesse. But I had to show you this shot on the morning of the second day.

Note the 9th SS Pz recon making "the crossing" into Arnhem... they already lost a motorized flak platoon to Frost's defensive fire.[8D]

[SapperAstro_MatrixForum]

In other words, you managed to get Frosty into the city centre without too much hassle...unlike before?

[simovitch]

ORIGINAL: SapperAstro

In other words, you managed to get Frosty into the city centre without too much hassle...unlike before?

Yes, it is a bit easier to get the whole battalion and probably more into the City. Whether it's a good idea or not? well...

[Gizuria]

Where can I get a copy of this Beta patch? I have registered the game but I don't see it listed on the members boards.

[Lieste]

When it's tested [8|]. The paint's still wet. [:D]

[Gizuria]

Oh I see. Thanks for the reply

[Phoenix100]

How enticing, Simovoitch. Is it a good thing? Well, Frost did it historically, so surely it is? And since the last patch it really has been impossible for me to get them near the road bridge by day 1. I prefer From the Meuse to the Rhine to try, not Red Devils, though. This (below) is about the best I've done so far - approaching the road bridge from both sides (though the northern attack with 10 Para is going nowhere but back to a POW camp I fear) at tea-time day 3. Down south I have taken the Nijmegan road bridge, but not the rail bridge, and despite best efforts xxx Corps have only just crossed Grave bridge after about 10 hours on the map. Not looking so good, I would have thought. Progress throughout has been bedevilled by 'halting' issues which I have tried to get round by issuing new orders, so I will be very grateful for the patch.

[SapperAstro_MatrixForum]

I assume it was attempted in Meuse to the Rhine as well?

[Phoenix100]

Maybe it was. I had assumed Simovitch was playing RDOA. I know that the AI behaviour is quite different between the scenarios - at least, it seems like that to me, and I've asked questions the answers rto which confirm it might be - in that in FTMTTR the Axis tries to get units down through Arnhem to Nijmegan - as it was historically, Nijmegan was the priority at first - and that, I assume might make it harder to win in RDOA. Not sure. I always felt there were more Axis units there in RDOA. What is astonishing in Simovitch's screenie is the dearth of Axis troops. I've never seen the bridgehead like that - whenever I play there are black and grey counters swarming all over.

[simovitch]

The screenshot above(from RDOA)was made at the break of dawn before effective intel. As the day broke it became clear that the Germans were there in force. FTMTTR should play out just like RDOA during the first few hours.

Here's what is left of Frost's group on the night of D3:

[Phoenix100]

Ah.

[wdkruger]

Any news on when a public beta might be forthcoming?

[Arjuna]

wdkruger,

As soon as I get to the bottom of the halting issue.

[Arjuna]

SITREP 1700hrs Friday 9 Nov 2012 ( Canberra time ).

Hi all. It's been a very busy week. Monday was spent at a Defence conference but the rest of the week I have been cutting code for the patch. My focus has been to try and get to the bottom of the halting issue. After putting out a new beta build last weekend Richard observed that he was finding it hard to disengage units - ie if they had Move order to head north but had enemy to the south, then his units would Halt rather than retreat or withdraw so they could continue moving away from the enemy. I also noticed that some complex attacks were being continually slipped and the sub atack groups never moving.

So I decided to tackle the latter one as it was having the biggest impact. It's taken me all week but finally I think I have cracked this one. What was happening was that when the complex attack was developed it had the superior HQ and its arty in reserve with four different sub attack tasks. It wasn't a coordinated attack, so the sub attacks were able to select their own start times dependent on their individual orders delay. The reserve and four subAttacks tasks were all linked as concurrent tasks. When the first sub attack task began it requested aditional time to complete its Move to its FUP. This was granted by the superiorHQ and the complex attack plan slipped. Alas, because the other subAttacks had not started yet it was slipping their start by the amount requested by the first subAttack. This meant in some cases delays of four to 8 hours. It was then repeated each time the next subAttack was started. So in this case the whole attack was eventually slipped by a day and everyone sat around twiddling their thumbs.

I fixed this by ensuring that the start of concurrent tasks cannot be slipped if the sourceTask ( ie the task belonging to the original requester ) has already started. This worked a treat till an assert fired to say that the advance to the reserve task end was greater than the reserve task start. These two tasks are linked sequentially. So the start of the reserve should immidiately follow the end of the advance. So I had to ad code to prevent the slipping of any sequentially linked tasks affected by the earlier mod that prevented their start from being adjusted. I have gone through an initial test and it looks pretty good now. This should mean that big scale attacks will work effectively.

While I have also fixed a number of other bugs reported by the autotesters ( see list below ) I have run out of time to address the disengagement issue reported by Richard. I will look into this next. I have a pretty good idea of how to address this. Basically I will test for the direction of the unit and the enemy threats. If it's deemed to be moving away from them, then I will reduce the probability of it halting and either increase the prob of it retreating or ignoring the threat altogether. I need to step through the code first though.

Once I have this fixed that should be it. from me.

Paul has written some conversion code for the maps to fix an anomoly that occured on some older maps that were opriginally made with an earlier version of the MapMaker. This was affecting the base altitude layer and could have the effect of creating bad spot heights in certain places. We will have to run a conversion on all maps though.

Here is the list of fixes for this week::

• Ensure that attack are called off due to lack of time if the shortfall exceeds the assaultDuration. ( PA 10835 )
• Fix Assert in DetermineSlippageResponse() to account for cases where the FUP has been terminated and its times all set to its start. ( MSP 5511 )
• Ensure attackSubHQs determined after independents in End of Scenario attack ( PA 2343 )
• Ensure that all stored peripheral task force groups are factored into the unitCount inside VerifyPlanForceGroups() regardless of their status ( SMP 4097 )
• Modify Assert inside AssessForSubAttacksWhoseReorgsCanBeBroughtForward() to cater for cases where an attack is scheduled to start next minute while it's status is set to current. ( TA 1789 )
• Ensure that OnCallSpt forces subtracted from Independents before developing end of scenario attacks. This avoids the possibility of allocating the same unit to more than one current task - ie reserve and assault. ( SRF 16165 )
• Ensure that the start of concurrent tasks are not slipped if the sourceTask they are linked to is already current. This prevents continual slipping of complex tasks, where their starts are not coordinated. ( SMP 4228 )
• Prevent the allocation of a forceGroup subject to a task if it is not suitable. ( SFTTAR 4309 )
• Added new member to SlippageTask and modified slippage code to ignore End if nextTask is ignoring its start time. This ensures that linked tasks are slipped and cribbed correctly. ( SMP 4311 )
• Ensure that existing peripheral forceGroups are deducted from the CoreFG at the start of DevelopMissionPlan() ( SMP 4098 )

[Phoenix100]

Wow. It looks like very difficult work, Dave. Much appreciated. Well done if you think you've bottomed the halting issue? I wasn't sure - was that what you said above - that you had, finally, fixed the halting issue, bar those iterations of it raised by Richard? Thanks for the update, anyway. Hope to see that patch soon, then.

[wdkruger]

Thanks for the update.

Warren

[Arjuna]

Hi all,

I have just kicked off the upload of a new build (4.4.254) for our beta bunnies to test. I have made extensive mods to the combat system in an effort to achieve better historical casualty rates and improve the way units react including halting, retreating and routing. I think I have it about right but will need feedback from the beta testers to confirm that. If this is forthcoming I'll initiate a new patch. Here are the changes for the latest build.

Fixes for Build 4.4.254 include:

• Ensure that attack are called off due to lack of time if the shortfall exceeds the assaultDuration. ( PA 10835 )
• Fix Assert in DetermineSlippageResponse() to account for cases where the FUP has been terminated and its times all set to its start. ( MSP 5511 )
• Ensure attackSubHQs determined after independents in End of Scenario attack ( PA 2343 )
• Ensure that all stored peripheral task force groups are factored into the unitCount inside VerifyPlanForceGroups() regardless of their status ( SMP 4097 )
• Modify Assert inside AssessForSubAttacksWhoseReorgsCanBeBroughtForward() to cater for cases where an attack is scheduled to start next minute while it's status is set to current. ( TA 1789 )
• Ensure that OnCallSpt forces subtracted from Independents before developing end of scenario attacks. This avoids the possibility of allocating the same unit to more than one current task - ie reserve and assault. ( SRF 16165 )
• Ensure that the start of concurrent tasks are not slipped if the sourceTask they are linked to is already current. This prevents continual slipping of complex tasks, where their starts are not coordinated. ( SMP 4228 )
• Prevent the allocation of a forceGroup subject to a task if it is not suitable. ( SFTTAR 4309 )
• Added new member to SlippageTask and modified slippage code to ignore End if nextTask is ignoring its start time. This ensures that linked tasks are slipped and cribbed correctly. ( SMP 4311 )
• Ensure that existing peripheral forceGroups are deducted from the CoreFG at the start of DevelopMissionPlan() ( SMP 4098 )
• Modified code inside TaskMove::ReassessOptions() to only Halt when under serious threat and not just because the unit is not making progress.
• Reduced probability of halting where unit is trying to move away from closest threat and the unit is not co-located with the closest threat.
• Where unit co-located with closest threat but is trying to move away, it will now retreat rather than halt.
• Remove LOS check inside CanFire() where a unit is passed in as unit will be from know visible threats. In other words stop double checking LOS. This ensures that a unit can have a chance to fire at a visible threat and reduced processing - excellent! In testing it increased the number of fire events by 70%.
• Increased range of routs from between 600 and 1200m to 1800 and 2700m
• Added code to give priority to covered terrain when retreating/routing.
• Extensive modification of Fire code both for APer and AArm fire to get more historical casualty results.
• Decreased the probability and quantum of surrenders that occur when a units routs.

[wodin]

I can start to imagine if you've made the game less deadly then I expect many scenarios will be difficult to complete the Obj's on time.

[Arjuna]

Certainly the trick has been to get casualties down while still maintaining momentum. That's why I have put so much effort to reduce the amount of halting and increase the rout distances. I have been using the BFTB tutorial as my testbed and while there is a range of outcomes over multiple run throughs in general the US 4th Armoured Division can barrel its way into St Vith after two days. So that's not bad progress against two reasonable infantry regiments.

In point of fact there is more firing now and hence more suppression. In many cases the effectioveness of fire has been increased while certain modifiers have been adjusted. With more suppression you often find an outnumbered defender effectively neutralised allowing the attackers to close and force it to retreat or rout.