BletchleyGeek

I ran the same scenarios as Hister using my system with the following specs:
AMD FX 8320 3.5GHz 8-core (4 modules totaling 8 integer, 4 floating point, up to 4.0GHz turbo mode)
8GB of DDR3 1600 (CAS 9)
MSI GeForce GTX 660 Ti  - 388.00 driver
Asrock 880GM-LE FX motherboard (AMD 880G chipset)
Samsung 840 EVO 250GB SSD
Windows 7 Home 64-bit SP1 (latest patches)
Running at a resolution of 1920 x 1200.
Using the default settings in CMBN 4.0 (Balanced/Balanced, Vsync OFF and ON, AA OFF) and in the Nvidia Control Panel I typically got about 6 FPS (measured with the latest version of FRAPS) in "Op. Linnet II a USabn UKgrnd" on the German entry side of the map (all the way to the edge) and scrolling right or left looking at the Americans in Richelle. In "The Copse" scenario it measured around 28 FPS behind the allied armored units at the start (scrolled around the map a bit).
Messing around with Vsync (both on and off), anti-aliasing, anisotropic filtering, Process Lasso (affinity, etc.), power saving settings in Windows control panel, etc. didn't seem to have a significant performance effect on the low FPS of 'Op. Linnet II...'. I overclocked the FX 8320 to 4.0GHz (simply using the multipliers in the BIOS and turning off several power saving features there too, such as APM, AMD Turbo Core Technology, CPU Thermal Throttle, etc.). With 'Op. Linnet II...' the FPS increased to only 7 FPS. Turning off the icons (Alt-I) did bump up the FPS by 1 additional frame (the option reduced the number of objects to be drawn in this view) to 8 FPS.
There are some Hotfixes from Microsoft that supposedly address some issues with the Bulldozer/Piledriver architecture and Windows 7 involving CPU scheduling and power policies (KB2645594 and KB246060) that do NOT come through Windows Update (you have to request them from Microsoft). I have NOT applied these patches to see if they would make a difference since they CANNOT have their changes removed (supposedly), even if you uninstall them. A number of users on various forums have stated that the changes made little difference to their particular game's performance.
I decided to compare this to an Intel system that was somewhat similar:
Intel Core i5 4690K 3.5GHz 4-core  (possibly running at 3.7 to 3.9GHz in turbo mode)
16GB of DDR3-2133 (CAS 9)
eVGA GeForce GTX 670 - 388.00 driver
Asrock Z97 Killer motherboard (Z97 chipset)
Crucial MX100 512GB SSD
Windows 7 Home 64-bit SP1 (latest patches)
Running at a resolution of 1920 x 1200.
Again using the same settings used on the FX system with CMBN and the Nvidia Control Panel I got 10 FPS in 'Op. Linnet II...' while scrolling on the far side looking at the American forces in the town. In 'The Copse' scenario the FPS went to 40 FPS behind the allied vehicles at their start positions. The biggest difference between the GTX 660 Ti and the GeForce GTX 670 is the greater memory bandwidth of the 670 since it has a 256-bit bus compared to the 660 Ti's 192-bit memory bus. So POSSIBLY the greater GPU memory bandwidth in conjunction with the Intel i5's higher IPC (Instructions Per Cycle) efficiency and the increased system memory bandwidth (faster system RAM) resulted in the higher frame rate on the Intel system, but only by so much.
I ran a trace of the OpenGL calls used by CMBN while running 'Op. Linnet II a USabn UKgrnd' on the FX system. This recorded all of the OpenGL calls being used in each frame. The trace SEVERELY slowed down the system during the capture (a lot of data to be written to the trace file). Examining the trace file suggests that CMBN is SEVERLY CPU BOUND in certain graphical views. This is especially true with views of a large amount of units and terrain like that in 'Op. Linnet II...'.
What appears to be happening is that some views in large scenarios of CM involve A LOT of CPU time in issuing instructions to the video card/'frame buffer'. The CPU is spending so much time handling part of the graphics workload (which IS normal) and sending instructions to the video card on what to draw that the video card does not have a full (new) frame of data to post to the frame buffer at a rate of 60 or 30 FPS (Vsync). At 30 FPS each frame would have to be generated between the CPU and the video card within 33.3ms. Instead this is taking around 100ms on the Intel system and about 142ms on the FX system (resulting in the 10 and 7 FPS respectively). Some frames in the trace file had hundreds of thousands of instructions, some reaching near 700,000 instructions (each one is not necessarily communicated between the CPU and video card, only a fraction of them are), whereas sections where the FPS was higher might only have less than 3000 instructions being executed. The low frame rate is a direct consequence of how busy the CPU is and this can be seen with both Intel and AMD CPUs.
So the accusation comes up, is the CM graphics engine un-optimized ? To a certain extent, it is. There are limitations on what can be done in the environment and with the OpenGL 2.x calls that are available. CM could be optimized a bit further than it is currently, but this involves a HUGE amount of time experimenting and testing. Working against this optimization effort is CM's 'free' camera movement, the huge variety, number and size of maps available and the large variety and number of units.These features make it hard to come up with optimizations that work consistently without causing other problems. Such efforts at optimization are manpower and time that Battlefront simply does not have as Steve has stated earlier. Charles could be working on this for years in attempt to get better frame rates. While this would be a 'worthy goal', it is unrealistic from a business standpoint - there is no guarantee with the amount of time spent on optimizing would result in a significantly better performing graphics engine. Other, larger developers typically have TEAMS of people working on such optimizations (which, importantly, does allow them to accomplish certain optimization tasks within certain time frames too). When CMSF was started sometime in 2004 OpenGL 2.0 was the latest specification available (with the 2.1 specification coming out before CMSF was released). Utilizing newer versions of OpenGL to potentially optimize CM's graphics engine still involves a lot of work since the newer calls available don't necessarily involve built-in optimizations over the 2.0 calls. In fact a number of OpenGL calls have been deprecated in OpenGL 3.x and later and this could result in wholesale redesigning of the graphics engine. On top of this is the issue that newer versions of OpenGL may not be supported by a number of current user's video cards (and laptops and whole Mac models on the Apple side).
As for the difference between the GTX 550 Ti and the GTX 660 Ti that Hister is experiencing, I'm not sure what may be going on. The GTX 550 Ti is based on the 'Fermi' architecture, while the GTX 660 Ti utilizes the 'Kepler' architecture. Kepler was optimized for the way games operate compared to the Fermi architecture which had slightly better performance in the 'compute' domain (using the GPU for physics calculations or other floating point, parallelized tasks). The GTX 660 Ti should have been a significant boost in video performance over the GTX 550 Ti, though this performance difference may not be too visible in CM due to the CPU bound nature of some views. It's possible that older drivers may have treated the Fermi architecture differently or simply that older drivers may have operated differently (there are trade-offs that drivers may make in image quality for performance - and sometimes this is 'baked into' the driver and isn't touched by the usual user-accessible controls). I have a GTX 570 I could potentially test, but I would probably need to know more details about the older setup to possibly reproduce the situation and see the differences first-hand.

I can eat, walk, pee, and breath without help so, it could be worse.
 
Nice to see you. It's funny, I was just perusing some of your stuff on YT a few minutes ago. Now, here you are.
 
Mord.

Halftracks should be seen as nothing more than bulletproof trucks, asking for more out of them is asking for trouble.
Their job is to deliver your infantry to their jumping off point unharmed, providing some suppressive fires with their machineguns, allowing for rapid redeployment in between engagements, as well as providing an easy source of ammunition resupply.
You would be better off keeping them out to around 400-500 meters while firing, and only closing within that range specifically to disembark infantry, then withdrawing again.
 
One of Jeffrey Paulding's tactics videos features Armored Infantry (Time-Stamped to Relevant Portion):
 
My playtesting of Rinaldi's scenario 'Duel in the Mist' does show some armored infantry in action, if you want to have a look:
Of course, I possessed copious amounts of supporting weapons, so the actual tactical problem was one of time management, rather than the specific problem of employment.
 
 
 
 
 
I do have plans to make a tactics video specifically about Armored Infantry, but life and work have sapped my schedule quite a bit.
I hope this helps, and welcome to the forums, btw.

I’ve been playing the CMFB campaign Courage Conquers and was wondering how you guys make best use of armoured infantry? Doctrine says to transport troops ‘close’ to the fighting and then the dismounted infantry continue the fight on foot.
So far so good. However, the US armoured infantry platoon loses a lot of potential firepower keeping the halftracks out of enemy LOS.
I’ve tried keeping the halftracks to 250-300m away from any enemy infantry, but the instant they ‘Open Up’ to allow them (and their passengers) to start dishing out the good news, they become total bullet magnets.
Within a turn or two, they’re reversing quicker than you can say ‘Italian tankette’, usually with multiple casualties on board, including  dead crew members. The exact same thing happens with the German Panzergrenadiers in their SdKfzs.
I often find situations where it’s absolutely necessary to have the extra MGs, but the halftracks regularly seem more vulnerable than their crew-served infantry equivalents.
So what’s the answer? How can you best use the additional firepower, especially when you don’t have enough other firepower to effectively suppress a range of mutually supporting defenders?

@Mord - The existing terrain types hopefully. New tree models - unlikely

Steve has said all they are looking to do is port the game to the new engine, but it will take account of water, bridges etc and so hopefully we will see all the relevant tile types carried across given they already exist. I don't think we will see any new models.

P

Sorry to dig this up again but being (again) on the receiving end of Soviet SMGs one thought came up:
HE is nerfed a bit to accommodate the bunching up of pixeltroopers so shouldn't there be a similar mechanic for SMGs?
Obviously any spray&pray type weapon would have an advantage against high density targets. Maybe that is causing the perceived effectiveness?

Yes, Harry's method works well, also great for tossing grenades over a ridgeline... I have used it many times for that, one opponent sent me an email wondering what I was firing on his team with and from where.  
I outlined the procedure (loosely) in my Platoon Scouts Blog post (look for the Cresting a Rise section).

try 'be evil unto him' - it's basically ALL recce.

TL;DR: Another thread derailed by the usual suspects.

Amedeo, just an observation on the data, informed by my experience dealing with that kind of data while working on another game
Always take that kind of figures as the "best that weapon can do". Full stop. These figures were collected from field trials, with the weapons being operated by technicians or marksmen on perfect conditions (a firing range with props that allow to measure exactly dispersion). The British Army Ordnance Service conducted a more "realistic" testing using recruits and the differences one can see between the technical specs and the actual outcomes achieved with highly reputed weapons as the Sten or the Enfield, well, let's say that the technical specs of the weapon predict very badly how they will actually perform in the hands of your average recruit, under psychological stress and against targets that try to close the range quickly or are using cover in an intelligent way.
From a more "operational" point of view: when you feed this data, taking it as the baseline probability of killing or maiming, on any reasonable model of infantry combat by fire, you'll get massive casualty rates. Massive as in totally ahistorical. The data is "wrong" in the sense that either it needs to be toned down to set the "any given Sunday" to a more reasonable level, which is difficult, since the definition of "any given Sunday" is a moving target, or the combat model (and the AI if it is empowered to manage ammunition) has to provide with the elements to "modulate" these figures, starting from the assumption that it is an absolute upper bound on what that weapon can do. That data integration and curation job is very hard. BFC call seems to be to have the AI to disregard the PPSh as something that can be fired above certain ranges... and I think it makes all the sense in the world.

Yet as ASL Veteran and others point out, there seems to be something a bit off with the lethality of these weapons on the latest versions of the engine. I do tend to agree with those observations. But I don't think the data BFC is using is wrong, their models are buggy or the AI is being unreasonable: I think it is more a question of design of effects and interactions with other aspects of the design of the CMx2 engine. Regarding design, I - personally and subjectively - would like to see the volume of fire these things can put out at ranges beyond 60 meters to result in more suppression over a larger area, rather than generating killing or incapacitating hits. As for interactions with other parts of the CMx2 design, the tighter-than-in-real-life packing of our pixel truppen due to action spots constraining their deployment that increases lethality. If you have five guys standing in a 8 square meters area and something like 100 rounds of ordnance shot fly through the volume encompassing the action spot and the men, chances that all of them are hit will be quite high, as they will be physically occupying a significant proportion of that volume. And that assuming that the rounds trajectories are uniformly and randomly distributed, for even loosely aimed fire, those chances can become almost a certainty.
Observations about action spots and burst fire extreme lethality have been made in the past, I am not sure what is BFC opinion on that.

Amedeo, just an observation on the data, informed by my experience dealing with that kind of data while working on another game
Always take that kind of figures as the "best that weapon can do". Full stop. These figures were collected from field trials, with the weapons being operated by technicians or marksmen on perfect conditions (a firing range with props that allow to measure exactly dispersion). The British Army Ordnance Service conducted a more "realistic" testing using recruits and the differences one can see between the technical specs and the actual outcomes achieved with highly reputed weapons as the Sten or the Enfield, well, let's say that the technical specs of the weapon predict very badly how they will actually perform in the hands of your average recruit, under psychological stress and against targets that try to close the range quickly or are using cover in an intelligent way.
From a more "operational" point of view: when you feed this data, taking it as the baseline probability of killing or maiming, on any reasonable model of infantry combat by fire, you'll get massive casualty rates. Massive as in totally ahistorical. The data is "wrong" in the sense that either it needs to be toned down to set the "any given Sunday" to a more reasonable level, which is difficult, since the definition of "any given Sunday" is a moving target, or the combat model (and the AI if it is empowered to manage ammunition) has to provide with the elements to "modulate" these figures, starting from the assumption that it is an absolute upper bound on what that weapon can do. That data integration and curation job is very hard. BFC call seems to be to have the AI to disregard the PPSh as something that can be fired above certain ranges... and I think it makes all the sense in the world.

Yet as ASL Veteran and others point out, there seems to be something a bit off with the lethality of these weapons on the latest versions of the engine. I do tend to agree with those observations. But I don't think the data BFC is using is wrong, their models are buggy or the AI is being unreasonable: I think it is more a question of design of effects and interactions with other aspects of the design of the CMx2 engine. Regarding design, I - personally and subjectively - would like to see the volume of fire these things can put out at ranges beyond 60 meters to result in more suppression over a larger area, rather than generating killing or incapacitating hits. As for interactions with other parts of the CMx2 design, the tighter-than-in-real-life packing of our pixel truppen due to action spots constraining their deployment that increases lethality. If you have five guys standing in a 8 square meters area and something like 100 rounds of ordnance shot fly through the volume encompassing the action spot and the men, chances that all of them are hit will be quite high, as they will be physically occupying a significant proportion of that volume. And that assuming that the rounds trajectories are uniformly and randomly distributed, for even loosely aimed fire, those chances can become almost a certainty.
Observations about action spots and burst fire extreme lethality have been made in the past, I am not sure what is BFC opinion on that.

If you code your weapons to fire at their maximum range, instead of their maximum effective range, you will run out of ammunition before killing anything.
That's true of any game that models realistic ballistics data, you have to compromise theoretical maximum range, to make the weapons effective enough for the player to use them.

This is from ChrisND's stream that aired today, enjoy guys, and thanks Chris!
 
 
 

Good news team. There's a couple of minor technical issues to resolve first, but at this stage it looks like the BP will be released mid-to-late September. Yay!

To this day I still think ASL is what helped make me into a engineer. - If you could understand those rules, you pretty much can learn to understand pretty much anything.

Status so far:

I believe spotting info is maintained to the AIP, despite animation change to a lower profile (kneel or prone). Yet the smaller profile makes them way harder to be hit. So generally it does its purpose for increasing suvivabilty for soldiers doing certain actions (reloading, buddy aid).

Beside that, animations are tightly coupled to the TAC AI actions and personally I don´t see more opportunities to increase survivability by changing animations. Some more basic SOP and TAC AI changes would be required instead. Most animations are reused either for idle or transition actions and changing one animation, could break multiple animation sequences. In example the buddy aid animation is 2 part. One is the soldier transitioning to kneel stance and then to actual buddy aid. The same kneel stance animation is used for many other sequences, thus if beeing changed to prone also, would break a number of other sequences in game. So this is already the end of the rope, tinkering with infantry animations IMO.

I got reloading, buddy aid and cower now adapted to my personal liking and it doesn´t break anything, at least I can´t observe something of the like.

I´ll make a list of file name changes, so everybody can repeat the mentioned edits for himself. Think redistributing the ani files with changed file names, is a no go, due to content copyright.

Just changed another animation that I found to be overly dramatic. Cowering!

Files exchanged (renamed), "kar98k-idle-prone 3.ani" to "kar98k-cower.ani". Looks like this:



Btw, majority of CM soldier animations, draw from the K98k animations folder by default.

Could do that, but I just want to check & change mentioned non combat animations. While doing buddy aid and reloading magazines (not loading individual rounds, i.e Kar98k, which is also shown as "reloading" in actions tab) I assume soldiers not performing any other actions like shooting, or observation. Here´s what can be greatly improved to avoid the most stupid and unnecessary carnage.
We need some official statement from BFC about this!

I´d changed the animation files (file names) in about 10-15 minutes (basic CMBN germans and US only), so it´s not really much work. CW and remaining stuff shouldn´t take any longer.

My assumption about changed animation is, when in the game every bullet and sighting line to actual geometry is tracked, then the method of forcing soldiers to less exposed stances while not combating, or observing, the associated 3D hitbox around geometry shouldn´t be either observable or targetable by the game. Could be that the game AI still has status "observable" and "targetable" registerd, but since it can´t see nor taget the actual geometry, it won´t shoot at it and maybe also looses track. That´s the interesting part.

Only "observable" side effect so far is partly non smooth transitions between changed animations. With regard to reloading animations, it´s hardly observable. The buddy aid animation has an odd transition between kneeling and new buddy aid prone animation (now simply "unarmed-idle-prone.ani"), but personally I can live with that, as long as I can get rid of stupid and unnecessary soldier exposure. The actions with changed animations, still work normally. I now have prone lying soldiers performing buddy aid, as well as soldiers, that go down next stance level, to perform weapon magazine reloading.

If anybody interested would like to help testing, I´ll pack some dropbox file.

So here´s the procedures for everybody to try yourself:

Buddy Aid:

Rezexplode the "Normandy v100A.brz" file from Data folder, look in animations/unarmed, rename the "unarmed-idle-prone.ani" file to "unarmed-tend to casualty.ani" and drop that into data/z folder = prone lying medic. He won´t that die that often anymore.

Cower:

Same as above, but rename "kar98k-idle-prone.ani" to "kar98k-cower.ani" (both in k98k folder) and drop into data/z.

Reloading, one stance lower:

Folders (in animation):

bar, bazooka, kar98k, m240, mg42, mp40, mp44, panzerschreck, piat, pistol, sten and thompson.

Ani files are distributed amongst "Normandy v110.brz" (base), "Normandy v111.brz", "Normandy v200.brz" (contains major animation file update), "normandy v210.brz" and "Normandy v211.brz".

Rezexplode them all subsequentially (assuming you have ALL game updates, as well as CW and MG modules installed) and copy the animations folder to a seperate place. Copy any animation file updates (from BRZ file list above) over older animation folder, until you have just the latest files available and ready for the renaming procedure.

Now go to the individual weapons animation folders (list above) and look for the files with "reload" in file name. I.E there´s 9 times a "reload" file in k98k folder (reload prone, reload kneel, reload stand, a-b-c). Copy the reload prone files to a seperate folder. Rename the prone files to corresponding kneel file names (i.e "kar98k-reload-a-prone.ani" to "kar98k-reload-a-kneel.ani"). Now put the original kneel files into a temp folder and rename them to corresponding stand files (i.e "kar98k-reload-a-kneel.ani" to "kar98k-reload-a-stand.ani").

This leaves up to 6 renamed files from every suitable weapons animations folder (rifles, lMG, SMG and zooks), to be copied or rezpacked into the data/z folder. If all done right, reloading soldiers in stand stance, will play the reloading in kneel stance animation, reloading in kneel stance will use reloading in prone stance animation. Reloading prone is unchanged and unaffected.

I did not tinker with any of the HMG (heavy) animation, nor other files, not related to reload. The reload animation files contain the full clip/magazine reload actions, not to be confused with single round reload (bolt action). Reloading rifle grenades is affected as well, as is Zooks/Schrecks, when files are renamed from the appropiate folders.

I haven´t had any game crashes or "broken" animation sequences, although some transitions could be a bit "dirty". Do at your own risk.

Hope the instructions are clear enough for everyone to experiment with and have fun with results.

Yep, it looks regular, as it´s the animation taken from regular behavior, a soldier with actual weapon in hand simply lying prone (kar98k-idle-prone.ani), used for all nationalities soldiers. I would´ve prefered a soldier with just this animation, but also with head simply pressed to the ground (not looking forward as in this chosen animation), but it´s not available unfortunately.

Personally I (always) found the standard cower animation looking overly dramatic, particularly with swinging back rifle 180° to the rear. Looks particularly bad (to me) with lMG and such. Whether this (original) is a realistic looking animation is not quite of concern, as BFC intention with this most likely was to give the player a quick assessment of a soldiers status (suppressed). Personally I´m totally fine with just having a look at the units suppression meter, as well as at individulal soldiers status (cowering) for my own troops to get a quick assessment. With regard to enemy units, I even consider this as increased realism, as you can´t see at a glance by taking notice of the standard cower animation, if the enemy (or parts of it) is heavily suppressed or not. Different sort of FOW so to say. At last it´s a matter of taste to use this or that animation style and I´m fairly sure that it hasn´t any other ingame effects, as there´s no actual stance change involved (prone = prone). Also doesn´t hurt transition animations (from any stance to cower and back).

Only question to me remains, if size of hitbox around every individual soldier is either equal, or different (with lying prone as example). If it´s different and hitbox roughly coincides with an individual soldier outer geometry, then I´d dare to suspect, that the standard cower animation offers more of a targetable silhouette, than the chosen substitute animation. So if putting quick status assesment intent of an animation put aside, then I´d find it more realistic, if a cowering soldier would itself make an as small a target, as possible. These are questions only BFC authorities could answer.

With regard to my medic animation substitute, my current "belief" is that the game keeps the actual spotting info from actual visible geometry of a soldier separated. In other words, although the medic is lying prone, the game assesses the medic still as in original kneeling stance (and tracks it as a shootable target). That´s hard to test, particularly in Iron mode, where I make almost all my testing. It´s still very much dependant where and in what hostile environment, a medic makes his buddy aid attempts. If it´s in a trench and the whole unit, where both the medic and WIA is part of is on "hide", chances are greatly decreased that the whole unit will attract incoming fire and the medic has greater chances, to actually complete and not break with his buddy aiding attempts (and start anew if situation permits). Currently, if a unit is on hide and not greatly suppressed by taking a loss previously, the medic will attempt buddy aid in kneel position and thus breaks the whole units hide attempt for quite a long duration. Getting back to your intial question, ...while the medic still might show his own (and his units presence) by the games internally recorded kneel stance, the actual medics prone stance geometry noticably decreases the enemies hit chances vs the medic. General survivability of a medic is noticeably increased, if remaining factors are favourable as well. A medic tending a WIA in coverless terrain, in full view of the enemy, won´t survive long, no matter if he´s in kneeling or lying stance.

Whatever the reason was for BFC to apply a medic soldier the kneeling stance generally, I´d wish for future game revisions some more distinct medic animations/stances that better coincide with a units tactical circumstances. In example, a unit on hide should have the medic put to prone. Can´t tell if there´s ingame abstractions that already reflect certain circumstances invisibly, but from my observations and associated conclusions there´s quite a number, where this is not the case obviously. Not all is WYSIWYG, just like in the case of buildings, where windows and doors obviously are way larger than visible geometry would indicate. Or damaged buildings that offer far less protection for soldiers, although actual building geometry doesn´t quite support the impression. Maybe medics already receive some sort of abstracted protection/LOS modifier, but I just can´t observe it in my games.

Generally, my "mod" is not a quite a mod. Rather a foundation for testing features that might become interesting for later game revisions. Or just trying different GFX for matters of taste, like it´s for other sorts of mods too. For animations that do not change stances or corrupt associated transition animations, personally I see no potential problems with it.

Thanks for your feedback, Erwin!

PS: *ani files go to data/z folder as any other modded game content. That info is part of the mod description at GAJ´s.

Thanks for additional links and interesting info from board members. Though it doesn´t clear up, whether hitboxes are used, or plain soldier geometry. I still believe, it´s the former.
For definition of a "Hitbox"

(From Valve Developer Community)

https://developer.valvesoftware.com/wiki/Hitbox

"A hitbox is an invisible box (or more often a series of boxes) which define the rough shape of a model for purposes of damage-based collision detection. A typical model within a game is much too high-poly to perform real-time hit calculations on, so hitboxes are used instead.

A hitbox is different from a bounding box in that it is more complex and closer to the model's visible shape. The bounding box is used for movement-based collision detection, and is usually literally a single box."

I just can encourage players to test both these animations vs. the AIP or H2H, as otherwise this remains a not so fruitful theorethical discussion only.

I keep the reloading stance "mod" in the bag, as well as other candidates for increased self preservation, as it requires some more intensive testing. Just naming lMG/HMG assistants (loaders) as example, or whole HMG crews. The following pic gives the idea. (now diving into my foxhole.... )

With regard to standard cower animation, it apparently is one size fits all purpose, that doesn´t intersect with surrounding terrain like foxholes ect. too much. Possible hitboxes or silhouettes, can be roughly compared in the following screenshot (standard cower - edited cower), for which personally I would prefer the edited one, as it possibly gives a slightly better chance not to be hit where it hurts.



I could imagine a more "realistic" cower to be one of the dead animations like this:



This pic is from the german Reibert, showing a soldier taking full cover (Volle Deckung). "The soldier takes full cover, if he neither wants to shoot, nor needs to observe." Maybe not quite the same as beeing suppressed, or "cowering", but gives the idea about making itself a small target, as was taught to the greenest of soldier:

As I understand things now, there are "generally" two Battlefront teams now. I say generally as there is a lot of overlap and movement between the teams but for example one team worked on the Bulge and the Vehicle Pack for CMBN  after Red Thunder while another worked on Black Sea. With Black Sea done for now (except for another bigger patch) it seems to me the low hanging fruit would be a module for Red Thunder with Lend-lease vehicles and SS and Luftwaffe Field formations (all already done) of which there were a lot of in AGC. Maybe throw in some of the advanced snow terrain they have made for the Bulge and you're set. Anyway that's how I read the tea leaves. All conjecture, no inside info. 

Next major WW2 title is the Bulge game.

CMRT is clearly getting a module at some point, and they've talked about more Eastern front modules, working backwards.
Logically this could be one per year, which would mean Kursk and Stalingrad in the next Eastern Front game (!)

CMFI might have a final module, but CMBN is presumably "finished", at least for the most part.

This all might change of course - Steve's been even more hesitant/cautious than normal when talking about the future.

 

IanL,
is the HUNT command a SOP, too?
Is a covered arc a SOP?
The HIDE command?
The DEPLOY command at the end of a movement path?

 
But that's not what I suggested. My suggestion is a very precise ans dedicated behaviour for certain kind of units.Just like infantry seeks cover by going down, the affected vehicles would no longer commit suicide once they recognize a threat when this function was enabled, but reverse where they came from. Thinking about it, maybe even the HIDE command and button could be used to activate this behaviour?
Vehicle moves + threat = current behaviour.
Vehicle moves + HIDE activated + threat = reverse.
 
I used the example of the DEPLOY command to show that certain units have special buttons, functions and behaviours which other units do not have. Normal game behaviour.Infantry squads.This function and the button even vanishes when the size of the unit is beyond a certain threshold - same unit.

The game is full of these things, well it is good, BECAUSE it models units realistically and gives them their own capabilities. My suggestion would fit to existing game mechanics and has nothing to do with SOPs or engine limitations.