Dave...about the coming patch...

[GBS]

When do you feel you will be at a point that you can share with your loyal customers[;)] some of the features and or fixes that the coming patch will have? I just want to get excited again. Thanks even if you can't.

[Arjuna]

Sure, I have listed below the fixes we have done for the last two builds. Unfortunately our task tracker database is no longer working and so I can't retrieve the previous build fixes. These were primarily focused on fixing various anomolies with formation movement. The overall focus is on fixing anomolies with the base mechanics - ie fire, movement, construction. We have completely reviewed all of these functions. The combat system has been scrutinised and verified against historical analysis. I am still tweaking this at the moment. I also have to address three issues with supply - first, to review the way bases are allocated to SEPs; second to review the way supply lines are interdicted by exempting from enemy firepower influence those locations where there are friendly units; and thirdly, to ensure that small arms ammo ditribution gets a bigger slice of the pie ( ie prevent all the ammo from being consumed by those greedy artillery units ).

Builds 236 and 237 fixes

• Formation Movement fixes.
• Modified In Situ formation values.

Build 4.2.238 Fixes

• Bridge demolition now works as intended. Removed requirement that unit must be an engineer to blow.
• Fixed Infinite Loop causes by not culling waypoints prperly inside DevelopMissionPlan(). ( NOTE - need to ensure waypoints culled properly as force moves. See AdvanceAlongRoute(). Waiting on suitable saved game. )
• Ensured that Player Waypoints are not being ignored by subordinates.
• Ensured that Player waypoints are being removed as force passes.
• Ensured PlanMove now calls proper formation pathing routines when catering for crossings.
• Ensure task waypoints set correctly for all subordinate Move tasks.
• Ensure CullRouteLoopbacks() factors in waypoints.
• Ensured that suboprdinate units now processed for exit eligibility.
• Fixed assert at ScenRoute.cpp, line 3622. Was erroneously choosing a foot path instead of a mot path because the FG Values hadn't been recalced since reallocation of units. Now forces a recalc of FGValues before calcing route.
• Fixed assert at ScenMissionPlan.cpp, line 3887 caused by not adjusting end times of missionTask and planTasks if these were of a different type to bossTask. It now caps the end and StartAT times of missionTasks and planTasks if these are greater than the bossTask. It also ensures that orders are sent to subordinates with changes.
• Fixed Assert at ScenMissionPlan.cpp, line 3920 caused by not checking for valid route before determining route duration. Now checks and if invalid due to boss routing it sets the end time for task to missionEnd. When the bos finishes rout recovery he will recalc route and send orders.
• Fixed Assert at TaskDoctrine.cpp, line 3550 caused at Game start when a subordinate tries to reschedule its boss's reassessment and it's boss doesn't yet have a curr unit task. Now checks and ignores if no curr unit task. This just depended on the sequence of seeding the on map forces at game start.

Replacement exe #1 fixes.

• Ensure that new formation movement mods work with non-road column formations.

Replacement exe #2 fixes

• Modified ObjectiveAchieved() test for TaskDefend. Now returns true if formation type is inSitu and unit within task radius. This prevents a lot of atStart units moving a few metres.

Replacement exe #3 fixes

• Modified move code to ensure bases stop moving if enemy ahead within 500m.
• Supply Routes and supply status now updated for all units at each ResupplyDetermination event even if they don't require more supplies

Replacement exe #5 fixes

• Ensured that CanMoveAhead() caters for route loopbacks. This fixes one source of formation lockups.
• Ensured Orders Delay occurs for all task changes greater than thresholds - ie for formation, route and waypoint changes and all replans.
• Removed double dipping on orders delay modifiers for human player orders.

Replacement exe #6 fixes

• Fix divide by zero error in ScenRoute::GetUnitAhead() caused when prev and next locs are the same and tries to get direction.
• Reduce maximum grids for initial phase line from 10 to 5 in an attempt to limit scope for HQs moving too far ahead on recalcing route.

Replacement exe #7 fixes

• Ensure uniform labelling for Task view thresholds. All fields now use three level naming convention.
• Fix Assert at ScenTask.cpp, Line 4056 HasAchievedObjective(). Ensure that if no MissionTask it returns false.
• Fix Divide by Zero error caused by adding TaskLoc to end of formation route when the last loc was already the same as the taskLoc.
• Ensure subordinates only delete waypoiints from their bossTask if they are the subject of the bossTask. Otherwise let the subject itself manage the waypoints. This fixes a problem where ordered waypoints are not removed when the force goes through them.

Replacement exe #8 fixes

• Changed the option labels for Aggro, ROF, Losses, Ammo, Fuel, Basics to all use Min-Norm-Max.
• Ensured that formation constraints with the boss were ignored by the subordinate during their move to join the boss's route and after they had left it. Similarly ensured that the boss ignored the subordinates after they had left their route but factored them before they joined. This was a major cause for lockups, especially with larger formations.

Fixes for Build 4.2.139

• Fixed assert at PlanAttack2342. Ensure that complex attacks are not undertaken where a force comprises of only one line unit and/or only one subordinate HQ.
• Fixed assert at PlanDelay.cpp, line 159. Ensure PlanDelay::DevelopTaskPlanSelf() tests that the force has more than one non-refueling line unit before trying to split it into multiple groups.
• Fixed assert at ScenPlanScheduling.cpp, line 17731. The Assert now includes soak off attacks.
• Stopped reporting that a unit had fired when in fact it had pulled out of the fire event without firing a round.
• Stopped reporting that a unit had been fired at if the firer had pulled out of the fire event without firing a round.
• Mods to APerFire and AArmFire including:
  • Reduce prob of firing if the hit probability gets below a threshold ( 20% for RPGs and 10% for all other weapons ).
  • Reduce impact of covered terrain mod if the engagement range is under 100m and even more if under 50m.
  • Reduced adverse impact of weapon accuracy for RPGs.
  • Ensure FirerLoc and targetLoc are used for determining grenade range. This should now make the grenade bonus work for APer fire when firer and target are within 25m.
  • Ensured targetsPerShot uses burstArea not burstRadius. This increases lethality of heavy cannon fire against personnel targets.
  • Adjusted impact of acquisition mod on APerFire.
  • Increased suppression effects.
  • Ensure that the range used for AArm fire against Mot and Mech Inf when dismounted is set between the mid and long range of the unit formation. Is set between min and long range if mounted. This increases survivability of half tracks in the assault.
  • Ensured BFTB casualty figures were within historical values. Baselined the first day of the tutorial scenario and reduced personnel casualty figures to a realistic 5-7% for the attacking force and between 21 and 28% for the defending force.
• Ensured unit formations use task setting for openSpacing.
• Ensured task setting for openSpacing only set to false for attack tasks and where defending in urban terrain.
• Adjusted Formation frontage and depth values in BFTB Estabs. Of particular note, increased depth of road columnfrom 3 to 4m per man. This had a significant effect on combat losses by reducing unit density of forces in road column. This one factor alone virtuall halved combat losses.
• Modified AAR screen to show losses rather than kills.
• Added extra data to AAR screen to show causes of pers losses.

For Replacement Exe #1

• Ensured HQs are not allocated to Assault tasks.
• Ensure no unit engagement indicator is animated on firer or target unit icons if no rounds fired during fire event.
• Ensure that mounted flak, AT, Mortar, RL and Gun typoe units are not disbanded until they are down to their last principal gun system.
• Modified CalcNonFormationMoveLoc() to slow down movement when actual enemy nearby and even further if friendly and enemy footprints overlap.
• Fixed error in isOverlap code that was preventing units slowing down when footprints overlap.
• Ensured that when units Halt() they do not get an opportunity to change facing.
• Ensured that dug in or better units do not change facing if they are at their objective.
• Added extra data to AAR screen to show causes of armour losses.

For Replacement Exe #2

• Ensure that the bossOffset route culls duplicate continguous locations - prevents divide by zero errors.
• Ensure that a unit can always move at least one metre when determining the distance a unit can move in a given move event.
• Ensure that when building an interim crossing large forces defend within the nearbyRange.

[oldspec4]

Wow....lots to like on this list.

I may have missed it but are the in situ values re: cohesion changes included also, e.g., to 60 from 30?

Thanks

[Arjuna]

Yeh they are.

[Nikolaj]

This is looking really good, even if I don't know what half of it means.

I haven't played for a while (I'm holding out for the patch), but I seem to recall that there were some issues with resting and fatigue. Have they been looked at yet, or is that for sometime in the future? Anyway, I'm really looking forward to this patch. I hope it will be released soon.

[GBS]

I like Nikolaj's? Dave have you been able to look into the rapid fatigue and slow recovery issue some brought up in the past?

[Arjuna]

Yes that was done some time ago. Sorry I forgot to add that to the list under the earlier build 236.

[Nikolaj]

That sounds great! I don't suppose there's an ETA yet?

[simovitch]

There is an improvement in fatigue, especially recovery. But I wager that it will still dissapoint a few armchair generals who relate fatigue only to physical tiredness.

Also, regarding HQ's and support units 'leading the charge'... this fix applies to assault tasks, so if you enjoy ordering your Regiment to move into battle with the 'move' or defend' order you may still find your unwary mortar platoon has taken the point.

[decaro]

ORIGINAL: oldspec4

Wow....lots to like on this list.

I may have missed it but ...

Did I miss the fix where racing German forces weren't exiting the map?

[Arjuna]

Joe D,

We've fixed that.

[Pawsy]

One feature I think that could be improve is the military engineering aspect. We should have the ability to blow bridges on order as a preliminary demolition? Primed is in fact bridge at state 1 for a reserved demolition. We should be able to order it to state 2 ready to blow giving the commander a better chance of successfully executing the demolition on orders or on his own initiative if the bridge is about to be taken. Military engineers on both sides used the same basic doctrine although by the late years I expect the standard of engineering in the Germany Army had somewhat declined. Having to wait for the enemy to turn up to prompt you to blow a demolition isn't recommended

[Phoenix100]

I absolutely agree. Why is it that you can't just prime and then blow a bridge? Why do we have to go through the 'deny crossing' order? I don't understand this. You should be able to blow the bridges without the enemy being anywhere near, on demand. This is what happened (and happens) in RL, surely?

[Perturabo]

When you are tasked with denying a bridge, the higher HQ probably hopes that blowing the bridge won't be necessary. Remember that bridges can be used by both sides.

[Phoenix100]

Yes. I realise - of course - that bridges can be used by me too!!! The thing is - I am the highest HQ, and I want the option, regardless of what some subordinate thinks.

[Perturabo]

ORIGINAL: phoenix

Yes. I realise - of course - that bridges can be used by me too!!! The thing is - I am the highest HQ, and I want the option, regardless of what some subordinate thinks.

You're not the highest HQ. It's not a strategic game.

[Arjuna]

We have opted for this approach because that mirrors what actually happened. The American engineers were ordered to prime the bridges and a guard was posted with instructions only to blow the bridge if the enemy was about to capture it. There were a few exceptions, but this in the main is what happened. No commander wants to foreclose options and that is what you do when you blow a bridge. If you like see it as a constraint on your actions imposed from above - something all comanders have to deal with.

[Phoenix100]

Ah-ha. Thanks Dave. It's certainly a constraint. It didn't happen like that everywhere in the war, of course. Sometimes bridges were blown before the enemy was anywhere near them, as part of a defensive strategy. For the germans as well, of course - perhaps even more imortantly for the Germans, though you have 'implemented' this in the game by making most of the Ardennes bridges already blown, I realise (like those at the beginning of Nobody Comes Back, which have to be laboriously rebulit before any German attack can really begin).

I suppose if the rule were ortherwise - you could argue - there might not be much of a game left in some scenarios, where the AI, focussing on immediate objectives (and not keeping bridges intact for long after this particular battle has passed by) might just blow all significant bridges immediately. In HTTR this would ruin a few interesting scenarios where the Germans didn't actually manage to blow bridges in RL, I guess. And it's part of the fun and game tension, for example, in a scenario like Piper's Race, to see (for both sides) whether all the Trois Pointes bridges are going to drop or not before the tanks get them. In RL the engineers dropped those bridges before Piper made it, but it's true that they failed to drop other bridges (the explanation given, however, usually, is that 'Grief' commandos had been at work - and this wouldn't apply to non-BFTB scenarios).


What does anyone else think of this rule, I wonder?

[Pawsy]

Oh yes I'm sure the Americans would give such orders the allies were on the advance and I can see how it would mess up some scenarios. I'm really enjoying the game I like the AI. Seems to take a different approach each time. Of course the British military engineering effort included a whole Division (79th) of engineer specific tanks for obstacle crossing not to mention bailey bridging.

[CaptCarnage]

This topic made me want to watch Bridge over the River Kwai.