c3k

I take too many screenshots. From "House Cleaning":
 
Assaulting the compound:

 
Firing squad:

 
Platoon HQ pokes their heads out to fire into the compound:

 
The Charge:

 
And here is my absolute favorite shot. Here is your action movie poster:

Just checking out the latest patch...
 

New and better enemy AI. Also with the patch improvements to soldiers staying in cover and not running away or toward you, your opponent is tough and fights very hard. Patience, recon by fire, objective prep with whatever fire support you have is key ( of course those are always key, right?) you have plenty of time for each mission. I recommend making use of that and not rushing in thinking you can sweep the enemy away. (Ask me how I know this😀)
 
Be careful and watch your losses. It affects follow on missions in the campaign and you need plenty of resources for the last couple missions. 
 
don’t want to give any spoilers except slow and steady wins the race. I know that’s not much 😀
 
Dave

Dude. How did you score that "CM Beta Tester" title? I know I've been behind in my dues. Is that it?

You seem to be suggesting that BFC games are some sort of 'open beta' games or something.  That's not the case.  Bug tracking is not chaos for BFC.  Actual software that is designed for bug tracking is used by the company in order to get the appropriate information to the appropriate individuals and the beta testers are charged with providing the appropriate information through the use of that bug tracking software.  While it is appreciated when players find things in the game that may need to be addressed the gaming public has no obligations of any kind in terms of bug tracking.  Customers play the games and enjoy them if they like playing them or stomp around angrily if they don't like the games.  Players can report things or not report things as they desire.  Customers will know that a bug has been addressed when a patch gets released and the patch log is published.  Bug tracking, reporting, and fixing is the obligation of BFC to the customers who buy the game.  There is no obligation by those who play the game to track, report, and fix bugs.  If something gets reported on a public forum more than once or even not at all then it really makes no difference because the public forums are not where the bug tracking is done.  Describing BFC bug tracking as chaos is wildly misinformed.  It may be different than what some are used to, but that doesn't mean that it's chaos.
Leave the bug tracking to BFC.  Perhaps if you get invited to the Beta team some day then you can participate in all the bug tracking and reporting that you would ever want, but for now just go and play the game and enjoy yourself.  

If BFC believed more transparency was needed - they'd do that. It's not you and this isn't the first time this topic has come up. There are two decades worth of posts here that attest to this.
All we can do is assume the CM Test Team (aka beta testers) is privy to more of the inner workings then we are. It took three years to undo the damage wrought by the 'evasion' fault and many save games, denials, resistance, etc. to get us to acceptance and ultimately a correction that brought back surrendering (rather than dead) troops. 
It was all accomplished without we pleebs ever gaining insights into how evasion way points are generated when a unit decides to decamp.
We'll never know if a more transparent process would have produced a correction after patch 4.01 or 4.02.
The Javelin guidance correction was issued within weeks. So, someone has a sense of 'severity'.
Save games rule. Keep posting until someone acknowledges the issue. That's the way we roll.
Welcome to the club. Don't take it personally. Play on.

As a beta tester (mention this because it's not obvious in my sig Edited to add: woot, I changed my sig. ), I will say that there are lot of issues reported as "bugs" that are really design decisions with which someone disagrees. I understand and sympathize with the user who sees something and  doesn't know if it has been reported or not or if it's a bug. (Without a deep search and the time it takes to do one...no snideness meant: this is reality.) Other things are not bugs. They're something misunderstood (either historically or gamewise).
But, some of the known, internal, bugs are pretty minor. Some are not yet known. Others are obvious. Some have some big effects but are tough to kill without messing up other stuff. (I cannot say what, but there was a feature that was wanted by beta testers. It was created, baked into a build, and...oh, my: it was horrible in the game. A great lesson.)
A public list would create a fulcrum upon which much would be leveraged against BFC. Haters gonna hate. (Not that your suggestion is one, nor are you a "hater". Just sayin'...) 
If you see something, a beta tester should come along and either show/state why/how it's meant to be that way, or dig into it and internally get the process underway to bring it up so BFC can work the issue. (Oops, "problem".  )
 

I'm going to use your statement as an example. Don't get upset.
"Drop down immediately": so, when 6 men are behind bocage (or whatever) and 1 man is close to the enemy and 3 men are in the middle of the open street, you want them all to "drop down immediately".  You know, and I know, that would lead to issues. The one man who is close will die. The 3 men in the open will die, the 6 men "back there" will drop and not contribute any suppressive firepower or spotting that could've aided the rest of the team/squad. Bad idea.
"when taking fire": what does this mean? Bullet striking flesh? A single round of 9mm 30 feet away? Four bursts of MG42 in the squad center? Etc.
This is why SHOWING a savegame is so much more helpful than a statement.
HUNT is a problematic movement command in that it is more like the old "Move to Contact". There are an infinite number of combinations of events that could be construed as "my men should've sought cover" or "my men should've kept moving". If there is an egregious issue, it should be fixed. If there is a consistently wrong borderline case, it should be fixed.
So, savegames help.
I have an hour or two of playing this series. I have not seen anything that strikes me that HUNT is broken. Not saying it isn't: just saying a savegame would help.

Oh, and one more item: the internal tracking system is approaching 10,000 items. I'm not going to see how many are open, how many are bugs, uniform errors, the wrong location for the PzVII b A7 (experimental) smoke discharger, or other such items. Each could be called a "bug".
Can you imagine a forum with 10,000 separate threads???
The tracking software does a great job. It is far better than having some sort of open list (that would have to be managed, updated, etc.).
Just wanted to give you a sense of the scale involved.

Hmmm....can't say I never noticed that definition, but you did.  
I'll toss it into the internal Beta Hopper and see if it gets spit out as a bug, or if the manual gets changed.
Thanks.

My bold. 
Your thread has an update.

One problem with a 'public' bug reporting system (using publically submitted bugs) is how much duplication there is in reporting and the quality of that reporting. Even among the beta-testers this happens on occasion. This causes a bit of 'noise' in the reporting, where the developer has to sort through the multiple reports trying to find the best or most workable reports. There is also the issue of attempting to confirm the bugs. Some issues may not be bugs or the details aren't sufficient to reproduce the problem and that clutters up the reporting system. With publically submitted bugs this can be a significant issue.
The closest thing that would be workable with a developer of this size is a public list of acknowledged bugs. This has its pitfalls too though, with the time it takes to resolve some bugs or even what is considered a bug and what isn't. This can give the perception that the game is buggy and will remain so in some customer's views.
 

So I did a little test because when I switched to an AMD GPU recently I discovered that the time it takes to load a game significantly worsened (with CM titles).
I have discovered that of the game options texture quality has an effect on that. And only that. Model quality, shader, multisampling etc. does not have an effect on this.
All times are given as m:ss, from a cold start (I have quit completely CM before starting the next test).
Test hardware: Ryzen 3600X + 5700XT + 32GB DDR4 RAM  + Kingston HyperX Savage SSD
 
CMFI: Beyond the Belice scenario (tiny) loading times in accordance with the 3D texture qualities:
Fastest: 0:14
Faster: 0:19
Fast: 0:29
Balanced: 0:46
Improved: 2:16
Better: 2:17
Best: 2:18
CMFI: Hot Mustard scenario (huge)
Fastest: 0:46
Faster: 0:50
Fast: 1:01
Balanced: 1:12
Improved: 2:28
Better: 2:31
Best: 2:31
 
You may wonder whats the difference in picture quality. Test shots for each setting are here in QHD resolution:
Fastest, Faster, Fast, Balanced, Improved, Better, Best

He was, and will remain, an icon for all things early CM.
He set a great example. 

A little update on Conflict of heroes, Storm of Steel - Kursh 1943.
My Son now works from my house also, so we now have time to play a game during lunch.
So guess what we are playing. played 4 Scenarios so far.
 
If you can find someone to play against, then this is the best wargame I have ever played that is a board game.
The concept and rules are designed for head to head play and it brings in plenty of fog of war and with the mechanics of the game. plenty of uncertainty as to what to expect from your units.
If you can accept good and bad luck, its just creates a fun aspect in the play.
 
One example, my Son brought two hidden squads out of hiding, crested a hill and was point blank to two of my squads in a gully. he knowing it was a risky move before he did it. 
I then opened fire on his units, all I needed was a 6 or better with 2 dice to put some type of hurt on him. I then added two CP points to the attack (they are valuable and he did not think I would use them for this attack), meaning all I needed was a 4 or more to get a pin type result or a 8 or better to just kill him. 
Needless to say, I was grinning from ear to ear in that I was going to make him pay for a stupid move.
I then role a 3 and he is yelling in joy and I in pain. but we both laughed, made a story line about how the sudden shock of seeing enemy troops emerging at point plank range put my men in panic mode and they were not aiming as they fired at the enemy onslaught .
 
I thought for sure that was going to cause my loss in the game, and it has made it very hard but I have manage to bounce back on that flank and gain control once again and cause him equal losses. So the game showed me that even bad luck did not wreck good tactics in that having other units well placed allowed for me to make that loss at least pay off in the long run as a likely amount of casualties for both sides.
 
But the game takes turns and twist as to who might have the advantage and there is no certainty about anything until  one side finally gets a few positive events in a row and get more of a commanding presence.
Anyway, the only board game that I have ever played that has created excitement with how the odds are calculated and executed in the dice role and how damage is also uncertain.
Also in the fact of how simple the roles are determined and it takes only one role to get the results, the game flow is very fast and engaging most of the time.
 
 

Oh no.....There were two of them:

They did this:

AFAIK at least one of them is still alive.....I'm now blowing the hell out of the police headquarters with a T-55, mostly in the hope of inducing a global surrender, as these two clearly have no intention of doing so on their own! 

Real-Time and WeGo have different "rules" about loading/unloading. Try both ways of playing, and TEST everything you've been told here so you get a feel.

Good. Something else to do is put pauses in the various units' movement orders. That is worth learning how they interact with one another.

Something to try: Open up the editor. Toss in a mounted infantry platoon (or company). Make the map about 800m x 800m. Give yourself 4 hours. Call it, "Test - Catch a Ride".
Save it, then play it. See what types of movement commands work and what don't. (Move, load. Load, move. Move, unload. Unload, move.) 
After ~30 minutes, you'll have gained a huge amount of insight into how this works and the timing involved.

Something to try: Open up the editor. Toss in a mounted infantry platoon (or company). Make the map about 800m x 800m. Give yourself 4 hours. Call it, "Test - Catch a Ride".
Save it, then play it. See what types of movement commands work and what don't. (Move, load. Load, move. Move, unload. Unload, move.) 
After ~30 minutes, you'll have gained a huge amount of insight into how this works and the timing involved.

Yes, I should have added the explanation for it too. I didn't want to make it seem they just nerfed artillery to annoy people.

Testers here are highly resistant to anecdote-based complaints due to repeated instances of following up on anecdotes with time-intensive controlled tests and finding either a non-issue, or results nearly opposite to that claimed in the anecdote (i.e. something claimed as happening all the time is actually statistically rare).  Users are very prone to confirmation bias regarding failures and negative events.  If the failure or negative event involves something where probability is a factor (like artillery casualties), not an always / never event, you really should try to set up a test to confirm.
But that is just general commentary.  On air bursts vs. trucks, I did setup a quick 155mm (point, heavy, quick) vs. mounted platoon in 32x32ish square test and the results did not diverge significantly from same test with "general" fusing.  Trucks and troops in trucks are certainly not immune to air bursts.  However, it does feel off in several ways:
Neither airbursts nor ground bursts seem to deliver sub-system (radio, engine, wheels) damage to trucks even when they are causing casualties to passengers.  Trucks appear to either be fine or KO'd with nothing in between.  The distance threshold for a hit to be likely to KO a truck seems to be the same for air bursts and ground bursts, maybe a little tighter for air bursts.  Might be a bug in this, or maybe any sub-system damage results in immediate KO? (If the latter, then trucks are definitely not taking sub-system damage as would be expected.) Because air bursts never directly strike trucks, all air burst KOs appear to be without damage.  Trucks won't blow up / burn from air burst KOs.  Also noticed that sometimes the KO would happen a turn or so later, further giving the "no effect" feel. Troops in trucks appear to have higher protection vs. artillery bursts compared to troops in the open on the ground.  But if their trucks are KO'd and they exit, they go down much faster to air bursts than to general.  

I've been working this and what I'm seeing is actually pretty good. Yes, there IS an issue, but only in one set of circumstances.
The TacAI targeting algorithm is correctly apportioning the team's antitank assets to the correct targets. I've tried various combinations of weapons and armored targets. The TacAI is really doing some great discrimination. Kudos.
The only issue is a matter of timing. If we could get everyone to HOLD FIRE until after the Javelin is fired, then it would be about perfect. IMHO.

Just to be clear: I am just a lowly beta tester. All I can do is flag it and run it up the pole. (To mix some metaphors. Or something. )
I have NO idea if it is possible for BFC (I am -not- an employee) to do this...or if they think it's a good idea or if they have the resources, etc. 
I shared my idea and that is what I will present. But, well, we'll both have to wait and see if anything comes of it. (Of course, if it does, I may know about it before you.  )

@nikolai,
Yeah, I figured out the stripping away of the assault team leaves the remaining team with the AT4s and the Javs.
There are a few things seeming to be going on here. Like I hinted, I've tested this for years, and I thought it had been resolved. I'll go back behind the closed Beta doors and work on it there.
The AT4 shows a range of 0 to 300 meters (point target) and the Javelin's is 75 to 2,500 meters. Their ranges overlap from 75m to 300m. This is the problem area. (Inside of 75m, only the AT4 should be usable...and used.) The desired behavior would be for NO AT4s to be used outside ~75m, if a Javelin is present in the team/squad. Fudging that ~75m up to ~100m would be fine to me (so it's not such a hard cutoff). So, enemy armor (IFV or MBT) inside ~100m, use the AT4s and anything else (absent a restrictive cover arc). Outside that ~100m, with a Javelin, no one should fire until AFTER the Javelin(s) engages the targets.
^^^
That is what _I_ would like to see. I'm not sure if it's possible to code it that way. But, as I said, I'm ducking behind the Beta curtain.
Thanks.
Ken