Too much surrendering and ammo loss?

[ZBrisk]

Now about the ammo thing I mentioned...

This is a pretty clear-cut example. On "nobody comes back" I ordered a German inf batallion to assault an American rifle platoon in the woods, with two of the companies attacking from both flanks (something the batallion AI should think of doing, btw). This is the result:



Those three companies have spent literally all of their ammo on that one platoon. Even a sturm company right on top of them doesn't make them budge. My units haven't received a single casualty, and intel shows the other side still has ~44 men.

In reality, I'd expect something like:

• Contact made at ~100m. Most German casualties happen here.
• Just a portion of the German batallion's firepower is enough to quickly pin down the American platoon.
• Engagement lasts just a few minutes before Americans surrender. Half casualties, half prisoner.
• Anywhere from a few to a few dozen casualties for the Germans, depending on how well they handled contact.
• The Germans spent maybe 10% of their ammo.

This is a situation where surrendering would've really made sense!

[Arjuna]

Do you have a saved game re the resupply of the Hetzers taken before the actual resupply event?

Re Routing and Recovering. Prior to BFTB we used to rout units a long way, and we also routed them again if while recovering enemy threats appeared close by. Trouble with this is that you could end up with a unit bouncing around continuously and never recovering. I've taken another l;ook at the code and noticed one obvious bit that applied a surrender threshold based on the unit's current morale, stubbornness and supply level. Alas this only applies to routing units. Recovering units therefore get an automatic 100% threshold. I've addressed this now. Recovering units use the same code and have the threshold halved, thus making them twice as unlikely to surrender as routing units. BTW the code does test to see that the time last engaged was within 10 mintes for routers and 2 minutes for recovering units. Hopefully this will improve matters. We'll test this with the next build.

[Arjuna]

Re ammo expenditure. Your're presumption about ammo expenditure is too low IMO. Most companies carried around 100 rds per rifle, from between 500 to 1000 rds per MG. In a typical assault, lasting fifteen minutes most units would burn through half if not more of their on line ammo. EG a MG42 will burn through 30 rds per minute in an assault. 60 rds once the unit's perimeters overlap ( ie they are near hand to hand ). Let's say an average of 40 rds. Let's assume the MGs carried 800 rds each. Therefore 800 / 40 = 20 minutes worth of fire. Not much really. Sure not every one will be firing at that rate but still the unit will burn through around 50% of their estab allowance. Now bear in mind that for the Germans they often didn't start with a full estabs worth. So I'm not surprised to see them exhaust thier supplies so quickly.

What I am concerned about though, is probably the low casualties inflicted on the defenders in this case. IIRC the US troops start entrenched along the front line. This is probably having too significant an effect when combined with the forest, poor visibility etc. Was this taken from close to the start of the scenario. If not, then can you send me asaved game prior to the assault line getting close to the defender. thanks.

[Arjuna]

Re why didn't that US inf pl surrender. It probably boils down to the lack of casualties inflicted on it. Which is why I want to look into this. I know from our test scenarios that when units are in the open, deployed, or dug in the casualties inflicted from small arms appears right. So it's probably a case of the terrain and fortification modiiers.

[ZBrisk]

Re hetzers resupply:
I have a save shortly after resupply is on the way. Will that work or does it need to be at the time of request?


Re routing:
Yes, units in CotA ping-ponged too much, but I don't think the ability to rout multiple times should've been removed entirely. Maybe a better solution is to allow it depending on the unit's suppression, nearby threats, and available nearby cover. For example, this company may surrender since they're out in the open and being fired on by a bunch of 75s. But this coy should've just run into the woods a little.


Re ammo expenditure:
Agreed 100% on expenditure rates. Note that I expected the engagement to last a few minutes. That's why I said 10%. Instead, it went on for over an hour and that screenshot shows the result. Maybe my presumption on engagement time is wrong, but an assault in the woods with 1:6 personnel and 1:16 APerFP coming from three sides shouldn't drag on for an hour. Maybe 15 minutes at most.

The whole point here is that after so many bullets, that platoon (which was only 'deployed') should've been annihilated. Even I haven't taken a single casualty, and I'm the one assaulting! Same thing with the panzerfaust/schreck thing earlier, and the Hetzers. After all those shells and rockets were fired, IMO at least 10% should've hit. Something about direct fire seems really off.

Good news is, indirect fire works nicely. I played through the assault a few times. One time the Americans actually routed and surrendered...after a mortar strike.


I will make a point on ammo expenditure though. IMO, lower rates of fire shouldn't only lower the expenditure rate, it should make shots more efficient as well. Does it work this way already? The manual says that low-ammo units will ration, but that only suggests high-level decisions of engagement. If visibility in that forest was so bad, then surely no soldier would fire every last bullet without even seeing the enemy...

[Lieste]

It seems even small amounts of fatigue severely impact the casualty rates (persons per round fired).

I fully agree that effectiveness should plummet when tired, but I'd tend to the suggestion that casualty rate (persons per hour) should be strongly reduced (as currently), but the effect on rates of fire should be the majority, so the (persons per round) is less strongly influenced.

More of a rationing of effort. As when the unit is rationing ammunition due to shortages.
Also perhaps appropriate for specialist AT weapons in restricted terrain (or any other weapon where area fires are not generally used - the weapon will usually be fired when a target is more-or-less clearly in view, so opportunity and limited chances are the limitation rather than abstract accuracy reductions /ammunition quantities).

It could be that the AT gunner never sees a clear shot while unsuppressed enough to fire, and fails to stop a tank's movement - or if he is in a quieter corner, and here cover and concealment help, he might get a textbook flanking shot at perfect range, and only need a single rocket to have effect.

[gabeeg]

I have had two odd things happen in regards to panzers in my current game. One, I had a Panther Company retreat in the face of a company of stuarts....see the screen shot. Now they might have gotten spooked because they knew more American units were behind it...I don't know but with in minutes of the stuarts being identified as stuarts and shots being fired the Panthers in town retreated...seems odd. The other issue was with another company of Panthers that entered an enemy held town backed up with two companies of Pz Gren. The came up against two units of american infantry (not sure of the E/S...so maybe they had AT weapons other than bazookas) and a mortar group....it surrendered. One of the infantry companies was on its left flank but the mortar and other infantry company were in front. Seems that 10 panthers supported by two pz gren. companies would have fought a bit. Again, I do not have all the details or a save game but on the surface it seems odd.

[Arjuna]

Harry,

Thanks for the feedback. Without a saved game taken before the event it's nigh impossible to determine for sure why these occured.

For all,

Please try and get into the habit of saving regularly. That way we'll be able to follow up on these reports. Many thanks. [:)]

[Lieste]

I just looked at the file sizes for a saved game - they are moderate, but not huge... less than 1mb each for a modest scenario.

What would greatly aid this is an option to save not just a single autosave file every twenty minutes (Real time), but also to opt to save a file (SCN_NAME-D1-0000, SCN_NAME-D1-0030 etc. - ideally time user specified, and selectable on/off during play.) This would give us an easy way of 'having' a save on hand, and also making better AAR presentations easy - often I want to make a save *After* something interesting has just happened (good and bad). Nothing really 'new' here, just automating something to make life a bit easier.
Ideally this could be made into a user* or automatically assigned folder eg SCN_NAME-Launch_date for each new game within the save folder... and while folders occur to me, I'd also love to be able to set subfolders to organise the original BFTB offical files and my local modifications and projects for Scenarios and Estabs - it can get quite hard to find specific versions of files, or 'branches' of work with the flat-only folder. I did try sub-folders for scenarios and they didn't get picked up.
With related files in a single folder I can easily manage each scenario-run individually (delete the whole folder, cull some 'dull' saves, archive the lot to disc) - a really big list of similarly named but unrelated files in one folder is a PITA...

It might be useful to also optionally save a larger file, with the messages and related 'kill tags' for the map display at the 'session-end' save when leaving an in-progress scenario so it can be fully resumed... and to allow an AAR-flagged save to be reloaded even if all on-map forces were eliminated.

*The user specified folder would allow different paths to be explored from a single saved game - the new branch would require a different naming convention if it wasn't to overwrite the original game.

[gabeeg]

I second that request for autosave option that saves in sequential files...that is a very nice idea.

[Lieste]

A minor amendment to the suggestion:
Use:
SAVEFOLDER_Branchstartdate/SCNSAVENAME-D01-0030, rather than the initially suggested D1-0030 format - this will guarantee saves are ordered by scn time/date when listed by name - there are many more annoying things in the world than finding 10 between 1 and 2, but it is easy to avoid...